RE: T2 SyncReply and ReliableMessagingMethod in QualityOfServiceI nfo

[Scott Hinkelman <srh@us.ibm.com>]

More thought on my comment:

Even though I believe the semantic of RM should mean From <-> To, that does
not mean
that an IM should be precluded from proxying this functionality. (This
could be conceptual
ground work for IM support and the functionality they can support).

Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074



Scott Hinkelman/Austin/IBM@IBMUS on 08/07/2001 10:16:53 AM

To:   "HUGHES,JIM (HP-Cupertino,ex1)" <jim_hughes@hp.com>
cc:   ebxml-msg@lists.oasis-open.org
Subject:  RE: T2 SyncReply and ReliableMessagingMethod in QualityOfServiceI
      nfo



I agree. RM is From <-> To.
However, does this imply that if a CPA is used, and IMs are in the
picture that multiparty (if an IM is a party) CPA is required? Seems to me.

Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074



"HUGHES,JIM (HP-Cupertino,ex1)" <jim_hughes@hp.com> on 08/07/2001 09:59:45
AM

To:   ebxml-msg@lists.oasis-open.org
cc:
Subject:  RE: T2 SyncReply and ReliableMessagingMethod in QualityOfServiceI
      nfo



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
>

------------------------------------------------------------------
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