Is WS-Addressing's silence on what it
means to use the anonymous IRI in the wsa:To header mean that it should
be obvious to the reader? If so, then perhaps we can take the same
approach to its use in other places that WS-Addressing is silent as well
- for example, AcksTo - and say nothing and assume its obvious to the reader.
thanks
-Doug
Anish Karmarkar <>
wrote on 09/09/2005 02:20:12 AM:
> As discussed on the call today, I'm raising an issue about the meaning
> of 'anon' URI when used in AcksTo URI.
>
> Title:
>
> What does 'anon' URI mean when used in AcksTo EPR?
>
> Description:
>
> WS-Addressing Core [1], section 2.1 says the following about 'anon':
>
> "Some endpoints cannot be located with a meaningful IRI; this
URI is
> used to allow such endpoints to send and receive messages. The precise
> meaning of this URI is defined by the binding of Addressing to a
> specific protocol."
>
> WS-Addressing SOAP binding [2] defines what the 'anon' address means
> when used with ReplyTo and FaultTo in SOAP and SOAP/HTTP binding.
It
> does not say anything about what it means when used in other headers
> such as AcksTo.
>
> Justification:
>
> WSRM defines AcksTo element of type EndpointReferenceType and allows
> 'anon' URI for the address. But the meaning of such an anon address
is
> not defined anywhere.
>
> Target:
>
> core, soap
>
> Type:
>
> design
>
> Proposal:
>
> This can be resolved by:
>
> a) Adding a stmt similar to WS-Addressing SOAP binding. Something
like:
>
> "When "http://www.w3.org/2005/08/addressing/anonymous"
is specified as
> the address of the wsrm:AcksTo EPR, the underlying SOAP protocol binding
> provides a channel to the specified endpoint. Any underlying protocol
> binding supporting the SOAP request-response message exchange pattern
> provides such a channel. For instance, the SOAP 1.2 HTTP binding[SOAP
> 1.2 Part 2: Adjuncts] puts the reply message in the HTTP response."
>
> OR
>
> b) we could ask the WS-Addressing WG to fix their SOAP binding to
> include not just ReplyTo and FaultTo EPRs but any EPR when used in
the
> context of SOAP/HTTP binding.
>
> I prefer that we do (b). If they refuse, we can do (a)
>
> Related issues:
> i012
>
>
