David, I don't know what you're smoking. As for the history lesson, thanks, but I was there. The following references cite discussion that clearly demonstrates that the team had felt that the delivery receipt is an application-level response [1] [2] [3] [4] and that we endeavored to separate the two so that it was clear that DR was not related to RM. I could have dug up more fodder, but this is getting boring and it is late. The spec clarifies the distinction between the delivery receipt and the acknowledgment in section 8.4.7.1. To wit: The deliveryReceiptRequested attribute is used by a From Party to indicate whether a message received by the To Party should result in the To Party returning an acknowledgment message containing a DeliveryReceipt element. Note: To clarify the distinction between an acknowledgement message containing a DeliveryReceipt and a Reliable Messaging Acknowledgement: (1) An acknowledgement message containing a Delivery Receipt indicates the To Party has received the message. (2) The Reliable Messaging Acknowledgment indicates a MSH, possibly only an intermediate MSH, has received the message. I think that this clearly supports my view. Note that the entire section talks about the To Party , not the To Party's MSH because, as I've said before, the DeliveryReceipt is a business level response. A signal in RosettaNet terms. It can be used for Nonrepudiation (signed) purposes, or simply to provide for the receiving application to tell the sending application (not MSH) that the message was received... we'll get back to you soon . All of this is provided for and prescribed in a business process description using the BPSS. Maybe you should read that spec as well. The fact that the DeliveryReceipt and Acknowledgment were temporarily siamese twins was merely a marriage of convenience because they shared the same structure basically (although that has since evolved). Section 8.14 states: The DeliveryReceipt element is an optional element that is used by the To Party that received a message, to let the From Party that sent the original message, know that the message was received. The RefToMessageId in a message containing a DeliveryReceipt element is used to identify the message being for which the receipt is being generated by its MessageId. Again, it clearly states To Party which equates to application which means that it is a business level signal. Nowhere in this section will you find any discussion of reliable messaging because it is completely unrelated. A search of the Reliable Messaging section (10) in the spec turns up a whopping 0 (zero) occurances of the word DeliveryReceipt. Is that clear enough for you? Regards, Chris [1]
http://lists.ebxml.org/archives/ebxml-transport/200104/msg00007.html [2]
http://lists.ebxml.org/archives/ebxml-transport/200102/msg00036.html [3]
http://lists.ebxml.org/archives/ebxml-transport/200104/msg00045.html [4]
http://lists.ebxml.org/archives/ebxml-transport/200104/msg00047.html David Fischer wrote: > > Chris, > > Prior to London (or around that time) we did not have Acknowledgements or > DeliveryReceipts (there was a MessageType which could have a value of > Acknowledgement ) so it was NOT always like this. The original name of the > Acknowledgement element was IntermediateAck (must have been an Intermediate > Acknowledgement). The original intent of DeliveryReceiptRequested was to send > back an Acknowledgement message (we didn't have the DeliveryReceipt element > yet). > > > The deliveryReceiptRequested parameter/element MUST be used by a From > > Party MSH to indicate whether a message received by the To Party MSH > > should result in the To Party MSH returning an acknowledgment message > > containing an Acknowledgment element with a type of deliveryReceipt. > > This is your suggestion Chris (1/16/01). Obviously the Original meaning of > DeliveryReceiptRequested was to send an Acknowledgement Message. Let me quote > from David Burdett to Saha, Saikat on 1/4/01 (RE: TRP spec 0.9a > comments/feedback): > > >> 3. Synchronous Messaging spec,. DeliveryReceipt and IntermediateAck. Why > >> both are required? Last intermediary > >> cannot produce IntermediateAck before it receives the DeliveryReceipt from > >> receiving MSH or intermediary nodes can create > >> IntermediateAck before they receive any response from next node? > > <DB>The whole idea of an intermediate ack is so that the intermediate node > > can return a response **before** they receive a reply from the next > > destination. This is useful particularly if end-to-end transmission times > > are long. This way, the sender of the initial message can turn off their > > timeout and rely on the intermediate node notifying them if they could not > > deliver the message. To draw an analogy with the real world, if you go to > > FedEX or UPS, they give you a receipt immediately. You don't hang around > > until your package has reached its final destination. You also don't keep on > > pestering FedEx to ask them if the package has got through.</DB> > ><DB>I could not follow these until I realised you are talking about 0.91 and > > not 0.9a !!</DB> > > Chris, these have ALWAYS been Intermediate Acks and not end-to-end. Let me > quote David Burdett on another message from the next day (1/5/01 -- RE: > SyncReplyMode as defined in .91 is a misnomer): > > > I am also uncomfortable with having two parameters that imply essentially the > > same thing. For example if deliveryReceiptRequested or > > immediateAckRequested are both set to NONE, then a syncReplyMode of > > AcksOnly or AcksAndResponse would be inconsistent. We really ought be able > > to avoid this sort of problem with the correct choice of parameters. > > > </DB> > > I still agree. David Burdett may prefer AckRequested rather than > DeliveryRequested (David?). I think whatever parameter we use, we need only one > and it needs to be in the MessageHeader, not in Via (spec is broken if it is in > an element which has actor=next). > > On 2/26/01 (RE: CPA and Overrides) David Burdett identified the parameters which > pertained to individual hops: > > > 2. Parameters that apply to an indivual hop: > > - syncReplyMode (or whatever it gets renamed as - Prasad?) > > - errorURI > > - reliableMessagingMethod > > - AckRequeted (was IntermediateAckRequested) > > On 3/9/01 (Issue: We need separate acknowledgment and delivery receipt elements) > David Burdett added the DeliveryReceipt element: > > >>Section 8.13 Acknowledgment Element. I think we need to fix the > >> acknowledgement element so that you can have, in one message,both: > >> · a MSH acknowledgment resulting from the ackRequested being set to > >> true, and also > >> · a DeliveryReceipt Acknowledgment arising from > >> DeliveryReceiptRequested being set to true. > >> > >> Currently if we have syncReply set to true (see lines 2444-7), then > >> although both are requested, only one could be returned. > >> > >> Having two elements would solve this problem: the current acknowledgement > >> element and a separate Delivery Receipt element with essentially the same > >> structure but a different meaning. Changes required are as follows ... > > /..snip > >>8.14 DeliveryReceipt Element > >> > >> The DeliveryReceipt element is used by a To Party that is the final > >> destination of a message to indicate to the From Party, that sent the > >> message, that the message has been received. > >> The DeliveryReceipt element has the same structure and content as the > >> Acknowledgement element (see section xx). > > Chris, this is not, nor has it ever been a business level Delivery Receipt. It > has always been a DeliveryReceipt Acknowledgement. I see that you have always > misunderstood this as in 4/16/01 you wrote (Re: comments on David's proposed > changes): > > > A DR is a very different animal. I respectfully disagree > > with your assertion that we keep the From element in the > > DeliveryReceipt with the rationale that it overly complicates > > things from an implementation perspective. > > DR is not a different animal but you misunderstood from the beginning. So, I > went back and read all instances of DeliveryReceipt in the current spec and I > don't see what you are describing. I see types of DeliveryReceipt (signed > unsigned). I see DeliveryReceipt in conjuction with a payload (as with > syncReply=true). I see that the DeliveryReceipt can be specifically a > messageService service as in section 8.4.7.1: > > · the Service element MUST be set to uri:www.ebXML.org/messageService/ > · the Action element MUST be set to DeliveryReceipt > > Chris, There is nothing in the spec describing your view of the DeliveryReceipt > element, nor is it born out in the eMail list. DeliveryReceipt has always been > an MSH level Acknowledgement message and Acknowledgement (IntermediateAck) has > always been for hop-to-hop RM. > > Sorry for the length. > > David Fischer > Drummond Group > >