Re: [ws-rx] NEW ISSUE: anonymous AcksTo

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

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
>