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" <>*
>
> 07/12/2005 12:39 PM
>
>
> To
> Doug Davis/Raleigh/IBM@IBMUS, "Lei Jin" <>
> cc
> <>
> Subject
> RE: [ws-rx] NEW ISSUE: anonymous AcksTo
>
>
>
>
>
>
>
>
> Which “SHOULD NOT” are you referring to?
>
>
> ------------------------------------------------------------------------
>
> *From:* Doug Davis [mailto:] *
> Sent:* Tuesday, July 12, 2005 5:44 AM*
> To:* Lei Jin*
> Cc:* *
> 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" <>*
>
> 07/11/2005 03:18 PM
>
>
> To
> <>
> 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
>
