[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
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. 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. 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> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC