OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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]