RE: Use of Anonymous Address in <wsa:To> Header for Request / One-Way Messages

Mike

thanks for such a comprehensive reply!

I suggest the following way forward:

- include wsa:To in the current example messgaes

- continue with it left out of the XPath assertions.

- raise the possible ambiguity of anonymous value for To: 
  as part of our feedback to the WG 

- consider creating a specific tests with To 
  defaulted / anonymous depending upon the results of
  that discussion.

I guess if we have an implementation on Tuesday which
sends anonymous or defauled To:s on the assumption it's the 
URI of the HTTP POST, we may have to negotiate a work-round.

Paul

-----Original Message-----
From: public-ws-addressing-tests-request@w3.org on behalf of Mike Vernal
Sent: Sat 1/14/2006 7:18 AM
To: public-ws-addressing-tests@w3.org
Subject: Use of Anonymous Address in <wsa:To> Header for Request / One-Way Messages
 

Greetings,

On our last call, we discussed the fact that none of the example one-way
or request messages included a <wsa:To> header.  Since there was some
question as to whether the omission of a the <wsa:To> header was valid
for these messages, I took an action to follow-up on the issue.

The WS-Addressing 1.0 - Core spec [1] makes five references to
"Anonymous."  

In Section 2.1, the spec states:

> 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.

In Section 3.2, the spec makes three statements:

> /wsa:To 
>
> This OPTIONAL element (whose content is 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/08/addressing/anonymous".

...

> /wsa:ReplyTo 
>
> This OPTIONAL element (of type wsa:EndpointReferenceType) provides the
> value for the [reply endpoint] property. If this element is NOT
present
> then the value of the [address] property of the [reply endpoint] EPR
is
> "http://www.w3.org/2005/08/addressing/anonymous".

...

> Comparison of [destination] property values is out of scope, other
than
> using simple string comparison to detect whether the value is
anonymous,
> that is, where [destination] has the value 
> "http://www.w3.org/2005/08/addressing/anonymous".

Lastly, in Section 3.3, the spec states:

> If the reply is a normal message, select the EPR from the related 
> message's [reply endpoint] message addressing property. If none is 
> present, the processor MUST fault.
>
> Note:
> 
> When using the XML Infoset representation, in the absence of a
wsa:ReplyTo
> element the value of the [reply endpoint] message addressing property
> defaults to an EPR with an [address] property of
> "http://www.w3.org/2005/08/addressing/anonymous" - see section 3.2 XML
> Infoset Representation of Message Addressing Properties.

For our purposes, I think WS-A Core says two things.  First, the To and
ReplyTo are optional; if not present their values are defined to be
anonymous.  Second, the precise meaning of the Anonymous Uri is left to
the protocol binding.

The protocol binding in question (WS-Addressing 1.0 - SOAP Binding [2])
makes two references to Anonymous (Section 3.5 and Section 6).

First, it states:

> 3.5 Use of Anonymous Address in SOAP
>
> When "http://www.w3.org/2005/08/addressing/anonymous" is specified as
the
> address of the ReplyTo or FaultTo 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.

The second reference is not relevant (but included for completeness):

> Messages that use wsa:ReplyTo or wsa:FaultTo headers whose [address]
is
> not the predefined anonymous URI should include claims that allow a
> receiver to confirm that the EPR was issued by a principle with
authority
> to represent the [address] of the EPR.

As I read it, Section 3.5 says that when the Anonymous Uri is used as
the address of the ReplyTo or FaultTo, the underlying SOAP protocol
binding provides a channel for delivering any response or fault
messages.  The spec seems to make no other statement about the semantics
of the Anonymous Uri.

As such, I believe we should scope our use of the Anonymous Uri to its
defined use in Core / SOAP, i.e., we should scope its use to the value
of the address of ReplyTo or FaultTo headers (in the case of a one-way /
request message) and to its use as the value of the To header for any
replies or faults.

Since the absence of a To header is semantically equivalent to its
inclusion with the value of the Anonymous Uri, I think this means that
all of the request / one-way message need to explicitly have a To header
whose value is something other than the Anonymous Uri (e.g., the address
of the destination endpoint).

Cheers,
-mike  

[1] http://www.w3.org/TR/ws-addr-core/
[2] http://www.w3.org/TR/ws-addr-soap/

Received on Monday, 16 January 2006 16:07:37 UTC