Re: T2 SyncReply and ReliableMessagingMethod in QualityOfServiceInfo

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

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