+1,
This is what I had brought up at F2F.
-hima
Cliff Collins wrote:
> >
> >
> > I don't get error on ack at all. If I receive an
> > acknowledgment message, and for whatever reason cannot
> > process it (let's say it was mangled in transit)
> > then I'll simply resend the original message
> > until I get an ack, or until either the message's TTL
> > expires or the retries have been exhausted at which
> > time I'll notify the application that I have not
> > received an acknowledgment confirming the message's
> > receipt by the intended recipient.
>
> Acks can now also be used for Non-repudiation of receipt. This means that if
> the ds:References are not included or it is not signed and the CPA says it
> was suppose to be than this is an ERROR of inconsistent. Waiting for the
> retry doesn't solve the error.
>
> >
> > As for ack on error, why on earth cannot an error
> > be treated with all of the same QoS as a normal
> > message?!?!? What if the recipient wants to be sure that
> > the original sender is notified that there has been
> > a problem in processing the message? Seems perfectly
> > reasonable to me to allow this.
>
> I look at this another way, since errors (in general) are generated by the
> MSH in response to a message they are not a reliably sent message any more
> than we would make "acks" be resent automatically. The error is in response
> to a message. If the sending MSH sends the message again, we would error
> again, not the other way. This is in contrast to continually sending an
> error for a message we received that was in error.
>
> >
> > The circularity comes only (IMO) when you error on
> > an acknowledgment because this would require that
> > the sender of the acknowledgment provide for the
> > ability to process the error (as well as for specification
> > as to what processing is required which is currently
> > not addressed in the specification).
> >
> > IMO, the only thing that the spec should say is that
> > an ack cannot be requested for an acknowledgment message.
> >
> > Cheers,
> >
> > Chris
> >
> >
> > Cliff Collins wrote:
> >
> > > I like Error on Ack (like the 1.0 model) the best.
> > >
> > > If we allow Ack on Error then it becomes really messy when there is a
> > > failure on the Ack message. And when the retries are reached on
> > sending an
> > > "error" over RM does this generate another error of delivery
> > failure? Messy
> > > :-)
> > >
> > >
> > >>-----Original Message-----
> > >>From: David Fischer [mailto:david@drummondgroup.com]
> > >>Sent: Monday, December 10, 2001 12:30 PM
> > >>To: ebXML Msg
> > >>Subject: [ebxml-msg] Ack on Error, or Error on Ack
> > >>
> > >>
> > >>I did not get to bring this up today so I will try eMail.
> > >>
> > >>If we allow both Ack on Error and Error on Ack, we have the
> > >>potential for an
> > >>infinite loop. Either is fine but not both.
> > >>
> > >>First we chose to allow Error on Ack but not Ack on Error (no
> > >>Error messages
> > >>sent reliably).
> > >>
> > >>There was some dissention, so we changed to allowing Ack on Error
> > >>but not Error
> > >>on Ack (Error message can be sent reliably but if there is
> > >>something wrong with
> > >>an Ack there is no notification). Now there is dissension the opposite
> > >>direction ;-(
> > >>
> > >>I prefer Error on Ack since it seems redundant to send an Error
> > >>reliably and I
> > >>would like to know if there is a problem on my Ack. I will be
> > >>happy either way
> > >>but we need to decide (and quit sending me complaints).
> > >>
> > >>Which way?
> > >>
> > >>Regards,
> > >>
> > >>David Fischer
> > >>Drummond Group.
> > >>ebXML-MS Editor.
> > >>
> > >>
> > >>
> > >>----------------------------------------------------------------
> > >>To subscribe or unsubscribe from this elist use the subscription
> > >>manager: <http://lists.oasis-open.org/ob/adm.pl>
> > >>
> > >
> > >
> > > ----------------------------------------------------------------
> > > To subscribe or unsubscribe from this elist use the subscription
> > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> > >
> >
> >
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>