Doug:
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Saturday, August 27, 2005
6:42 AM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] Proposal for
i004
Jacques,
thinking some more about this...I'm starting to convince myself that adding the
text you want
isn't
just possibly misleading or unnecessary but actually _can't_ be added. The
WS-A spec,
as
you point out, says when the messageID can be reused but it doesn't say
anything about
when
it must/should be reused. This is very important. Some people may
choose to implement
their
soap stack such that WS-A stuff is done before RM, and in those cases it makes
sense
that
the messageID would be reused. However, this is simply an implementation
choice. There
is
no reason why WS-A processing can not come after the RM logic. Its up to
the implementation
to
make sure that whatever messageID is ultimately used will work for proper
message
correlation
of any possible response messages.
<JD> Right. My concern was mostly to
bring to the attention of an RM developer that *in case the message that is retransmitted already has a wsa:MessageId
header* , the decision of what to do with this wsa:MessageId is not
without consequences on the ability to
compose with other wsa features. I think that such a reminder
cannot hurt given the special role of such
a header.
Now, we could say that is the job of a future
profile (WS-I) to do so, but from a pragmatic standpoint, before a profile is
rolled out that specifies this, several WS-RM implementations could be rolled
out with a handling of wsa:MessageID that will conflict. I know I am expressing
a preference that may restrict some option... my rationale is that at this
point I do not see
a convincing use case that would go
against *recommending* preserving
wsa:MessageId (when it is there) during retransmissions,while I see some potential
trouble when not recommending so.
All of this talk about reuse of messageID header
is actually incorrect - what is really important
is
the messageID that's in the wsa:RelatesTo header. That is actually the
value that MUST NOT
change
during a retry if the sender of this reply message ever hopes for proper
correlation back
to
the request message.
<JD> Indeed. But I think that the chances
that an implementor touches other wsa headers other than wsa:MessageId
are minimal: only wsa:MessageId lends
itself to legitimate alteration because after all, a retransmission is a new
message.
So if left without guidance, maybe 50% of implementers
would go that way, while very few if none at all would have a reason to change
other headers.
But I think a statement about the
consequences of altering wsa:RelatesTo header (or any wsa header?) cannot
hurt.
Whether the WS-A logic on the requester side uses some
WS-A
messageID
generated before or after the RM logic is simply an implementation choice. What
matters
is that the correlation _can_ take place and not how it takes place by implying
it _should_
be
on a messageID generated before the RM logic. And by implying that the
messageID should
not
change is implying an implementation choice, which I don't think the RM spec
should do.
<JD> I guess it is a matter of
trade-off: it is one of these areas where my preference goes for removing some
options because the potential composability trouble I perceive is greater than
the benefit from keeping this option open.
There may be use cases I don't see,
so I'd go only for a recommendation (not a must) - or just a
warning like:
"NOTE: in case wsa:MessageID is
present in the message to be retransmitted, any alteration of this value for
retransmission may impede other wsa features such as correlation via
wsa:RelatesTo."
Would that address your concern about
limiting options?
Not sure how contrived this example might be
but... let's say an RMS wants to be able to do some
sort
of analysis of the network stability. So, it actually uses a unique
messageID for all retries and
saves
the list so that when it gets a response it can examine the wsa:RelatesTo
messageID to
know
which specific request retry actually made it. This could provide
additional information
beyond
just "it took 3 retries to get there" - it might be useful to know
that even though it took 3 retries
message
1 was the one that got there each time - which means that the network might not
be
dropping
messages but instead my retry interval is too small. maybe??? :-)
<JD> your use case is beyond my
network expertise ;-) but if I have to make a choice between enabling it vs
forcing network guys to find another monitoring technique and prevent some
inconsiderate alteration of wsa:MessageId, (even via just a warning or
recommendation) I'd go for the latter... take it as a stubborn but friendly
dissent J.
-J
thanks,
-Doug
Jacques Durand
<JDurand@us.fujitsu.com> wrote on 08/26/2005 07:25:45 PM:
> 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 headerswhich 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
> > > --