Re: T2 PLEAE READ - Suggested solution to RM Issues

[christopher ferris <chris.ferris@east.sun.com>]

I'm in the XMLP WG f2f tuesday-thursday. I could make a call
later in the day Monday (say after 2 pm PDT) and I can probably
make an early call any day as long as it ends by 9 am PDT.

Thanks,

Chris

"Burdett, David" wrote:
> 
> Chris
> 
> You said ... "I request that the discussion of making it [Delivery Receipts]
> a default/required be deferred until I can participate." ... I agree as if
> you are not involved in the decision this thread is unlikely to end. When
> could you participate in a call next week as I don't want to leave this for
> another two weeks. We will then try work out a suitable time to discuss this
> on Monday.
> 
> See comments below this time marked with <db2/>.
> 
> David
> 
> -----Original Message-----
> From: christopher ferris [mailto:chris.ferris@east.sun.com]
> Sent: Friday, September 07, 2001 1:55 PM
> To: ebXML Messaging (E-mail)
> Subject: RE: T2 PLEAE READ - Suggested solution to RM Issues
> 
> Phew this thread is getting long;-)
> 
> Amazingly enough, DB agrees with me on a majority of
> my points... Someone please check for pods in David's
> office!!!
> 
> More comments below. I won't <snip/> as this is a valuable
> artifact for the resolution of these issues.
> 
> My comments with <cf1/> this go.
> 
> Cheers,
> 
> Chris
> -----------------------------------------------------
> Chris
> 
> Changea 4 & 5 suggest "Make the return of a Delivery Receipt required if
> deliverySemantics=OnceAndOnlyOnce"
> 
> Arvola and David F agree with this whereas Chris Ferris disagrees. I can see
> benefits in both approaches. So I think we should talk about this on next
> Monday's conference call.
> 
> See other comments below marked with <db1></db1> to distinguish from earlier
> comments.
> 
> David
> 
> -----Original Message-----
> From: christopher ferris [mailto:chris.ferris@east.sun.com]
> Sent: Friday, September 07, 2001 11:34 AM
> To: ebXML Messaging (E-mail)
> Subject: Re: T2 PLEAE READ - Suggested solution to RM Issues
> 
> My turn;-)
> 
> Please see my comments below.
> 
> Cheers,
> 
> Chris
> 
> "Burdett, David" wrote:
> >
> > 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>
> 
> <cf>
> I agree that the name change seems arbitrary and should only be taken
> after careful consideration of any backwards-compatibility issues.
> </cf>
> <db1>I've just re-read the spec on Via and, as currently defined it does not
> talk about it being used with intermediaries. So we do not HAVE to change
> the name. I just think it is misleading. Perhaps we should vote on this
> one.</db1>
> 
> <cf1>
> I don't necessarily agree that the name needs to be changed, but it could
> be tightened up to speifically indicate that it is for use with
> intermediaries
> which is, after all is said and done, what we had in mind when we added it
> in the 11th hour. As we discussed off-line, I think that much of the
> problems
> that people raise w/r/t 1.0 have more to do with what is NOT said in the
> spec which those of us who were intimately involved in its creation had
> internalized over the course of the discussions, f2f meetings, etc.
> 
> IIRC, you were the one who suggested the Via name in the first place! ;-)
> </cf1>
> 
> >
> > <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>
> 
> <cf>
> My take is that lumping *all* of the stuff designated for the "next" actor
> would be a mistake. We should be leveraging SOAP as it is intended. IMO, a
> SOAP "block" or header should have a specific purpose. More comments on
> this below.
> </cf>
> <db1>Following on from our separate earlier discussions, I think I agree
> with you.</db1>
> >
> > 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>
> 
> <cf>
> As I believe David B has pointed out, the CPAId in the Via element is
> currently optional in the v1.0 spec.
> </cf>
> <db1>Yes, but I think we need to clarify what the presence of the CPAId
> element actually means.</db1>
> 
> <cf1>
> No argument here!
> </cf1>
> 
> >
> > 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>
> 
> <cf>
> Agree that Acknowledgment, which is already targetted at the "next" actor
> should remain as a separate SOAP header block as per the v1.0 spec.
> </cf>
> 
> >
> > 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>
> 
> <cf>
> The TraceHeader list is already targetted at the 'next' actor. I see no
> reason whatsoever to relocate it.
> </cf>
> <db1>I agree.</db1>
> 
> >
> > 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.
> 
> <cf>
> If you have a CPA, whether real or imagined, and no intermediary then
> ReliableMessagingMethod is not needed in the message itself. The two nodes
> already have an understanding as to how they are effecting RM as per their
> agreement. Thus, it is not REQUIRED for point-to-point RM at all.
> </cf>
> <db1>It's not required if you are using the default values for: syncReply
> (false), reliableMessagingMethod (ebXML), CPAId (use the message level CPA).
> If you are not then it IS required whether you are doing point-to-point or
> multi-hop. This was my main reason for suggesting changing the name from Via
> to NextActorData.</db1>
> 
> <cf1>
> I disagree. Please be specific as to why you think this is needed. The
> CPA provides the requisite information that the two partys need without
> having to put this in the MessageHeader.
> </cf1>
> <db2>There may be no CPA. Remember although we are allowing (even
> encouraging) the use of a CPA we are not requiring it. In this case the
> information has to be in the message header. I agree that having the Via is
> optional. However you could still need it for point-to-point if: a) You have
> no CPA, and b) you want to use non-default values for syncReply,
> reliableMessagingMethod, the CPAId in the Via.</db2>
> 
> > 2. There are two levels of reliability, that need to be covered:
> > point-to-point (P2P) as well as end-to-end (E2E).
> 
> <cf>
> The fact that the parties agree to exchange receipts is orthogonal
> to RM. The fact that the RM protocol that is defined by the spec
> uses Acknowledgments is mere coincidence. We could have employed
> other mechanisms to acheive reliability. If it is desired that
> there be a formal expression of the equivalent of "I expect an
> acknowledgement" in the SOAP envelope, targetted at the "next"
> actor with a mustUnderstand=1, I suppose I have no problem with
> that. I would prefer that it be a standalone SOAP header and not
> merely lumped in with a bunch of other stuff.
> </cf>
> <db1>I agree that the need for a receipt and the need to do RM are separate
> requirements. In the current spec an "Acknowledgement message" at a minimum
> must contain a RefToMessageId that identifies the message that was received
> (lines 1814-5). The Acknowledgement elementis optional (lines 1816-7) and is
> controlled by the ackRequested attribute. I think that the current spec
> meets your need for separation. </db1>
> <cf1>
> ackRequested attribute is only on Via. I would actually prefer the
> solution/proposal
> I offered below to cover all cases, which I think is where you
> were going with this NAD proposal. I would prefer that it be
> a separate SOAP block if it is determined that a majority agree
> that the equivalent of 'ackRequested' is needed/desired in all cases.
> </cf1>
> <db2>I have a lot of sympathy with this but consider it could then be more
> of an improvement rather than a bug fix. This is something we should discuss
> on Monday.</db2>
> 
> >
> > 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.
> 
> <cf>
> See above, I disagree with the assertion that ReliableMessagingMethod
> is required in the MessageHeader.
> </cf>
> <db1>I agree. I don't want ReliableMessagingMethod in the header either. See
> earlier response.</db1>
> 
> >
> > 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>
> 
> <cf>
> I disagree! As I have repeatedly stated, the delivery receipt is
> not a function of RM. Do not tie the two together. If you want a
> deliveryReceipt, then ask for it using the existing mechanism
> (deliveryReceiptRequested). If you want that whenever you send a
> message with OnceAndOnlyOnce you ask for a deliveryReceipt, be my guest.
> 
> Please, do not make this a requirement.
> </cf>
> <db1>I think I can see benefits in both approaches. If we make it a
> requirement then it should make for a simpler solution at the expense of
> doing it even when it is not always needed. I think this is one we need to
> discuss on a conference call.</db1>
> <cf1>
> 'fraid I won't be able to join the next call (Monday). I don't think
> that it actaully makes anything simpler. I request that the discussion
> of making it a default/required be deferred until I can participate.
> </cf1>
> 
> >
> > 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>
> 
> <cf>
> Again, as I disagree with making a DR REQUIRED, I see no real value
> add in changing "None" to "false" unless the DR is ALWAYS signed
> in which case making the attribute an XSD boolean would make sense.
> </cf>
> 
> >
> > 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>
> 
> <cf>
> Huh? If the issue is that section 10.3.3 is less than clear as to whether
> an "Acknowledgment message" MUST have an Acknowledgment element, then
> clearly, that is an editorial issue that should be addressed. Seems
> to me that lines 1814/1815 should be changed to read:
> 
>         At a minimum, it MUST contain a MessageData element with a
>         RefToMessageId that is set to the value of the MessageId of
>         the message being acknowledged along with an Acknowledgment
>         element as described in section 8.6.
> </cf>
> <db1>I think this is the sort of wording we need. It also though makes lines
> 1816-17 redundant and removes the need for ackRequested.</db1>
> 
> >
> > 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>
> 
> <cf>
> Actually, consistent with the proposal I put forth above, adding a
> SOAP header block requesting an Acknowledgment would be a bit more
> coherent IMO.
> 
> e.g.
> 
>         <SOAP:Envelope xmlns:SOAP="...">
>           <SOAP:Header>
>             <eb:MessageHeader xmlns="...">...</eb:MessageHeader>
>             <eb:AckRequested xmlns:eb="..."
>                 SOAP:actor="http://.../next"
>                 SOAP:mustUnderstand="1"
>                 eb:signed="true|false"/>
>           </SOAP:Header>
>           <SOAP:Body>
>             <eb:Manifest xmlns:eb="..">...</eb:Manifest>
>           </SOAP:Body>
>         </SOAP:Envelope>
> 
> This approach is more consistent with SOAP and it eliminates the
> need to worry about ReliableMessagingMethod. It also provides for
> the Acknowledgment to be used for a foriegn specification for a reliable
> protocol that also used acknowledgments. For that matter, we could
> consider the AckRequested and Acknowledgment elements to be a
> SOAP module that is useful in and of itself. It could be essentially
> a self contained module with its own set of processing semantics
> specified, etc. IMO, this is a far cleaner and more modular approach.
> </cf>
> <db1>Chris I agree !! But is this a "bugfix" or an "enhancement" and
> therefore version 2.0. I really like it though. It is though inconsistent
> with your earlier suggested change to lines 1814-15.</db1>
> <cf1>
> It is no more of an enhancement than NAD. It isn't necessarily
> inconsistent, but it would be a different means of expressing
> the intent behind saying that an Acknowledgement message must
> have an Acknowledgment element. I'd be more than happy to craft
> this for consideration.
> </cf1>
> <db2>This is something we need to discuss on a call.<db2/>
> 
> >
> > 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>
> 
> <cf>
> I disagree for the reasons I've repeatedly cited. Absence of a received
> DR does NOT mean that the message hasn't been delivered. It only means that
> the sending party hasn't received a DR.
> 
> I would counter-propose the following:
> 
> - REQUIRE that ALL MSH nodes that receive a message with OnceAndOnlyOnce
>   deliverySemantics SHALL comply with the reliable messaging semantics
>   as defined in section 10. Further specify that any MSH node that
>   acts as an intermediary SHALL forward the message onto the next MSH
>   node using reliable messaging semantics as defined in section 10.
> 
> - REQUIRE that a DFN SHALL be sent to the From Party (section 10.4)
>   as requested by Marty if a message cannot be delivered.
> 
> - Clarify what "cannot be delivered", in section 10.4, means:
>         A message that is sent with deliverySemantics of OnceAndOnlyOnce
>         for which the MSH, after exhausting the specified number of
>         retries, separated by the specified retryInterval, has either
>         been unable to send (e.g. unable to establish a network connection
>         with the designated MSH node to which the message is to be
> delivered)
>         or for which no "Acknowledgment message" has been received.
> 
> - REQUIRE that a DR be delivered reliably (OnceAndOnlyOnce) if requested
> 
> - add a MSH "parameter" for DRTurnAroundTime or something like that
>   which the sending MSH uses to wait for a DR
> 
> - REQUIRE that the From Party's origin MSH notify the "From Party"
>   if the DRTurnAroundTime expires before receiving a DR
> 
> - let the "application layer" of software make the determination as
>   to whether or not it wants to resend the message, possibly using
>   an alternate delivery channel.
> 
> Please do keep in mind that a NRR/DR SHOULD be supported even if
> the deliverySemantics are BestEffort IMO. Let us not confuse these
> mechanisms.
> 
> Adding in the complexity of having to deal with intermediaries
> re-forwarding/processing messages for which no DR has been
> received would be a mistake IMO. It raises the bar on the complexity
> of an MSH considerably, especially for processing intermediaries
> as I have repeatedly pointed out.
> 
> If we stick with a store and forward, all nodes must adopt, protocol
> then if a message does not go through, there are WAY bigger problems
> than might be addressed by resending the message in any event.
> 
> </cf>
> <db1>Again I generally like the clean separation that your ideas suggest.
> However I have a couple of concerns.
> 1. It assumes a homogenous network where all the hops use ebXML. The real
> world will not be like this for a long time, if ever. However we don't want
> this to stop people using ebXML RM for some or all of the hops. Also suppose
> ebXML only goes as far as the mailroom. What happens after that? I suggest
> therefore the following as an alternative to your first para ...
> 
> "- REQUIRE that ALL MSH nodes that receive a message with OnceAndOnlyOnce
> deliverySemantics SHALL comply with the reliable messaging semantics as
> defined in section 10. Further specify that any MSH node that receives such
> a message SHALL forward the message onto another MSH node using reliable
> messaging semantics as defined in section 10 or use other processes that
> provide similar degrees of reliability."
> 
> <cf1>
> We discussed this in various f2f meetings and we concluded that the
> semantics ONLY applied between MSH nodes. If the message is passed through
> a pachinko (sp?) machine between MSH nodes, or through orange juice cans
> and strings, the sending MSH is still responsible for ensuring that
> the receiving MSH node gets it. We don't consider what happens in-between.
> SMTP is a good example. We don't care how SMTP moves the message from one
> end to the other, we only care about the MSH nodes that send and receive
> it.
> </cf1>
> <db2>
> I sense a disagreement here. I agree in the use case you suggest (i.e. SMTP)
> that the intermediaries can be ignored from a RM perspective. I was thinking
> though of another use case ...
> Suppose you have three parties, A, B and C. B is an intermediary. A & B
> agree to use ebXML. B and C agree to use the BizTalk Framework (which also
> supports reliable messaging). So you can get end-to-end reliable messaging
> as all hops are reliable. I think your words would not allow it because the
> second hop is not ebXML. How would you make this use case work?
> <db2/>
> 
> 2. I can see the benefit in making re-sends of a message because no DR has
> been received an application responsibility makes the spec cleaner. However:
> a) Marty has said words to the effect that unless you know that the message
> has been received (ie you have a DR) then you don't have RM.
> 
> <cf1>
> I respectfully disagree with Marty. MQSeries provides an application-level
> api that can be
> used to send a DR, but it is optional. That doesn't make MQSeries any
> less reliable. MQSeries nodes only concern themselves with ensuring that the
> message is safely persisted in the adjacent node/queue.
> </cf1>
> 
> b) You are increasing the burden on the application layer in that you are
> making it do the retries if an expected DR was not received.
> So if we don't include it in the v1.1 spec should we include it in v 2.0 or
> in a separate spec?
> </db1>
> <cf1>
> This is, IMO, a v2 issue at best, and possibly more of the perview of
> the BSI or BPF than anything MSH related. Again, there are larger
> issues at play here.
> </cf1>
> <db2>Chris. I think this is a question of scope. I covered this in an
> earlier email (see
> http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00422.html). In
> this email I suggested that:
> 1. Application level Delivery Receipts (as you describe) are out of scope as
> the are business process
> 2. To Party MSH to From Party MSH are in scope as:
>   a) Some legacy systems may not be able to generate an application level
> delivery receipt
>   b) Even if the application can generate a Delivery Receipt, it may not be
> able to generate it for some time (e.g. it is a batch overnight process) and
> the From Party does not want to wait until the application starts
> processing.
>   c) It provides useful assurance of delivery in the absence of an
> application level Delivery Receipt.
> 
> So I think we need both.
> 
> This then leaves the issue of whether it is in v 1.1 or v 2.0. Again we need
> to discuss on a conference call.
> <db2/>
> 
> >
> > 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 re
begin:vcard 
n:Ferris;Christopher
tel;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;;;;;
version:2.1
email;internet:chris.ferris@east.sun.com
title:Sr. Staff Engineer
fn:Christopher Ferris
end:vcard