Re: T2, Proposed solution for ... Re: SyncReply and ReliableMessagingMethod in QualityOfServiceInfo

[Arvola Chan <arvola@tibco.com>]

David:

My comments are bracketed by <ac> and </ac>.

Cheers,
-Arvola

----- Original Message -----
From: "David Fischer" <david@drummondgroup.com>
To: "Arvola Chan" <arvola@tibco.com>; "Burdett David"
<david.burdett@commerceone.com>
Cc: "ebXML Messaging (E-mail)" <ebxml-msg@lists.oasis-open.org>
Sent: Sunday, August 12, 2001 2:33 PM
Subject: RE: T2, Proposed solution for ... Re: SyncReply and
ReliableMessaging Method in QualityOfServiceInfo


> Arvola,
>
> What if I am sending to you and you are using an IM for some reason, e.g.
no
> persistent connection?  I might not even know and since I have no
agreement with
> that IM (my agreement is only with you), I cannot be responsible for
putting the
> CPAid in the Via -- there is no CPAid.  What I can do is fill in the Via
fields
> as much as I am able in case there is an IM I am not aware of.  This, IMO
will
> be a very common use case.
>
> This exact same situation would arise if you used multiple MSHs where one
was a
> mailroom.
>

<ac>
I must admit that your use case is a very valid one and I have not made
provision for
it.

Come to think of it, when I suggested that the sender MSH should dictate if
all intermediaries
should use reliable message or not at all, it is not strictly necessary for
the sender MSH to
know that intermediaries are involved, all it is choosing is between
reliable message with
intermediate Acks vs reliable messaging without intermediate Acks.

As you have indicated earlier, "Even though the ends don't need to know
about the IMs,
 it is critical that the IMs realize their role." There, the IMs should be
able to respect the
directive from the sender MSH to use intermediate Acks or not.
</ac>

> You are correct, I need to be more clear.  I believe the sender MSH would
> construct the Via.  This Via would pass to the first IM MSH who would
construct
> a new Via (possibly very similar to the original) and pass this new Via to
the
> next hop's MSH.
>
> NEW PROBLEM WITH MULTI-HOP?
> This brings up a good point.  I (the From Party MSH) know how to send to
you
> (the To Party MSH) because I can look up your connection info in the CPA
> Database based upon a CPAid and a ChannelID.  This info might not reside
in the
> To PartyID element.  If my message goes through an IM, how does the IM
know
> where to send?  I don't send to you, I send to my IM.  If I am using an
IM, does
> that mean any time I make an entry in my database I also have to duplicate
that
> info to my IM (and they to each of their IMs etc.)?  This would not be
> acceptable.  Maybe this connection info MUST reside in the To PartyID?
This
> would not be a problem for single-hop.  Maybe the Receiver connection info
needs
> to be put in the Via?
>

<ac>
I agree with you this is a problem. The intermediary needs to be configured
with the
Endpoint and various characteristics for the To Party (or the Endpoint for
yet another
intermediary who can route messages to the To Party directly or indirectly
and its
characteristics). My understanding is that CPPs and CPAs currently deal only
with
the point to point case. Therefore, there is no automated way to configure
intermediaries
using CPAs. This is something the CPP/A TC will have to address in its 2.0
spec.
</ac>

> Regards,
>
> David Fischer
> Drummond Group.
>
> -----Original Message-----
> From: Arvola Chan [mailto:arvola@tibco.com]
> Sent: Sunday, August 12, 2001 1:16 PM
> To: David Fischer; Burdett David
> Cc: ebXML Messaging (E-mail)
> Subject: Re: T2, Proposed solution for ... Re: SyncReply and
> ReliableMessaging Method in QualityOfServiceInfo
>
>
> David:
>
> Please see below.
>
> -Arvola
>
> ----- Original Message -----
> From: "David Fischer" <david@drummondgroup.com>
> To: "Arvola Chan" <arvola@tibco.com>; "Burdett David"
> <david.burdett@commerceone.com>
> Cc: "ebXML Messaging (E-mail)" <ebxml-msg@lists.oasis-open.org>
> Sent: Saturday, August 11, 2001 12:00 AM
> Subject: RE: T2, Proposed solution for ... Re: SyncReply and
> ReliableMessaging Method in QualityOfServiceInfo
>
>
> > Arvola, I think we cannot assume the sender is cognizant of the IMs.  If
> the
> > proper info is ALWAYS put in Via (NAD) then it wouldn't matter if the
> sender
> > knows of the IM.  I guess I am moving/leaning toward always having VIA.
> Much of
> > the required info will reside in IM CPAs or the equivalent.
> >
> > Take a case of Wal-Mart using C1 as its IM.  I might send to Wal-Mart
> using a
> > CPAid of uri:www.walmart.com-001 yet I might lookup and make an HTTP
POST
> to
> > http://www.c1.com/ebxml/receive but since this is all automatic, there
is
> no
> > human to look at the difference and realize I have an IM.  From the MSH
> > perspective this is just a lookup procedure.  It can't know it is not
> sending
> > directly to Wal-Mart (actually neither can a human, even though it might
> > outwardly appear that way).
> >
>
> <ac>
> Are you equating the sender with the From Party as opposed to the From
Party
> MSH? Either the From Party or the From Party MSH has to construct a
> Via element for the outbound message. The Via element contains an optional
> CPAId. If the message is going through an intermediary, then wouldn't it
be
> necessary to use a CPAId here that is different from the CPAId in the
> MessageHeader element? Therefore, my contention is that the sender and/or
> the
> sender MSH is cognizant of the fact that an intermediary is involved. I
> agree that
> the sender and/or the sender MSH cannot necessarily tell the exact number
of
> intermediaries that may be involved.
>
> In the case of the To Party MSH, again it should be able to tell from the
> CPAId in
> the MessageHeader element and the CPAId in the Via element (if present)
that
> the
> message is coming through an intermediary. Alternatively, the length of
the
> trace
> header list should indicate if intermediaries have been involved.
> </ac>
>
> > End-To-End RM has to work exactly the same way with or without any IMs.
> The
> > only difference might be whether to send back an Ack.  Even if a
> single-hop sent
> > back an Ack and DR, it wouldn't really matter, especially if they are in
> the
> > same message.  All MSHs have to silently support multiple/duplicate
Acks.
> The
> > problem is what if you get a success and then later a failure on the
same
> > message?  I think you assume the failure was slow and got past by the
> success,
> > so just accept the success.
> >
>
> <ac>
> I think reliable messaging without intermediary is an important use case
> that we
> should optimize for.  In that case, either a DR should imply an Ack or
both
> the
> Ack and the DR should be returned in the same message. Regardless of
whether
> intermediaries are involved, the sender should not consider the reliable
> message successfully delivered until it has received both a corresponding
> Ack and DR.
>
> The sender only needs to retry if the Ack is not received. This assumes
that
> the
> sender dictates whether all intermediaries use reliable messaging, or none
> of them
> does. If an Ack has been received but no DR has been received, then it
must
> be
> the case that one or more intermediaries are involved. Since the first
> intermediary
> has received the message OK and all intermediaries are expected to use
> reliable
> messaging in this case, the sender should just wait for the eventual
arrival
> of the
> DR. There needs to be a timeout for the DR. This has to be in the CPA or
> perhaps derived from ((retry + 1) * retryInterval).
>
> My opinion is that change 8 in David Burdett's proposal is somewhat
> complicated.
> It will also be expensive if digital signatures need to be recomputed.
> </ac>
>
> > Even though the ends don't need to know about the IMs, it is critical
that
> the
> > IMs realize their role.  I don't think this is an issue though since
they
> can
> > see they are not the From or the To.
> >
> >
> > Regards,
> >
> > David Fischer
> > Drummond Group.
> >
> > -----Original Message-----
> > From: Arvola Chan [mailto:arvola@tibco.com]
> > Sent: Saturday, August 11, 2001 12:51 AM
> > To: David Fischer; Burdett David; ebXML CPPA (E-mail)
> > Cc: ebXML Messaging (E-mail)
> > Subject: Re: T2, Proposed solution for ... Re: SyncReply and
> > ReliableMessaging Method in QualityOfServiceInfo
> >
> >
> > David and David:
> >
> > In general, the proposal looks very reasonable to me. My comments are
> inline
> > bracketed by <ac> and </ac>.
> >
> > -Arvola
> >
> > ----- Original Message -----
> > From: "David Fischer" <david@drummondgroup.com>
> > To: "Burdett, David" <david.burdett@commerceone.com>; "ebXML CPPA
> (E-mail)"
> > <ebxml-cppa@lists.oasis-open.org>
> > Cc: "ebXML Messaging (E-mail)" <ebxml-msg@lists.oasis-open.org>
> > Sent: Friday, August 10, 2001 4:38 PM
> > Subject: RE: T2, Proposed solution for ... Re: SyncReply and
> > ReliableMessaging Method in QualityOfServiceInfo
> >
> >
> > > Very good!
> > >
> > > I have a couple of questions (no surprise) <df>in-line</df>.
> > >
> > > Regards,
> > >
> > > David Fischer
> > > Drummond Group.
> > >
> > > -----Original Message-----
> > > From: Burdett, David [mailto:david.burdett@commerceone.com]
> > > Sent: Friday, August 10, 2001 5:25 PM
> > > To: ebXML CPPA (E-mail)
> > > Cc: ebXML Messaging (E-mail)
> > > Subject: FW: T2, Proposed solution for ... Re: SyncReply and
> > > ReliableMessa ging Method in QualityOfServiceInfo
> > >
> > >
> > > I'm forwarding this email to the CPPA list as it contains some
suggested
> > > changes for thinking about intermediaries which are relevant to the
CPPA
> > > discussion.
> > >
> > > I'm also reposting to the ebXML Messaging list as I omitted two
> > attachments
> > > from the original post.
> > >
> > > David
> > >
> > >
> > > -----Original Message-----
> > > From: Burdett, David
> > > Sent: Friday, August 10, 2001 3:18 PM
> > > To: 'Arvola Chan'; Fischer, John
> > > Cc: ebXML Messaging (E-mail)
> > > Subject: T2, Proposed solution for ... Re: SyncReply and
> > > ReliableMessaging Method in QualityOfServiceInfo
> > >
> > >
> > > Arvola/David F
> > >
> > > I have some ideas for a few changes that might solve the problems
raised
> > in
> > > this thread so the rest of this email contains:
> > > 1. Extracts from a number of recent emails from you both and analysis
of
> > the
> > > issues/requirements they raise
> > > 2. Some additional further analysis of the issues to identify a few
more
> > > requirements
> > > 3. A proposed solution to meeting the identified requirements which
> > > hopefully will solve the problem ... and who knows perhaps bring this
> > email
> > > thread to an end :-)
> > >
> > > So please let me know if:
> > > a) I've missed a requirement
> > > b) You (or anyone else) think the proposed solutiuon is wrong or could
> be
> > > improved ... but then I know you will anyway ;)
> > >
> > > Details below
> > >
> > > David
> > > ******************************
> > > EMAIL THREAD and ISSUES/REQUIREMENTS
> > > ====================================
> > >
> > > Arvola Chan: Thu 8/9/2001 3:28 PM
> > > ---------------------------------
> > > >>I am of the opinion that the DeliveryReceipt element should be used
by
> > the
> > > ToParty MSH to inform the FromParty MSH that a reliable message has
been
> > > received. ... It is the non-arrival of a DeliveryReceipt that requries
> the
> > > MSH to notify the application. In this case, it must rely on
persistent
> > > information to determine the application service that must be
> notified.<<
> > >
> > > >>I think end to end acknowledgement is always needed to support
> reliable
> > > messaging, so it is unnecessary to explicitly set
> deliveryReceiptRequested
> > > to true, it should always be implied by deliverySemantics of
> > > OnceAndOnlyOnce. On the other hand, if intermediary acks are optional,
> > then
> > > ackRequested needs to be an explicit attribute at the QOS level and it
> > > should apply to all intermediaries.<<
> > >
> > > [DavidB]This highlights a number of issues/requirements:
> > > Req 1. A positive Ack sent back to the sender of a message by the
> ultimate
> > > destination is the only sure way the sender can be certain the message
> was
> > > delivered. If no Delivery Receipt is sent, then the sender cannot be
so
> > > certain.
> > > Req 2. If end-to-end Delivery Receipts are always required for the
> sender
> > to
> > > be certain, then it would be simpler if there was a rule that
> > > deliverySemantics of OnceAndOnlyOnce implies a Delivery Receipt is
sent.
> > The
> > > only remaining issue is whether or not the Delivery Receipt should be
> > > signed.
> > >
> > > David Fischer: Thu 8/9/2001 7:31 PM
> > > -----------------------------------
> > > >>Question 1 ... the end-to-end MUST be able to do RM as if it does
not
> > know
> > > (which it probably doesn't) what the IM(s) are doing.  The end-to-end
> > > probably doesn't care if the IM(s) are doing RM at all (even though
each
> > IM
> > > might care very much)<<
> > >
> > > >>On the issue of Sender time outs and retries, their are two kinds:
1)
> a
> > > timeout to the first IM and 2) a timeout getting to the end.  The
first
> is
> > > easy and obvious so we don't need to discuss it.  The second is a
> > timeframe
> > > that is usually contractually guaranteed ...<<
> > >
> > > >>While the Sender/Receiver may not have any idea what path or IM
> > transport
> > > the message is taking (and they really don't need to) they must have
an
> > idea
> > > about delivery times to the end.  We MUST generate some kind of an
> > > end-to-end Ack allowing the ends to do RM.<<
> > >
> > > >>Proposal:
> > > 1) We need to update section 10 with end-to-end RM (deliveryReceipt or
> > > something new that is similar to Acknowledgement).
> > > 2) We need to put in the spec somewhere that ALL MessageHeaders
> (including
> > > Via) MUST be passed to the next hop, including the end.<<
> > >
> > > >>Question 2 ... I agree that it doesn't matter if ackRequested gets
> > changed
> > > because an Ack gets sent based upon DeliverySemantics (This was my
> second
> > > solution to Question 2).  Why then do we have ackRequested?  The only
> way
> > it
> > > would change is if there was some kind of local CPA overriding
> > ackRequested.
> > > If RM is requested and an IM can do RM then it MUST, right?  Then why
> have
> > > this parameter?  (I see from your comments that you are considering
> this.)
> > > <<
> > >
> > > [DavidB]This highlights a number of issues/requirements:
> > > Req 3. The sender should not know nor care if an IM is being used and
> > > whether or not they are doing RM with the next IM.
> >
> > <ac>
> > The sender application may not care if an IM is being used. The sender
MSH
> > certainly has to know if it has to construct the Via element in order to
> > route
> > the message to an IM.
> >
> > I think it may be a little simpler if the sender MSH dictates in the QOS
> > whether all
> > intermediaries use reliable messaging or not at all. If reliable
messaging
> > is used in
> > every hop, then the sender MSH only needs to retry if it does not
receive
> an
> > ack from
> > the next MSH. Once such an ack is received, it can wait for the delivery
> > receipt
> > from the to party MSH. If this is not received in time, it can simply
> notify
> > the
> > sender application of the delivery failure.
> >
> > If none of the intermediaries use reliable messaging, and the receiver
MSH
> > does
> > not return a delivery receipt in time, then it is the responsibility of
> the
> > sender MSH
> > to retry.
> >
> > This is the approach described in the 0.93 version of the TRP spec. I
> think
> > it
> > is simpler because only a single set of retry related parameters is
> needed.
> > It also
> > make logical sense to have the sender specify the quality of service
> > desired, i.e.,
> > reliable messaging with or without intermediate acknowledgements.
> > </ac>
> >
> > > Req 4. There are two different types of "acks" that are useful:
> > >   a) It's been accepted by the postal system (i.e. the next MSH has
> > > received, this is the Acknowledgement Message)
> > >   b) It's been received by the final destination (i.e. the To Party
has
> > > received it, this is the Delivery Receipt)
> > > Req 5. Even if the initial Ack (i.e. Acknowledgment Message) is
received
> > > there needs to be some method of automated retry if the Delivery
Receipt
> > is
> > > not received within the expected timeframe.
> >
> > <ac>
> > My recommendation is to retry on time out waiting for the Delivery
Receipt
> > only
> > in the case of not using intermediate acknowledgements.
> > </ac>
> >
> > > Req 6. If you a doing reliable messaging between two hops, then you do
> not
> > > need ackReqeusted as an acknowledgment must be sent if the ebXML RM
> > protocol
> > > is being sent and not needed if it isn't.
> > >
> > > David Fischer: Thu 8/9/2001 8:02 PM
> > > -----------------------------------
> > > >>I am concerned that end-to-end RM is taking a back seat to IM RM.
> This
> > is
> > > the opposite of how it should be.  Most transactions will be
single-hop.
> > > Many other cases will be single IM where the sender or receiver may
not
> > even
> > > know there is an IM so it still appears to be single-hop.  The ends
> should
> > > not even have to know about the IMs.  Ends will always do automatic
> > retries.
> > > RM should work for the ends in exactly the same manner whether or not
> > there
> > > are IMs.<<
> > >
> > > [DavidB]This really just provides further support for
> issues/requirements
> > > numbered 3 and 5 above.
> > >
> > > Arvola Chan: Fri 8/10/2001 12:23 AM
> > > -----------------------------------
> > > >>Even if you have a channel that calls for the use of synchronous
reply
> > > mode, the syncReply attribute still has to be set. In other words, it
is
> > > still necessary to use the Via element if the syncReply attribute is
> > present
> > > only there, but this constradicts the assumption that the Via element
is
> > > only used when intermediaries are involved.<<
> > >
> > > [DavidB]This highlights a number of issues/requirements:
> > > Req 7. The syncReply needs to be set at the message level whether or
not
> > an
> > > intermediary is being used
> > > Req 8. There is a contradiction in the spec (which therefore needs to
be
> > > removed) that the Via element is only for intermediaries when it is
> > actually
> > > also needed for non-intermediaries.
> > >
> > > DAVID BURDETT's COMMENTS
> > > ========================
> > > Before proposing a resolution to all these requirements I'd like to
make
> a
> > > few comments and identify an additional couple of requirements.
> > >
> > > Firstly on Requirement 6 above (you don't need ackRequested). There
> could
> > be
> > > benefit in gettingan acknowledgement element back even if you are
using
> a
> > > reliable messaging protocol such as MQ Series as you then have
evidence
> > > (especially if it is signed) that the next MSH has received the
message.
> > I'm
> > > not convinced though that this is a huge benefit.
> > >
> > > Secondly if we put syncReply at the message level then there is an
> > > additional requirement ...
> > > Req 9. The next recipient of a message needs to know whether or not to
> > > return an acknowledgement message synchronously or not.
> > >
> > > Now for the proposed solution.
> > >
> > > PROPOSED SOLUTION
> > > =================
> > > The solution dsecribed below refers to the requirements identified
above
> > ...
> > >
> > > 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 (also posted here) 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.
> > >
> > > 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 we think of the
> data
> > > in the Via as being for the "Next Actor" then we are 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.
> > >
> > > This change addresses Req 3 and 8.
> > > <df> agreed </df>
> > >
> >
> > <ac>
> > I also agree.
> > </ac>
> >
> > > 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.
> > > 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.
> > >
> > > This change addresses Req 3, 4a
> > > <df> agreed, does the first IM send an Ack back to the From Party MSH?
> > does the
> > > To Party MSH send an ack back to the last IM MSH? The first IM would
> send
> > an Ack
> > > back to the From Party without being asked so the From Party needs to
> > understand
> > > this was an Ack not a DR.
> >
> > <ac>
> > Since Acknowledgement and DeliveryReceipt are separate elements, there
> > should
> > not be any confusion.
> > </ac>
> >
> > > The To Party would send a DR based on the presence of
> > > deliverySemantics=1&o1 and then if there was a Via (NAD) it would also
> > send an
> > > Ack (could be in the same message).
> >
> > <ac>
> > If no intermediary is involved, the To Party MSH only needs to return a
> > DeliveryReceipt. There is no need to return an (intermediate)
> > Acknowledgement.
> > The Via element can be present even if no intermediary is involved. See
> Req
> > 8
> > above.
> > </ac>
> >
> > > Why isn't TraceHeaderList a sub of Via?
> > > Never mind -- too late. </df>
> > >
> > > Change 3
> > > --------
> > > Summary: Make the return of a Delivery Receipt required if
> > > deliverySemantics=OnceAndOnlyOnce
> > > <df> agreed </df>
> > >
> >
> > <ac>
> > I also agree.
> > </ac>
> >
> > > Change 4
> > > --------
> > > Summary: Replace deliveryReceiptRequested by deliverReceiptSigned=true
> or
> > > 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.
> > >
> > > These changes address Reqs 1, 2, 4b
> > > <df> agreed  What about the requirement that
> > reliableMessagingMethod=ebxml?  Can
> > > we drop that?  What would it mean if deliverySemantics=BestEffort and
> > > DeliveryReceiptSigned=signed|unsigned? </df>
> > >
> >
> > <ac>
> > I think it would be inconsistent to specify BestEffort delivery and yet
> ask
> > for
> > a delivery receipt. Perhaps the receiving MSH should return an error.
> > </ac>
> >
> > > Change 5
> > > --------
> > > Summary: Make the return of an Acknowledgment element in a message
> > required
> > > if the ebXML RM protocol is being used
> >
> > <ac>
> > I agree. I would also prefer to rename this as IntermediateAck, and use
it
> > only
> > when intermediaries are involved.
> > </ac>
> >
> > > Change 6
> > > --------
> > > Summary: Replace ackRequested by ackSigned=true or false(the default)
> > >
> > > Rationale: The rationale for doing this is similar to changes 3 and 4.
> 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 9 below).
> > > <df> agreed.  Same comments as DeliveryReceiptSigned </df>
> > >
> >
> > <ac>
> > I agree. I would also prefer to rename this as IntermediateAckSigned.
> > </ac>
> >
> > > Change 7
> > > --------
> > > Summary: Include automated retry by the original sender (From Party)
if
> no
> > > Delivery Receipt is returned
> > > <df> agreed.  Need to be careful since the retryInterval specified in
> the
> > CPA is
> > > end-to-end and there is no IM retryInterval (probably need one). </df>
> > >
> >
> > </ac>
> > Please see my earlier comments about Req 3. I think retry is called for
> only
> > in
> > case intermediate acks are not used.
> > </ac>
> >
> > > Change 8
> > > --------
> > > Summary: Include "ResendOfMessageId" 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
> > > cannot send the **identical** message as it will be treated as a
> duplicate
> > > and therefore ignored by any intermediate MSH that has previously
> received
> > > it. To solve this problem the from party needs to use a different
> > MessageId.
> > > However there is now a need to stop the message being treated as a
> > > completely new message. To solve this problem we could add a
> > > "ResendOfMessageId" element that identifies which message the new
> message
> > is
> > > a resend of. 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 and therefore the original
should
> > be
> > > ignored. This logic needs to be included in section 10 and probably
> needs
> > a
> > > bit more thinking through.
> > >
> > > These changes addresses Req 5
> > > <df> How does the Sender know to use this?  The sender may not know
> there
> > is an
> > > IM.  I understand the problem, I'm just not sure this is the right
> > solution.  I
> > > think the Sender must be allowed to send the **identical** message.  A
> > duplicate
> > > at the IM is not the same as a duplicate at the To Party MSH.  The
> > presence of a
> > > duplicate at the IM should signal a problem, not necessarily stop the
> > message.
> > > Have to think about this more.  What about always including a retry
> > number?
> > > </df>
> > >
> >
> > <ac>
> > This change would not be necessary if the sender MSH dictates whether
> > intermediate
> > acks are used by all intermediaries or not at all.
> > </ac>
> >
> > > Change 9
> > > --------
> > > 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 via.
> > >
> > > This change adresses Reqs 7 and 9.
> > > <df> agreed.  Might have an Ack in there too.  I still like changing
> > > Acknowledgement to Ack.
> > >
> > > Good Plan.</df>
> > >
> >
> > <ac>
> > I also agree.
> > </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 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
>