RE: [ws-rx] Proposal for i004

[Doug Davis <dug@us.ibm.com>]

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.
  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. 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.
  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???  :-)
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 
> > > --