← Prev in month
← Prev in thread
RE: [ws-rx] Proposal for i004
Title: RE: [ws-rx] Proposal for i004 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:] Sent: Wednesday, August 31, 2005 5:10 PM To: 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: blog: http://webpages.charter.net/chrisfer/blog.html phone: +1 508 377 9295 Jacques Durand <> 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:] > Sent: Wednesday, August 31, 2005 12:37 PM > To: > 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: > blog: http://webpages.charter.net/chrisfer/blog.html > phone: +1 508 377 9295 > Jacques Durand <> wrote on 08/31/2005 02:51:43 PM: > > Doug: > > > > > > From: Doug Davis [mailto:] > > Sent: Saturday, August 27, 2005 6:42 AM > > To: > > 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 <> 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:] > > > Sent: Thursday, August 25, 2005 4:34 PM > > > To: > > > 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 <> 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: > > > > 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:] > > > > Sent: Thursday, August 25, 2005 10:46 AM > > > > To: Marc Goodner > > > > Cc: > > > > 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:] > > > > > Sent: Thursday, August 25, 2005 12:29 AM > > > > > To: Marc Goodner > > > > > Cc: > > > > > 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 > > > > > --
← Prev in month
← Prev in thread