[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] Proposal for i004
+1
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
Doug Davis/Raleigh/IBM@IBMUS wrote on 08/25/2005 07:34:16 PM:
>
> 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. Ifit 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]