Proposals to Resolve LC comment on WS Addressing Metadata Spec

This email message provides two alternative proposals to resolve the LC 
comment regarding WS Addressing policy assertions in WS Addressing 
Metadata Spec: 
http://lists.w3.org/Archives/Public/public-ws-addressing/2007Feb/0007.html
----

This proposal presents two alternatives:
a) changes the nested policy assertions to be requirements, but
keeps definition of non-anonymous to be “not wsa:anonymous” uri.

b) In addition to the changes in alternative a, this proposal also
changes definition of Non Anonymous to be restricted to
connectable URIs for responses to be sent to.

I prefer alternative b) because it is more exact and easier to compose
with “backchannel” mechanism other than wsa:anonymous. Other “back
channel” mechanisms for response URIs, such as the makeConnection URI
template, and be factored in by employing additional policy expression
alternatives which require the MakeConnection mechanism for responses.

The following example policy expression factors in wsrx MakeConnection
mechanism, by including three alternatives:

<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<wsam:Addressing>
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All> <!-- anon or non-anon responses required-->
<wsam:AnonymousResponses/>
</wsp:All>
<wsp:All>
<wsam:NonanonymousResponses/>
<wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
</wsam:Addressing>
<wsp:All>
<wsp:All> <! Addressing required, usemakeConnection for reply -->
<wsam:Addressing>
<wsmc:MakeConnection>
<wsp:All>
</wsp:ExactlyOne>
<wsp:Policy>

Stated in words, this policy statement requires that responses must be
sent either as NonAnonymousReplies, or as wsa:Anonymous replies, or as
a wsmc:MakeConnection reply.


Proposal a) Change nested policy assertions to be requirements, but
keep definition of non-anonymous to be “not wsa:anonymous URI”.

In 3.1.2 Change:
“
The appearance of this element within a policy alternative indicates
that the endpoint expresses explicit support for request messages with
response endpoint EPRs that contain the anonymous URI
("http://www.w3.org/2005/08/addressing/anonymous") as the value of
[address]. In other words, the endpoint guarantees support for
anonymous responses.

The absence of the wsam:AnonymousResponses policy assertion within a
policy alternative does not indicate that the endpoint will not accept
request messages with response endpoint EPRs that contain the anonymous
URI as an address; it simply indicates the lack of any affirmation of
support for anonymous URIs.

To:
“
The appearance of this element within a policy alternative indicates
that the subject requires request messages that require responses to
include response endpoint EPRs that contain the anonymous URI
("http://www.w3.org/2005/08/addressing/anonymous") as the value of
[address]. In other words, the subject requires response instances to
be sent as anonymous responses.

The absence of the wsam:AnonymousResponses policy assertion within a
policy alternative indicates that the subject prohibits response
message instances using the anonymous URI as an address.

“

In 3.1.3 change:
“
The appearance of this element within a policy alternative indicates
that the endpoint expresses explicit support for request messages with
response endpoint EPRs that contain something other than the anonymous
URI as the value of [address]. In other words, the endpoint guarantees
support for non-anonymous responses. This assertion is deliberately
vague; its presence indicates that some non-anonymous addresses will be
accepted but doesn't constrain what such an address might look like. A
receiver can still reject a request that contains an address that it
doesn't understand or that requires a binding it doesn't support.

As with the other assertions, the absence of the
wsam:NonAnonymousResponses policy assertion within a policy alternative
does not indicate that the endpoint will not accept request messages
with response endpoint EPRs that contain something other than the
anonymous URI address; it simply indicates the lack of any affirmation
of support for them.
“

To:

“
The appearance of this element within a policy alternative indicates
that the subject requires any request message that has responses to
include response endpoint EPRs that contain something other than the
anonymous URI as the value of [address]. In other words, the endpoint
requires that any response instances use non-anonymous address URIs.
This assertion is deliberately vague; its presence indicates that some
non-anonymous addresses are required for instances of response
messages, but doesn't constrain what such an address might look like. A
receiver can still reject a request that contains an address that it
doesn't understand or that requires a binding it doesn't support.

The absence of the wsam:NonAnonymousResponses policy assertion within a
policy alternative indicates that the subject prohibits response
message instances using endpoint EPRs that contain something other
than the anonymous URI address.
“

Proposal Alternative b)

In addition to the changes in proposal alternative a)

In 3.1.3 Change
“
The appearance of this element within a policy alternative indicates
that the subject requires any request message that has responses to
include response endpoint EPRs that contain something other than the
anonymous URI as the value of [address]. In other words, the endpoint
requires that any response instances use non-anonymous address URIs.
This assertion is deliberately vague; its presence indicates that some
non-anonymous addresses are required for instances of response
messages, but doesn't constrain what such an address might look like. A
receiver can still reject a request that contains an address that it
doesn't understand or that requires a binding it doesn't support.

The absence of the wsam:NonAnonymousResponses policy assertion within a
policy alternative indicates that the subject prohibits response
message instances using endpoint EPRs that contain something other
than the anonymous URI address.
“

To:
“
The appearance of this element within a policy alternative indicates
that the subject requires any request message that has responses to
include response endpoint EPRs that contain a connectable URI as the
value of [address]. This assertion is deliberately vague; its presence
indicates that some connectable addresses are required for instances of
response messages, but doesn't constrain what such an address might
look like. A receiver can still reject a request that contains an
address that it doesn't understand or that requires a binding it
doesn't support.

The absence of the wsam:NonAnonymousResponses policy assertion within a
policy alternative indicates that the subject prohibits response
message instances using endpoint EPRs that contain a connectable URI
address.
“


A PDF file which makes the changes in Proposed alternative b), and
which also modified the examples to correspond, is attached to this
email..

Tom Rutt


Tom Rutt

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133