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


Title: RE: [ws-rx] Proposal for i004

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]