[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] Proposal for i004
I think that two notions need be clearly
distinguished: 1. what a duplicate is. 2. what a "retransmission" is,
or should be w/r to the duties of the RMS or to its scope of action. Regarding (1), I think that we are in
agreement that a duplicate is solely detected based on sequenceID/number. Regarding (2), as Anish said there is
still an implicit contract that a retransmitted message be "equivalent"
to the original, not just a message with same RM headers. Now I believe that any developer with a
sound mind understands how to implement an RMS so that within its scope of
responsibility, (2) will be achieved the best it can. However, some header
elements such as wsa:MessageID are on the borderline of what application
semantics is, and could be interpreted either in or out of the contract (2). The
simple fact that issue i004 was raised, indicates an ambiguous situation. I can
see that some RMS developer with the current text, may rightfully decide to
alter wsa:MessageID. But preserving wsa:MessageID is key to the
composability of WS-RM. A processing module upstream to RMS (lets call it "PSource")
that has added the wsa:messageID header, may need to be assured that the
message that has reached its destination counterpart ("PDest"), has
the same wsa:messageID as the one it has sent. I think it is worth an explicit statement. Avoiding the minefield of trying to define
"equivalent" messages, a minimal proposal I would back for i004 is
one where it is clear to implementers that an RMS must not alter wsa:messageId
when retransmitting. Now, it is also in the scope of this specification
(RM Policy Assertion) to define precisely (enough) the semantics of the
concepts expressed in policy assertions, including "retransmission".
Being more precise than the current text without being too tight, a definition "by
intent" could be like: "Retransmission is an operation that ensures
that the retransmitted message has the same effect on its consumer as the
original message would have, given the expected processing up to consumption
and all other things being equal." I think a definition like this would be an
improvement, but that does not remove the need to separately disambiguate the
case of wsa:messageID. Jacques From: I think
Anish has a point. - also,
that may affect the validity of signatures. In 6.3 of SOAP Binding for
WS-Addressing, there is clear requirement that "To avoid breaking
signatures,intermediaries MUST NOT change the XML representation of
WS-Addressing headers when relaying those headers." The RMS may act as
intermediary, and resending is just a relaying technique... Jacques
-----Original
Message----- Marc,
The
reference you have provided is the submission document. That The spec
does not say anything about the content of the message on But I'm
curious as to why you used a 'may' in your proposal. Do you see My
concern about [message id] is that: In any
case, reliability is based on the fact that the receiver can -Anish
[1] http://www.w3.org/TR/2005/CR-ws-addr-core-20050817/
Marc
Goodner wrote: |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]