Title:
Sorry for the HTML but we lose too much with plain text (colors, bolding,
fonts etc) I feel like I'm in the stone age.
David,
Question 1:
If I understand you right, the end-to-end RM is to rely on IM Delivery
Failure messages? No, that won't work. What if the Failure gets
lost. What if one IM can't do RM? We have to have a positive Ack
from end-to-end.
While the IM(s) might be willing to do RM this way, 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 -- the VAN guarantees to
get the message to the recipient within 3 hours or something like that
(SLA). This too is important to the sender and probably much more
important than the first timeout. There MUST be some
notification/acknowledgement to the sender that the receiver MSH has received
the message. This cannot be sent by the IM since there may be multiple
IMs. It must be sent by the To Party.
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. All IM RM is meaningless to the
Sender without this. I thought this was not a problem because
DeliveryReceipt was this Ack but I don't see DeliveryReceipt in section
10? That's why I'm asking this question.
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.)
Regards,
David.
-----Original Message-----
From: Burdett, David
[mailto:]
Sent: Thursday, August 09,
2001 11:32 AM
To: 'David Fischer'
Cc: Christopher Ferris
(E-mail)
Subject: RE: End to End RM
David
See
comments in-line.
David
-----Original Message-----
From: David Fischer
[mailto:]
Sent: Wednesday, August 08, 2001
10:52 PM
To: Burdett, David
Subject: FW: End to End
RM
I think I
know the answers, I just want to make sure you agree.
Question
1: To do RM end-to-end you request a DeliveryReceipt, or if RM is set
you MUST generate a DeliveryReceipt from To Party to From
Party.
[David B] You don't have to generate a
Delivery Receipt since if an intermediary fails to deliver a message to the
next MSH (or to the application if it is the To Party MSH), then
the MSH must return a "Delivery Failure" error message back to the "From
Party". This error message is a "negative ack". On the other hand, the
Delivery Receipt is a "positive ack" in that it is proof that the
message was delivered. Both are valid use cases and I don't think we
should, in the spec, force use of Delivery
Receipts.
Need to
change:
10.3.3 Generating
an Acknowledgement Message
An Acknowledgement
Message MUST be generated whenever a message is received
with:
· reliableMessagingMethod
set to ebXML (the default) and
·
deliverySemantics set to OnceAndOnlyOnce
In
addition a Delivery Receipt message containing the DeliveryReceipt element
MUST be generated and sent to the From Party MSH by the To Party MSH but not
by an Intermediate MSH.
As a minimum, these messages MUST contain a
MessageData element with a
RefToMessageId that contains the same value as the
MessageId element in the message being
acknowledged.
Need to make some
other similar changes to section 10 e.g. second paragraph should
be:
Reliability is achieved by a Receiving MSH responding to a
message with a Delivery Receipt, or in the case of an
Intermediate hop, with an Acknowledgment Message.
There is a problem with
this since with two types of Acks, the From Party will always receive Both
Acks. In a single-hop situation BOTH will be generated by the To
Party (not good)
[David B] Maybe, but if both acks are in the same message,
then it is no big deal.
while in a multi-hop situation the Ack
would come from the IM and the DR would come from the To Party (very
good). I don't know how the To Party MSH would know if the message
arrived via Single Hop or Multi-Hop since the Via with actor=next might not
be passed to the end.
[David B] He shouldn't need to know it just
follows the instructions in the
message.
SOAP
1.1 Section 4.2.2
/snip... That is, a receiptient receiving a header element MUST NOT
forward that header element to the next application in the SOAP
message path. The receipient MAY insert a similar header element
but
in that case, the contract is between that application and the
receipient of that header element.
The problem above can
be solved by specifying somewhere in the spec that ALL ebXML headers MUST be
forwarded to the next application. I don't see that anywhere?
(Did I just miss it?)
[David B] I think we discussed this.
Chris should be able to better advise on this - I'll copy him on this
email
If we do this then the From Party can
refrain from sending Acks if there is no Via (or TraceHeaderList
etc.)
Question 2: There is no
way to stop an IM from changing the value of AckRequested (for instance in
the case of an IM hop using MQseries) and when the IM does this, it will be
changed for all subsequent hops.
[David
B] Correct, but I don't think this is an issue as if you are using
MQ Series you don't need the ack. If Delivery Semantics is OnceAndOnlyOnce,
then any intermediary MSH which receives a message knows that they should
forward the message using a reliable messaging protocol of some
kind.
This is due to the
actor=next on Via. There are two possible fixes. 1) forbid any
change or 2) move AckRequested out of Via. In the first choice, if it
doesn't change then why is it in Via?
[David B] It
can change as previously described.
So the second answer is really the
only answer. AckRequested needs to go in QualityOfServiceInfo.
The question must then be asked, will AckRequested ever be different than
DeliveryReceiptRequested? Although some obscure case might be made, I
doubt it. There will however be cases where a local CPA might override
this value. Is there then any real reason to have two request
parameters? Let's just get rid of AckRequested and use
DeliveryReceiptRequested for both DeliveryReceipts and Acknowledgements
(change to ReceiptRequested?) and make these two types of
"Acknowledgement Messages" fairly synonomous in the spec.
[David B] You
can't rely on just Delivery Receipts as if there is an intermediary who
stores a message before forwarding it then the From Party might time out
waiting for the Delivery Receipt and assume the delivery failed when
actually there are no problems at all. Because you can have different
transport protocols with different timing characteristics you need to make
each hop reliable so that the retry behavior can stop within a
reasonable time. For example if you are using HTTP you could retryt for
say 5 minutes before giving up, but if the next hop is SMTP going you might
want to wait three hours. As the original sender may have no idea what
transport will be used for all the hops they cannot set a reasonable time
out. If they assume that some link is slow (e.g. SMTP) but the first link is
HTTP then they would not trap an HTTP failure for potentially
hours.
Question 2:
Another answer might be that Acks are part of RM and they fall under section
10.3.3 which says an Ack MUST be generated if
DeliverySemantics=OnceAndOnlyOnce & ReliableMessagingMethod=ebXML.
Therefore do we need AckRequested at all since we can deduce the need for an
Ack based on this criteria? Again, let's get rid of
AckRequested.
[David B] This is an idea that could be worth
considering.
What do you
think?
Regards,
David.
-----Original Message-----
From: David
Fischer [mailto:]
Sent: Wednesday, August 08, 2001
9:39 PM
To: David Burdett
Cc: ebXML Msg
Subject: End to End
RM
Was (RE: T2 SyncReply and ReliableMessagingMethod in
QualityOfServiceInfo)
Thanks, David, that was long!
The
answer to my questions is probably somewhere in there but I may have
gotten
lost.
Question 1: How do we do end-to-end RM
irrespective of IM RM, i.e. how do we
request an end-to-end Ack? Is
it the DeliveryReceipt or is there something
else?
Question 2: In
a multi-hop situation (more than one IM) how do we avoid having
the IM
change AckRequested and thus have the wrong value for all
subsequent
hops?
David Fischer
Drummond
Group.
------------------------------------------------------------------
To
unsubscribe from this elist send a message with the single
word
"unsubscribe" in the body to:
