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