ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ws-rx] Proposal for i004
- From: Doug Davis <dug@us.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Thu, 25 Aug 2005 19:34:16 -0400
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 headers which 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]