RE: T2 PLEAE READ - Suggested solution to RM Issues

[David Fischer <david@drummondgroup.com>]

David, Chris,

I don't think the "DR required on deliverySemantics=1&O1" needs to wait.  Since
DR can be requested by DeliveryReceiptRequested then the same functionality can
be achieved either way.  I say let's drop this change.  This does mean however
than the (default) value of "None" will still be needed on
DeliveryReceiptRequested.

The reason we dropped the value of "None" on ackRequested is because of the
potential for a parameter mis-match if ackRequested="None" and
deliverySemantics=1&O1.

I think this is Chris's position.  Anyone object?

David Fischer
Drummond Group.

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Friday, September 07, 2001 5:47 PM
To: 'christopher ferris'; ebXML Messaging (E-mail)
Subject: RE: T2 PLEAE READ - Suggested solution to RM Issues


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 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>

<cf>
As I said above, this raises the bar on complexity. You cannot use the
same retries/retryInterval as for single-hop for starters. Consider a
long chain of intermediaries which may have the ultimate recipient receiving
the message after a significant passage of time for which the sending
node wants to simply know when to stop resending (or trying to resend)
the messsage to the first intermediate node.
</cf>
<db1>No further comment</db1>

>
> 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>

<cf>
Please see my proposal above.
</cf>
<db1>Noted</db1>
>
> 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>

<cf>
Agreed. However, I think that both DR and DFN should be delivered
reliably. No DR for a DR though.
</cf>
<db1>I agree.</db1>
>
> 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>
>
> ----------------------------------------------------------------
> 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>

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>