RE: T2 SyncReply and ReliableMessagingMethod in QualityOfServiceInfo

[David Fischer <david@drummondgroup.com>]

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