[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-msg] Ack on Error, or Error on Ack
+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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC