Re: T2 PLEAE READ - Suggested solution to RM Issues

[Arvola Chan <arvola@tibco.com>]

David:

You asked me to check the contents of the Via element to see if the
Via element can be omitted when QOS is BestEffort for the single-hop
case:

><db>Not sure this works. There are additional attributes in the NAD (Via)
>element that are currently required such as syncReply. Arvola. Can you
ckeck
>the spec and determine which is optional which is required and specify what
>the default semantic should be for each of these elements/attributes if the
>NAD/Via is not present.</db>

Your proposed change #11 calls for having syncReply both under
MessageHeader and Via, so for the single-hop BestEffort case, the
information can be obtained from the MessageHeader.

The elements and attributes under Via are:

- CPAId -- not needed for single-hop
- Service -- not needed for single-hop
- Action -- not needed for single-hop
- id -- not needed when Via is not present
- version -- not needed when Via is not present
- actor -- not needed when Via is not present
- syncReply -- can be obtained from MessageHeader
- reliableMessagingMethod - not needed when QOS is BestEffort
- ackRequested -- not needed when QOS is BestEffort

Therefore, my conclusion remains that the Via element is not
needed when QOS is BestEffort and no intermediary is involved.

Regards,
-Arvola

-----Original Message-----
From: Burdett, David <david.burdett@commerceone.com>
To: ebXML Messaging (E-mail) <ebxml-msg@lists.oasis-open.org>
Cc: 'Arvola Chan' <arvola@tibco.com>
Date: Thursday, September 06, 2001 5:23 PM
Subject: RE: T2 PLEAE READ - Suggested solution to RM Issues


>Arvola
>
>See comments in line.
>
>David
>
>-----Original Message-----
>From: Arvola Chan [mailto:arvola@tibco.com]
>Sent: Thursday, September 06, 2001 4:47 PM
>To: ebXML Messaging (E-mail)
>Subject: Re: T2 PLEAE READ - Suggested solution to RM Issues
>
>
>David and David:
>
>I don't have any major objection to the proposed changes.
>My comments are in tandem with David Fischer's bracketed
>by <ac> and </ac>.
>
>Regards,
>-Arvola
>
>-----Original Message-----
>From: David Fischer <david@drummondgroup.com>
>To: Burdett, David <david.burdett@commerceone.com>; ebXML Messaging
(E-mail)
><ebxml-msg@lists.oasis-open.org>
>Date: Thursday, September 06, 2001 3:19 PM
>Subject: RE: T2 PLEAE READ - Suggested solution to RM Issues
>
>
>David,
>
>Looks pretty good.
><df>Comments inline</df>
>
>Regards,
>
>David.
>
>-----Original Message-----
>From: Burdett, David [mailto:david.burdett@commerceone.com]
>Sent: Thursday, September 06, 2001 1:44 PM
>To: ebXML Messaging (E-mail)
>Subject: T2 PLEAE READ - Suggested solution to RM Issues
>
>
>Folks
>
>If you do not respond to this email then, as chair of the T2 effort, I AM
>GOING TO ASSUME YOUR SUPPORT. So please read at least the first part of
this
>email which explains why I am doing this ...
>
>There has been a LOT of discussion about Reliable Messaging on the list. I
>also sense that different people's views are gradually aligning. However to
>move forward we HAVE to come up with constructive suggestions. I first did
>this a nearly a month ago see ...
>
>http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00125.html
>
>Although there were a lot of replies to this email few of them were about
>the actual suggestions I made. Those that were received (Arvola Chan &
David
>Fischer) were generally in agreement although both suggested worthwhile
>improvements. So in order to focus on the solution I have restated the
>approach in my earlier email below with a few tweaks to reflect more recent
>discussions.
>
>What I think will be really constructive is if we use this suggested
>solution as the basis for discussion so that we can refine it and hopefully
>finalize it in the F2F on October 3-5. Once we get agreement we can then
>start making changes.
>
>Furthermore, AS CHAIR OF THE T2 EFFORT I AM GOING TO ASSUME THAT NO COMMENT
>MEANS ACCEPTANCE. I don't like doing this but unless we start talking about
>solutions rather than problems we will not make progress.
>
>Does this makes sense?
>
>Finally, I've missed some of the detail of the discussions in order to make
>the suggested solution (fairly) brief. This does not mean they are not
>included ... they definitely will need to be ... and if they are important,
>I am sure you will make your views known ;)
>
>Best wishes to everyone.
>
>David
>SUGGESTED CHANGES TO SOLVE RM ISSUES
>
>Change 1
>--------
>Summary: Rename the Via element as "Next Actor Data" or similar.
>
>Rationale: There can always be "intermediaries" in a message transfer even
>if you are going point-to-point. For example consider the two example
>message flows that I recently posted that cover the following use cases:
>1. A genuine intermediary who is a third party that is running a MSH and
>forwards messages to the final destination.
>2. A Party which has a MSH that acts as a "mailroom" that forwards the
>message internally using ebXML RM to another MSH that then forwards it to
>the application. The "mailroom" MSH ia an intermediary. Chris Ferris
>provided an example of this use case at
>http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00412.html
>
>I think we need to support both use cases. By renaming the Via element as
>"Next Actor Data". We are simply saying that the data contained within the
>element is for the Next Actor **only** and does not need to be forwarded.
>The Next Actor recreates the data as they need to if they are forwarding
the
>message. If we think of the data in the Via as being for the "Next Actor"
>then we are also more closely aligned with SOAP. It also removes the
problem
>of treating intermediaries as "something special" and allows an internal
MSH
>to forward the message to another MSH without the original sender needing
to
>know and without having to re-create the complete message.
>
><df>I agree with all your rationale.  My only question is backward
>compatibility
>issues with 1.0 implementations due to the name changes.</df>
>
><ac>
>I am ambivalent about the name change. Clarification of the intent of the
>element and its usage rule is sufficient for me.
></ac>
><db>We might need to vote on this.</db>
>
>Change 2
>--------
>Summary: Data in the Next Actor Data (Via) element is for the Next Actor
>only
>
>Rationale: What Change 1 means is that we must carefully review the
existing
>elements in the header and check to see whether they are needed by the
>ultimate destination/endpoint or the next actor. I think that this will
>require the following changes:
>1. CPAId. The CPAId in the Message Header identifies parameters that apply
>"end-to-end", e.g. business process level stuff, whereas the CPAId in the
>NAD/Via element applies to the transport over a single hop, e.g. transport
>level stuff. I realise this will require changes to the CPP/A ... and
>probably more discussion.
>
><df>Agreed.  This may not require any CPA change at all since, as Marty put
>it,
>multi-hop is just a set of binary collaborations.  There is a CPA with the
>end
>and a CPA with the next hop.  This is perfect.  What is the value if there
>is no
>IM?  Needs to be optional or allowed to be empty.</df>
>
><ac>
>I agree with David Fischer.
></ac>
>
>2. Acknowledgment Element. This should be part of the NAD/Via element as
>acknowledgments are between two MSHs and are not propogated to the original
>sending party.
>
><df>No, if we move Acknowledgement to Via then we remove it from the
>Signature.
>This is OK if we don't want signed Acknowledgements.
>
><ac>
>I suppose it is possible that the CPA between two intermediate MSH
>calls for non repudiation of receipt in which case the Acknowledgement
>would have to be signed. I vote for keeping the Acknowledgement
>element outside of the Via element.
></ac>
><db>I agree with this also and have withdrawn this suggested change.</db>
>
>If we are going to make this massive a change, then let's go all the way
and
>move TraceHeaderList to Via and simplify the ds:Signature Transform.
>TraceHeaderList must be modified by each hop and then passed to the next.
>TraceHeaderList is intended for the next hop so it also should be part of
>Via.
>
><ac>
>I agree that it makes logical sense to move the TraceHeaderList
>under the Via/NAD element.
></ac>
><db>I've a change of view here in that we should not move it unless there
is
>a real reason. We just need to make it clear what the "next" and "to"
actors
>need to do with each SOAP extension</db>
></df>
>
>Change 3
>--------
>Summary: Make Next Actor Data (was Via) a required element.
>
>Rationale: There are two reasons for this:
>1. The current Via element contains data that is REQUIRED for
>point-to-point, e.g. ReliableMessagingMethod.
>2. There are two levels of reliability, that need to be covered:
>point-to-point (P2P) as well as end-to-end (E2E).
>
>Currently Via is optional. If we are doing point-to-point, then you would
>have to have ReliableMessagingMethod duplicated at the header level in
order
>to solve the problem. This does not make sense. Making NAD required solves
>this problem.
>
>The layering problem of P2P vs E2E is similar to the problem that TCP/IP
>solves as was clearly stated by Dan Weinreb at
>http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00225.html. Marty
>Sachs, David Fischer and others have also repeatedly said that unless you
>have end-to-end acknowledgement then there is no certainty. I think we need
>to recognize that there can always be two levels and therefore need to
>recognize both these levels in the header.
>
>Now TCP/IP does this as two SEPARATE layers. The current spec puts both
>layers in one spec with one header. I don't think we NEED to radically
>change the spec in this area but would like peoples views.
>
><df>Agreed.  What is the value of Via CPAId if there is no IM?</df>
>
><ac>
>The CPAId under the Via element is optional according to the XSD.
>If the QOS is BestEffort and no intermediary MSH is involved, there
>is no need for the Via/NAD element. I think it can remain optional as
>long as we can clearly articulate the circumstances under which it must
>be present.
></ac>
><db>Not sure this works. There are additional attributes in the NAD (Via)
>element that are currently required such as syncReply. Arvola. Can you
ckeck
>the spec and determine which is optional which is required and specify what
>the default semantic should be for each of these elements/attributes if the
>NAD/Via is not present.</db>
>
>Change 4
>--------
>Summary: Make the return of a Delivery Receipt required if
>deliverySemantics=OnceAndOnlyOnce
>
><df>Agreed</df>
>
><ac>
>I agree. Even if the incoming reliable message does not have
>the DeliveryReceiptRequested attribute set, the receiver MSH
>should still return a DeliveryReceipt.
></ac>
><db>I agree but is should be unsigned. This is the default value. See
>below.</db>
>
>Change 5
>--------
>Summary: Remove "None" as an option for deliveryReceiptRequested and make
>deliveryReceiptRequested=false the default.
>
>Rationale: As the return of a Delivery Receipt is the only sure way that
you
>know a message was delivered suggests that it will be a simpler solution if
>we make this always the case. Therefore we can make the return of a
delivery
>required if the deliverySemantics are OnceAndOnlyOnce. However you still
>need to know if the receipt must be signed.
>
><df>Agree with removing "None" but would prefer to leave as "Signed |
>Unsigned"
>for backward compatibility.  Default is "Unsigned".</df>
>
><ac>
>I agree with David Fischer.
></ac>
><db>So did I!</db>
>
>Change 6
>--------
>Summary: Make the return of an Acknowledgment element in a message required
>if the ebXML RM protocol is being used
>
><df>Agreed, but isn't this already true?</df>
>
><ac>
>I agree with David Burdett. The current spec does not required the
>Acknowledgement element to be present in an Acknowledgement
>message.
></ac>
><db>I agree with you and me ;)</db>
>
>Change 7
>--------
>Summary: Remove "None" as an option for ackRequested and make
>ackRequested=false the default.
>
>Rationale: The rationale for doing this is similar to changes 4 and 5. It
>simply gives the rule that if you are doing ebXML RM then you must include
>an Acknowledgment element in the response. The response can be synchronous
>or asynchronous (see change 11 below).
>
><df>Agree with removing "None" but would prefer to leave as "Signed |
>Unsigned"
>for backward compatibility.  Default is "Unsigned". (same as Change 5)</df>
>
><ac>
>I agree with David Fischer.
></ac>
>
>Change 8
>--------
>Summary: Include automated retry by the original sender (From Party) if no
>Delivery Receipt is returned
>
><df>Agreed</df>
>
><ac>
>Do we need to give some guideline on the selection of retry interval
>for hop-to-hop vs retry interval for end-to-end?  I think the former
>interval
>should be shorter than the latter.
></ac>
><db>Agree this would need to be included in the revised spec.</db>
>
>Change 9
>--------
>Summary: Include a "MessageRetryCount" in the NAD (was Via) element in the
>Message Header
>
>Rationale: There is a need for automated retry by the original sender (From
>party) if a Delivery Receipt is not received. However, the original sender
>wants to send the **identical** message yet not have it treated as a
>duplicate and by any intermediate MSH that has previously received it. To
>solve this problem you can add a "MessageRetryCount" to the NAD which
>indicates to the MSH that even though they have received the message before
>they must still forward it.In this case even if the resend is received
first
>and the original appears some time later, the ToParty will be able to
>recognize that the message has already been processed by comparing
MessagIds
>only and therefore the original should be ignored. This logic needs to be
>included in section 10 and will need to include another level of
>RetryCounts/RetryIntervals to work at the end-to-end rather than the
>point-to-point level.
>
><df>Agree on MessageRetryCount.  No need for another level of
>Retries/RetryInterval since it already exists -- there is one set in the
>end-to-end CPA (MessageHeader CPAId) and another in the Sender-FirstHop CPA
>(Via
>CPAId).</df>
>
><ac>
>I agree with David Fischer.
></ac>
>
>Change 11
>---------
>Summary: Include syncReply at both the Message Header and the NAD/Via
>elements
>
>The To Party needs to know whether the From Party wants the Delivery
Receipt
>and Business Payload assembled into one message.The next MSH needs to know
>whether to send back an Acknowledgment synchronously or wait for the
>Business Payload before sending it. The Delivery Receipt and Business
>Payload can be sent asynchronously and the Acknowledgment sent
synchronously
>and vice versa as they are independent of each other.
>
>As you can't easily cover both requirements in a single element, they need
>to be included separately in the header and in the NAD(Via).
>
><df>Agreed</df>
>
><ac>
>I agree in general.
>
>The semantics of syncReply need to be aligned with the CPP/A spec.
>The notions of signalsOnly, signalsAndResponse, and responseOnly
>in the CPP/A spec need to be expanded to cover Acknowledgements
>and DeliveryReceipt. Signals are application level messages according
>to the BPSS spec.
></ac>
><db>I agree that the MS and CPPA specs need to be aligned.</db>
>
>Change 12
>---------
>Summary: Clearly explain the relationship between applications, MSHs and
>partys and the need for notification.
>
>Rationale: Marty Sachs has clearly demonstrated the absolute need to be
>clear about stating the requirement that the From Party "knows" that the
>message has been delivered. We need to clarify the spec to make sure that
>this is clear.
>
><df>Agreed.</df>
>
><ac>
>I agree.
>
>I also like to propose a Change 13. If ackRequested is implied whenever
>deliverySemantics is onceAndOnlyOnce and reliableMessagingMethod
>is ebXML, then there is no real need for an ackRequested attribute
>(under the Via element).
><db>Disagree. You need to indicate whether it is signed or unsigned. With
>the changes above, if it is absent, then it implies that it is
>unsigned.</db>
>
>If end-to-end reliable messaging does not imply hop-to-hop reliable
>messaging, then we should clearly state that in the spec.
><db>Yes and no. I think that reliability works at two levels the hop and
>point-to-point. They can actually work independently of each other as Dan
>Weinreb has described.</db>
>
>Also, I believe in earlier discussions we have said that a Delivery
>Failure Notification message from an intermediate MSH to the
>sending MSH should be sent using reliable messaging. Such a
>statement and the rationale for doing so should be incorporated into
>section 10 as well.
><db>Agreed. Does the text contained in the email to Marty at
>http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00365.html meet
the
>need? It proposes a revision to section 10.4</db>
></ac>
>
>
>Product Manager, xCBL, XML Standards
>Solution Strategy, Commerce One
>4400 Rosewood Drive, Pleasanton, CA 94588, USA
>Tel/VMail: +1 (925) 520 4422; Cell: +1 (925) 216 7704
>mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>