RE: [ws-rx] Proposal for i004

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

Comment inline.
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.)

I agree that in the scenario you describe things can
go bad, but I also don't
want to preclude cases where the RMS knows what its
doing and has a very good
reason for doing something that, on the surface, might
appear to be bad.

> 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.

To me, its not just about composibility with WS-A
but all WS-* specs.  So, do we need
to make a statement about how RM will compose with
WS-Tx (indirectly referenced in the 
charter) and how the RMS should not change the CoordinationContext
data as well?  This 
could impact things just as badly as changing the
MessageID.

I do understand your desire to give a warning but
it isn't clear to me how far we should
go.  As I mentioned, why talk about just WS-A
and not WS-Tx?  or the security headers?
Or anything else when security is turned on since
it could mess up the dsig?  
By calling out certain bits of data I fear we're putting
special focus on those over
others - which could imply to someone that _just_
those are untouchable while other bits
are fair game.  By leaving it as it currently
stands, or making it clearer that just the
SeqID+Msg# are what identify a message from an RM
perspective, we don't run the risk of
playing favorites or misleading the RM developer.
 They're left with their natural common
sense which should tell them that typically the message
will not change during a retry.
If they don't know this already they probably shouldn't
be coding up an RM 
implementation.  :-)

> 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 
> > > --