[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] Proposal for i004
FYI: WS-Addressing WG had a long discussion on this and specifically
decided to keep a MAY in there (changing what was there before).
I have no objection to going back to the WS-Addressing WG and saying --
we need more guidance. But ...
The issue for me isn't about MessageID. MessageID is no different than
any other header or body (in this context). The protocol is build on the
foundation that messages with the same Identifier/MessageNumber can be
treated as the same by the receiver. This facilitates duplicate
detection. If we don't already say that (I don't think we do), we should
in the spec. The spec talks about what WSRM "module/unit" (or an
implementation of WSRM spec) does. It should not say what other
modules/units up and down the pipeline do or don't do. From that
perspective, I do think that we should say that WSRM should not modify
the "message" other than the WSRM headers (or something similar).
For example, if a module down the chain modifies the message to include
the timestamp, that is none of WSRM's business. WSRM spec should speak
about what WSRM module does.
As a side note, the example I gave about wsa:RelatesTo and what would
happen if retransmissions changed wsa:MessageID -- I think the example
was misunderstood. I was talking about retransmission changing the
wsa:MessageID in the request message (not the response message). This
wsa:MessageID is carried in the wsa:RelatesTo header of the response
header. Now if there are multiple instances (because of retransmissions)
of request messages with different wsa:MessageID, which one should the
reply message be correlated to? What about the other messages which will
potentially never get correlated responses (say because of
once-and-only-once semantics)? Throw in an intermediary or a reply
destination that is not 'anon' and it creates plenty of unintended
consequences.
-Anish
--
Jacques Durand wrote:
> Proposal:
> The TC will contact the WS-addressing WG to:
> - express concerns that the WS-addressing specification is making a
> statement on message retransmission and the possibility that
> wsa:MessageId be modified, without clearly stating the implications on
> this when related responses are expected, on related headers such as
> wsa:RelatesTo. (The node interpreting wsa:RelatesTo may not be aware of
> retransmission).
>
> - suggest that the specification be updated to remind of possible
> interference with the usage of other headers such as wsa:RelatesTo, when
> wsa:MessageId header is modified during retransmission.
>
> Jacques
>
> -----Original Message-----
> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> Sent: Wednesday, August 31, 2005 5:10 PM
> To: ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] Proposal for i004
>
> +1
>
> > So I would not take more of the TC bandwidth at this point, but would
> propose that the TC (as
> > opposed to just me) suggests to the WS-A WG an update / errata to add a
> warning on the
> > consequences of changing the messageId when retransmitting for usability
> of other WS-A headers
> > (since they ventured in talking about retransmission).
>
> Cheers,
>
> Christopher Ferris
> STSM, Emerging e-business Industry Architecture
> email: chrisfer@us.ibm.com
> blog: http://webpages.charter.net/chrisfer/blog.html
> phone: +1 508 377 9295
>
> Jacques Durand <JDurand@us.fujitsu.com> wrote on 08/31/2005 07:47:39 PM:
>
> > Chris:
> > >The RM layer might inspect WS-Addressing headers, but frankly, I don't
> > > think it needs to do so for any reason.
> > Concur with that, and I personally would not either, but the simple fact
> that i004 was raised
> > worries me - not so much about inspecting headers, but I can see that if
> Steve raised i004, then
> > some developers will have similar question and may re-identify a
> retransmitted message with no
> > other reason than they "may". I think it is a concern that is specific
> to this particular wsa
> > header (not justified for other wsa headers.)
> >
> > > I suggest that you bring this up in the WSA WG if you think that it
> needs
> > > to b tighter than a MAY in their spec.
> > As this issue does not seem to get much traction on the mailing list, I
> take it that not many are
> > sharing my paranoid concern here (though I'd claim that a bit of
> paranoia is not a bad thing in a
> > TC work...)
> > So I would not take more of the TC bandwidth at this point, but would
> propose that the TC (as
> > opposed to just me) suggests to the WS-A WG an update / errata to add a
> warning on the
> > consequences of changing the messageId when retransmitting for usability
> of other WS-A headers
> > (since they ventured in talking about retransmission).
> > I also thought that could be a WS-I profile job to do that - and in fact
> it will probably need to
> > anyway - but the timing may not work out well for implementers.
> > Cheers,
> > Jacques
> > -----Original Message-----
> > From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> > Sent: Wednesday, August 31, 2005 12:37 PM
> > To: ws-rx@lists.oasis-open.org
> > Subject: RE: [ws-rx] Proposal for i004
> > Jacques,
> > Discussion of wsa: header blocks, aside from specifying the values for
> > wsa:Action for WS-RM
> > operations, etc. is outside the scope of this spec.
> > The WS-Addressing spec says that it MAY be the same. It's their call.
> > What if the RM spec said it MUST be the same and the WS-TX spec said
> that
> > it MUST NOT?
> > Frankly, it isn't our call. The RM layer might inspect WS-Addressing
> > headers, but frankly, I don't
> > think it needs to do so for any reason.
> > What possible reason could you see for the RM layer to be concerned with
>
> > the wsa:MessageId?
> > It has its own identifier, the Sequence Identifier+MessageNumber. That
> is
> > all it should care about.
> > Separation of concerns.
> > If you want to influence treatment of wsa:MessageId, then IMO it needs
> to
> > be either via WS-Addressing
> > or a WS-I Profile. I suggest that you bring this up in the WSA WG if you
>
> > think that it needs to b tighter
> > than a MAY in their spec.
> > Cheers,
> > Christopher Ferris
> > STSM, Emerging e-business Industry Architecture
> > email: chrisfer@us.ibm.com
> > blog: http://webpages.charter.net/chrisfer/blog.html
> > phone: +1 508 377 9295
> > Jacques Durand <JDurand@us.fujitsu.com> wrote on 08/31/2005 02:51:43 PM:
>
> > > 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 took3 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
> > > > > > --
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]