RE: T2 SyncReply and ReliableMessagingMethod in QualityOfServiceInfo

[Martin W Sachs <mwsachs@us.ibm.com>]

*************************************************************************************

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