Doug:
Staying out of the murky waters of retransmission
semantics:
Plain and simple, I actually see
issue i004 as being about composability with WS-Addressing: if a node
XYZ that has added the wsa:MessageID header is composed with RMS (and before
it) , then if the RMS generates a new wsa:MessageID for each retransmission,
clearly that makes it impossible for XYZ to rely on wsa:RelatesTo in a received
response message (the wsa:MessageID it refers to may be different from the original
one.)
Now, should we bother warning about
this in the spec? I think so: it is not just about dealing with a broader
bucket of bits, but affects composability with WS-A (in charter). I
suspect many developers might face the same question as Steve who raised this
issue: without additional guidance, it is perfectly legitimate for them to
treat retransmissions as new messages that must be "uniquely identified
in time and space" according to WS-Addressing - and to restrict composability
when doing so.
Now, WS-A says: "A
message MAY be retransmitted for any purpose including communications failure
and MAY use the same [message id] property." But again, that is just a MAY. The one thing that an RMS developer understands
when reading that statement, is that it is OK to manipulate this header when
retransmitting. So I am in favor of either warning about manipulating this
header in RMS, or just prohibiting this.
Jacques
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Thursday, August 25, 2005
4:34 PM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] Proposal for
i004
I would not be comfortable with this because it implies
some understanding on the part of the RMS
on
what the intent/meaning... of the message is. It also implies there is a
certain bucket of bits
that
RM considers important when comparing two messages (e.g. wsa:MessageID), and I
don't
believe
RM should get into that business. I would much prefer if RM remained
silent anything
having
to deal with the content of the message with the exception of the RM headers
which are
clearly
under its control.
To
that end, for retransmission the RM spec should simply say that the SeqID +
Msg# need to be
the
same. Scanning the spec I'm not sure if actually says that but I think
it does imply it. If it says it
then
I don't think any change is needed. If it doesn't actually come right out
and say it then we should
add
the appropriate text (to section 3.1 perhaps?)
thanks,
-Doug
Jacques Durand
<JDurand@us.fujitsu.com> wrote on 08/25/2005 06:31:31 PM:
> 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: Jacques
Durand
> Sent: Thursday, August 25, 2005 11:26 AM
> To: 'Anish Karmarkar'; Marc Goodner
> Cc: ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] Proposal for i004
>
> I think
Anish has a point.
> I believe that Resending MUST not alter
wsa:messageId, nor anything in the SOAP envelope.
> - wsa:messageId may have some relevance w/r
to MEPs, and whoever on the Sender side
> will verify that a wsa:RelatedTo is
correlating with a previous wsa:messageId must
> be sure of the messageId that has been
received, regardless of which retry made it
> to the RMD. If messageId may be altered by
the RMS or further intermediary, that won't work.
> - 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-----
> From: Anish Karmarkar
[mailto:Anish.Karmarkar@oracle.com]
> Sent: Thursday, August 25, 2005 10:46 AM
> To: Marc Goodner
> Cc: ws-rx@lists.oasis-open.org
> Subject: Re: [ws-rx] Proposal for i004
> Marc,
> The
reference you have provided is the submission document. That
> sentence has been removed from the CR docs
[1] [2].
> The
spec does not say anything about the content of the message on
> retransmission and I don't see [message id]
as being special (as far as
> WSRM is concerned). Therefore, I don't see
any reason to say anything
> specific about [message id].
> But I'm
curious as to why you used a 'may' in your proposal. Do you see
> any reason why this [message id] would be
different? I had assumed
> (since the spec does not say) that the
retransmission would have the
> same message content at the Infoset level. Do
you see it otherwise?
> My
concern about [message id] is that:
> a particular message may be part of an MEP
(such as a request message in
> a req-res MEP). The reply message then has to
use the [message id] of
> the request message in its [relationship]
property. This is used to
> correlate the reply message with the request
message. If the [message
> id] on retransmission is changed by the RM
layer this will lead to problems.
> In any
case, reliability is based on the fact that the receiver can
> detect duplicates (based on seq id/message
no) and duplicates are copies
> of the same message and can be discarded by
the receiver.
> -Anish
> --
> [1]
http://www.w3.org/TR/2005/CR-ws-addr-core-20050817/
> [2]
http://www.w3.org/TR/2005/CR-ws-addr-soap-20050817/
> Marc
Goodner wrote:
> > "A message MAY be retransmitted for
any purpose including communications
> > failure and MAY use the same [message
id] property."
> >
> >
http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/#_Toc77464
> > 322
> >
> > So as I said no further clarification
should be needed in WS-RM.
> >
> > -----Original Message-----
> > From: Anish Karmarkar
[mailto:Anish.Karmarkar@oracle.com]
> > Sent: Thursday, August 25, 2005 12:29 AM
> > To: Marc Goodner
> > Cc: ws-rx@lists.oasis-open.org
> > Subject: Re: [ws-rx] Proposal for i004
> >
> > Marc Goodner wrote:
> >
> >>I've looked into this issue and I
believe it is not an issue and
> >
> > should
> >
> >>be closed as follows.
> >>
> >>
> >>
> >>Proposal:
> >>
> >>Web Services Addressing says that the
wsa:messageID may be the same
> >
> > for
> >
> >>a retransmitted message. Therefore
when a message is retransmitted
> >
> > with
> >
> >>the same wsrm:{Identifier,
MessageNumber} pair the wsa:messageID may
> >
> > be
> >
> >>the same. The correct use of
wsa:messageID need not be redocumented in
> >
> >
> >>this specification therefore this
issue should be closed with no
> >
> > action.
> >
> >
> > Shouldn't it say 'MUST' rather than a
'may'? Why would the wsa:MessageID
> >
> > (or more appropriately [message id]) be
different for a retransmission
> > in the context of WSRM? Or for that
matter anything else in the Infoset
> > that is transmitted.
> >
> > Also, can you point me to the text in
WSA where it says this?
> >
> > Thx!
> >
> > -Anish
> > --