Re: T2 SyncReply and ReliableMessagingMethod in QualityOfServiceInfo

[christopher ferris <chris.ferris@east.sun.com>]

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
> 
> -----Original Message-----
> From: christopher ferris [mailto:chris.ferris@east.sun.com]
> Sent: Tuesday, August 07, 2001 4:13 PM
> To: David Fischer
> Cc: Martin W Sachs; ebxml-msg@lists.oasis-open.org
> Subject: Re: T2 SyncReply and ReliableMessagingMethod in
> QualityOfServiceInfo
> 
> David,
> 
> I think that you must have misunderstood then.
> 
> DeliveryReceipt has ALWAYS BEEN a business level response
> message.
> 
> Acknowledgment is not exclusive to use when there are
> intermediaries. Acknowledgment is for MSH RM use exclusively.
> We left DeliveryReceipt in the spec (actually calling out the
> clear distinction between it and Acknowledgment) so as to provide
> for use for business "signals" ala RosettaNet as prescribed by BPSS.
> 
> ToParty != MSH
> "ToParty MSH" == MSH
> 
> ToParty == Application
> FromParty == Application
> 
> This has always been the case. That is the reason for the
> very clear distinction between ToParty and ToParty MSH.
> 
> The DeliveryReceipt, or NonRepudiationReceipt serve *business*
> functions, not messaging functions. The source and target of a
> DeliveryReceipt is an application, the "ToParty", not the messaging
> software.
> 
> Cheers,
> 
> Chris
> David Fischer wrote:
> >
> > No Chris, that's not what we decided.   We had long (heated) discussions about
> > this in London and David (B) assured us that Acknowledgements were for
> > intermediate hops only.  Acknowledgement (sp) only goes back to the previous
> > hop.  This is why it is only in the Via.
> >
> > The DeliveryReceipt in the MSH is absolutely not a business level receipt.
> The
> > only mechanism we have to do end-to-end RM is through DeliveryReceipt.
> Section
> > 8.14 says
> >
> >         "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."
> >
> > This is only for receipt purposes -- no business processes.  We even built in
> > NRR (critical functionality IMO).
> >
> > David Fischer
> > Drummond Group.
> >
> > -----Original Message-----
> > From: Chris.Ferris@Sun.COM [mailto:Chris.Ferris@Sun.COM]On Behalf Of
> > christopher ferris
> > Sent: Tuesday, August 07, 2001 11:58 AM
> > To: David Fischer
> > Cc: Martin W Sachs; ebxml-msg@lists.oasis-open.org
> > Subject: Re: T2 SyncReply and ReliableMessagingMethod in
> > QualityOfServiceInfo
> >
> > Note that DeliveryReceipt is orthogonal to RM. A message
> > delieverd with BestEffort might require a DeliveryReceipt.
> > The BPSS determines whether a DeliveryReceipt is necessary.
> >
> > DelieveryReceipt is an application-level response/signal,
> > not a function of RM. It is the responsibility of some
> > "external" software agent to initiate a DeliveryReceipt.
> >
> > What I mean by this is that the MSH itself, while it might
> > be a part of a greater whole, is not responsible in and of itself.
> >
> > The MSH is a concept and it is given certain responsibilities
> >
> > How one implements an MSH, whether as a standalone peice
> > of software or as part of a more comprehensive peice of
> > infrastructure code is up to the implementer, not the
> > authors of the MS specification.
> >
> > In my mind, DeliveryReceipt is more a function of Stefano's
> > BSI or IBM's BPF.
> >
> > Cheers,
> >
> > Chris
> >
> > David Fischer wrote:
> > >
> > > Marty,
> > >
> > > The purpose of Acks is for hop-to-hop RM only.  The way it is set up now,
> once
> > > the message passes a hop which is not able to handle RM or doesn't need RM
> > (like
> > > MQseries) then none of the remaining hops will do RM since there is no way
> to
> > > reset AckRequested once it passes the unreliable hop.
> > >
> > > If intermediate-hop RM is not useful then why have Acks at all?  End-to-end
> RM
> > > can be done strictly with DeliveryReceipts ;-).  But, I am not suggesting
> > > getting rid of intermediate Acks, only getting rid of the AckRequested
> > attribute
> > > in Via.  We need intermediate Acks and we need intermediate-hop RM.  We
> don't
> > > need end-to-end Acks because we already have DeliveryReceipt but they need
> to
> > > act the same for RM.  By removing AckRequested and using only
> > > DeliveryReceiptRequested, the integrity of the RM request is maintained
> > > throughout the path.  Any hop which can do RM then will (unless overridden
> by
> > a
> > > local CPA).
> > >
> > > David Fischer
> > > Drummond Group
> > >
> > > BTW, let's change Acknowledgment (or Acknowledgement) to Ack.  I liked that
> > > idea!
> > >
> > > -----Original Message-----
> > > From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> > > Sent: Tuesday, August 07, 2001 9:26 AM
> > > To: ebxml-msg@lists.oasis-open.org
> > > Cc: "Chris Ferris"
> > > Subject: RE: T2 SyncReply and ReliableMessagingMethod in
> > > QualityOfServiceInfo
> > >
> > >
> >
> ********************************************************************************
> > > *****
> > >
> > > Martin W. Sachs
> > > IBM T. J. Watson Research Center
> > > P. O. B. 704
> > > Yorktown Hts, NY 10598
> > > 914-784-7287;  IBM tie line 863-7287
> > > Notes address:  Martin W Sachs/Watson/IBM
> > > Internet address:  mwsachs @ us.ibm.com
> > >
> >
> ********************************************************************************
> > > *****
> > > ---------------------- Forwarded by Martin W Sachs/Watson/IBM on 08/07/2001
> > > 10:25 AM ---------------------------
> > >
> > > Martin W Sachs
> > > 08/07/2001 10:24 AM
> > >
> > > To:   David Fischer <david@drummondgroup.com>
> > > cc:
> > > From: Martin W Sachs/Watson/IBM@IBMUS
> > > Subject:  RE: T2 SyncReply and ReliableMessagingMethod in
> > >       QualityOfServiceInfo  (Document link: Martin W. Sachs)
> > >
> > > Again, be careful with the ACKS.
> > >
> > > If the To and From parties are separated from each other by intermediaries
> > > A, B, C in series, and B can't do reliable messaging:
> > >
> > > a) It doesn't matter that B can't do reliable messaging if the reliable
> > > messaging protocol is betwen the To and From parties' MSHs, which is what
> > > it should be.  The job of hops A, B, and C is simply to move the message
> > > along.  I suppose that the A-B and B-C hops could do their own reliable
> > > messaging under the covers but, as I said in the earlier posting, if C
> > > loses the message before forwarding it to the To party, then the fact that
> > > A-B and B-C are doing reliable messaging is of no value.  The message still
> > > won't get to the To party.
> > >
> > > b) Aside from that, if hop B-C is generally unreliable, reliable messaging
> > > can still be done between the To and From parties.  However, the To party's
> > > MSH may have a higher than normal frequency of retries because of the low
> > > quality of hop B.
> > >
> > > Regards,
> > > Marty
> > >
> > >
> >
> ********************************************************************************
> > > *****
> > >
> > > Martin W. Sachs
> > > IBM T. J. Watson Research Center
> > > P. O. B. 704
> > > Yorktown Hts, NY 10598
> > > 914-784-7287;  IBM tie line 863-7287
> > > Notes address:  Martin W Sachs/Watson/IBM
> > > Internet address:  mwsachs @ us.ibm.com
> > >
> >
> ********************************************************************************
> > > *****
> > >
> > > David Fischer <david@drummondgroup.com> on 08/07/2001 09:42:09 AM
> > >
> > > To:   christopher ferris <chris.ferris@east.sun.com>
> > > cc:   ebXML Msg <ebxml-msg@lists.oasis-open.org>
> > > Subject:  RE: T2 SyncReply and ReliableMessagingMethod in
> > >       QualityOfServiceInfo
> > >
> > > How do you set SyncReply on a message-by-message basis?  If I understand
> > > you
> > > correctly, syncReply MUST apply to ALL transfers between two parties or to
> > > None -- must always be the same.  I think we may want a little more
> > > flexibility.
> > > We allow this flexibility in multi-hop, why not in single-hop?
> > >
> > > In EDIINT, syncReply was always default to True and we occasionally would
> > > change
> > > to False for very large files -- allowing the connection to close rather
> > > than
> > > wait (potentially hours) for a very large file to be decrypted or the MIC
> > > to be
> > > generated for a NRR.  (Instead of syncReply, EDIINT calls this parameter
> > > Receipt-Delivery-Option).  IMO, we need to allow for the unforeseen.
> > >
> > > In the case of ReliableMessagingMethod, I'm not even sure what this does or
> > > why
> > > we need it at all.  What does a value of "Transport" mean -- the spec
> > > doesn't
> > > say?  I assume it means just send the message and don't worry about RM
> > > since
> > > this hop can't handle it?  I think this will never be used but David seemed
> > > to
> > > think it was needed and I don't have any heartburn with that.  Since I this
> > > sits
> > > right next to SyncReply in the Ack, I included it in parameters which need
> > > to be
> > > allowed without an Ack.  Either way is fine with me.
> > >
> > > David.
> > >
> > > -----Original Message-----
> > > From: christopher ferris [mailto:chris.ferris@east.sun.com]
> > > Sent: Tuesday, August 07, 2001 5:58 AM
> > > To: David Fischer
> > > Cc: ebXML Msg
> > > Subject: Re: T2 SyncReply and ReliableMessagingMethod in
> > > QualityOfServiceInfo
> > >
> > > David,
> > >
> > > Where does this requirement come from? In the case of
> > > syncReply, the CPA is what determines this. In the absence
> > > of a CPA, then a virtual CPA applies.
> > >
> > > Cheers,
> > >
> > > Chris
> > >
> > > David Fischer wrote:
> > > >
> > > > There should be nothing in the Via which is not also in other headers.
> > > Via
> > > > should only be used for multi-hop intermediaries.  In the case of
> > > SyncReply,
> > > > there is no single-hop way of requesting SyncReply=true.
> > > >
> > > > Attributes SyncReply and ReliableMessagingMethod should also be in
> > > > QualityOfServiceInfo.  They should retain their current defaults.
> > > >
> > > > Regards,
> > > >
> > > > David Fischer
> > > > Drummond Group.
> > > >
> > > > ------------------------------------------------------------------
> > > > To unsubscribe from this elist send a message with the single word
> > > > "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
> > >
> > > ------------------------------------------------------------------
> > > To unsubscribe from this elist send a message with the single word
> > > "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
> > >
> > > ------------------------------------------------------------------
> > > To unsubscribe from this elist send a message with the single word
> > > "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
> > >
> > > ------------------------------------------------------------------
> > > To unsubscribe from this elist send a message with the single word
> > > "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
> >
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
> >
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
begin:vcard 
n:Ferris;Christopher
tel;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;;;;;
version:2.1
email;internet:chris.ferris@east.sun.com
title:Sr. Staff Engineer
fn:Christopher Ferris
end:vcard