RE: T2 SyncReply and ReliableMessagingMethod in QualityOfServiceI nfo

["HUGHES,JIM (HP-Cupertino,ex1)" <jim_hughes@hp.com>]

Marty's answer is precisely why we had difficulties in introducing multi-hop
RM in MSS V1. I agree with Marty's general observation of the purpose of RM,
though I would word it as "getting confirmation of message delivery between
the FromParty MSH and the ToParty MSH" -- pointedly, whether there are
intermediate MSH nodes (running RM or not) or static on the wire is not
material, as both scenarios could introduce failure. This is a MSH-level
session protocol, if you will, that just involves the two MSH end points. 

Maybe you get more "reliability" if an intermediate MSH node pair use
MQseries, but I think it really confuses the issue when you allow the
presence of intermediate nodes to affect the basic RM algorithm. I think
that a node's use of RM should be quite distinct from the (higher layer?) RM
between the endpoint MSHs.

jim



> -----Original Message-----
> From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> Sent: Tuesday, August 07, 2001 9:42 AM
> To: David Fischer
> Cc: ebxml-msg@lists.oasis-open.org
> Subject: RE: T2 SyncReply and ReliableMessagingMethod in
> QualityOfServiceInfo
> 
> 
> 
> In my mind, the only meaningful purpose of reliable messaging 
> is to get a
> message from the From Party's application to the To Party's 
> application
> once and only once.  Everything else is details of how to do 
> it.  Further,
> it cannot be guaranteed that there will never be a failure to 
> deliver a
> message, then the From Party's application is owned a 
> guaranteed delivery
> failure notification.  Multihop complicates the definition and
> implementations but it does not change the purpose.
> 
> 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 11:22:54 AM
> 
> To:   Martin W Sachs/Watson/IBM@IBMUS, ebxml-msg@lists.oasis-open.org
> cc:
> Subject:  RE: T2 SyncReply and ReliableMessagingMethod in
>       QualityOfServiceInfo
> 
> 
> 
> 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
>