[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] NEW ISSUE: anonymous AcksTo
The latest editor's draft which incorporates all of the post LC changes is at: http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-core.html?content-type=text/html;%20charset=utf-8 The WG has removed the 'SHOULD NOT' that Lei is referring to. HTH. -Anish -- Doug Davis wrote: > > At this version of the WSA spec: > http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/ > The last paragraph right before section 3.1 says: > > Requests whose [reply endpoint], [source endpoint] and/or [fault > endpoint] use this address MUST provide some out-of-band mechanism for > delivering replies or faults (e.g. returning the reply on the same > transport connection). This mechanism may be a simple request/reply > transport protocol (e.g., HTTP GET or POST). This IRI MAY be used as the > [destination] for reply messages and SHOULD NOT be used as the > [destination] in other circumstances. > > I believe this is the same "SHOULD NOT" Lei was referring to as well. > Might not be the absolute latest version of the spec but that's the > latest version I saw on the WG home page. > > thanks, > -Doug > > > > *"Jonathan Marsh" <jmarsh@microsoft.com>* > > 07/12/2005 12:39 PM > > > To > Doug Davis/Raleigh/IBM@IBMUS, "Lei Jin" <ljin@bea.com> > cc > <ws-rx@lists.oasis-open.org> > Subject > RE: [ws-rx] NEW ISSUE: anonymous AcksTo > > > > > > > > > Which “SHOULD NOT” are you referring to? > > > ------------------------------------------------------------------------ > > *From:* Doug Davis [mailto:dug@us.ibm.com] * > Sent:* Tuesday, July 12, 2005 5:44 AM* > To:* Lei Jin* > Cc:* ws-rx@lists.oasis-open.org* > Subject:* Re: [ws-rx] NEW ISSUE: anonymous AcksTo > > > Lei, > w.r.t using the anonymous IRI on non-reply messages - I'd like to point > out > that even the WSA spec[1] itself doesn't adhere to their own "SHOULD NOT". > If you look at the text for wsa:To it says: > * > /wsa:To * > This OPTIONAL element (of type xs:anyURI) provides the value for the > [destination] property. If this element is NOT present then the value of > the [destination] property is > "http://www.w3.org/2005/03/addressing/role/anonymous". Otherwise the > [children] of this element convey the value of this property. > > This applies to all messages. > > Some of this is reading between the lines, but to me the WSA spec was > simply > trying to encourage people to use a real IRI for the wsa:To and trying > to find a way > to have a copy of the transprt URL within the envelope in order to make > the envelope > a self-contained/self-describing entity. There are however cases where a > transport URL is not available (like on the HTTP response > flow), and these are the cases where anonymous IRI makes sense. > > Since we need a way to deliver ACKs for one-way messages even when a > firewall is in place I believe using the anonymous IRI is a valid choice. > > w.r.t. your intermediary examining the wsa:ReplyTo - be a bit careful here. > The presence of a wsa:ReplyTo does not imply anything about the MEP > (sadly :-(. > There are cases where a wsa:ReplyTo could be present even for a one-way > message. And the presence of an anonymous wsa:ReplyTo does not guarantee > that anything will flow back on the http response flow. > > thanks, > -Doug > > [1] http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/ > > *"Lei Jin" <ljin@bea.com>* > > 07/11/2005 03:18 PM > > > To > <ws-rx@lists.oasis-open.org> > cc > > Subject > [ws-rx] NEW ISSUE: anonymous AcksTo > > > > > > > > > > > > > I have the impression after talking to a few people that there is the > implicit assumption (though not specifically called out) in the spec > that if the AcksTo EPR is set to use the anonymous IRI, then all > subsequent acknowledgements for that reliable sequence will be sent back > synchronously on the http response path of either the application > message or an ack request message. > > I think that is not a good idea. First of all, we are saying that even > if my application message is one way (or asynchronous), I might still > receive something back on the http response(the WS-RX ack). Nothing > really precludes this usage, but we are introducing unnecessary > dependency between WS-RX (acknowledgement messages) and WS-Addressing > (normal MEP). For example, if I have an intermediary on the server side > that takes an incoming message, looks at the reply-to address (or > message MEP), and decides to close http connection if it's a oneway or > asynchronous message, everything works fine. Now, with WS-RX, it has to > know that "hmm, maybe I shouldn't close that connection if WS-RX is > involved and synchronous ack is used". > > Secondly, the paragraph below quoted from WS-Addressing spec says the > anonymous IRI shouldn't be used as the destination in any other > circumstances other than the destination for reply messages. I don't > see acknowledgements as reply messages. > > WS-Addressing defines the following well-known IRI for use by endpoints > that cannot have a stable, resolvable IRI: > "http://www.w3.org/2005/03/addressing/role/anonymous" Requests whose > [reply endpoint], [source endpoint] and/or [fault endpoint] use this > address MUST provide some out-of-band mechanism for delivering replies > or faults (e.g. returning the reply on the same transport connection). > This mechanism may be a simple request/reply transport protocol (e.g., > HTTP GET or POST). This IRI MAY be used as the [destination] for reply > messages and SHOULD NOT be used as the [destination] in other > circumstances. > > Proposal 1: > > Specifically call out that the AcksTo EPR should not use the anonymous > IRI. > > -- One reason to use an anonymous IRI is so that the acknowledgement may > reach sending endpoints that may be sitting behind a NAT or firewall. > But we have to deal with the same problem with asynchronous response > messages anyway. > > Proposal 2: > > Specifically call out that an anonymous IRI in the AcksTo EPR would > indicate acknowledgement message will only be sent back in response to > ack request messages where the ack request message should be a > standalone synchronous invoke. > > Flames? > > Lei >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]