Re: Proposals to Resolve LC comment on WS Addressing Metadata Spec

Tom Rutt wrote:
> 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 
>
I have produced two analogous examples of policy expressions composing 
with MakeConnection
one for alternative a) another for alternative b).  I now see advantages 
and disadvantages for either alternative.  Alternattive a) requires no 
definition of connectable URI in a transport independent manner, and 
thus might be more appropriate as a resolution.

I present two example policy expression which state the subject can send 
replies using either of three mechanisms:

-  Using wsa:anonymous reply address

-  Using a non-anonymous reply address, which is not wsmc:anonymous

-  Using a wsmc:anonymous address

 

I assume in the examples below that the wsmc:MakeConnection policy 
assertion is changed to be a requirement, with lack of presence implying 
a prohibition on its use.

 

The following example shows an equivalent policy expression, assuming 
proposed
alternative A (wsa:NonAnonymous defined as any URI value other than 
wsa:Anonymous) is selected.  This requires use of MakeConnection to be 
treated as a special case of wsam:nonAnonymous reply.

 

<wsp:Policy>  <-- Policy expression for proposed alternative a) -->

<wsp:ExactlyOne>

<wsp:All>

<wsam:Addressing>

<wsp:Policy>

<wsp:ExactlyOne>

<!-- anon or non-anon responses required-->

<wsp:All>

<wsam:AnonymousResponses/>

</wsp:All>

<wsp:All>

<wsam:NonanonymousResponses/>

</wsp:All>

</wsp:ExactlyOne>

</wsp:Policy>

</wsam:Addressing>

<!--  wsmc:MakeConnectio is not asserted, thus prohibited in

                                    this alternative -->

</wsp:All>

<wsp:All>

<! Addressing required, only use makeConnection for reply -->

<wsam:Addressing>

<wsp:Policy>

<wsp:ExactlyOne>

<!-- non-anon responses required-->

<wsp:All>

<wsam:NonanonymousResponses/>

<wsp:All>

</wsp:ExactlyOne>

</wsp:Policy>

</wsam:Addressing>

<wsmc:MakeConnection/>

</wsp:All>

</wsp:ExactlyOne>

</wsp:Policy>

 

The following example shows an equivalent policy expression, assuming 
proposed

alternative b) (wsa:NonAnonymousResponses defined as a using 
 “connectable” URI ) is selected.  This requires use of MakeConnection 
to be treated as a special case outside of wsam:nonAnonymousResponses or 
wsam:NonAnonymousResponses.

 

<wsp:Policy>  <-- Policy expression for proposed alternative b) -->

<wsp:ExactlyOne>

<wsp:All>

<wsam:Addressing>

<wsp:Policy>

<wsp:ExactlyOne>

<!-- anon or non-anon responses required-->

<wsp:All>

<wsam:AnonymousResponses/>

</wsp:All>

<wsp:All>

<wsam:NonanonymousResponses/>

</wsp:All>

</wsp:ExactlyOne>

</wsp:Policy>

</wsam:Addressing>

<!--  wsmc:MakeConnectio is not asserted, thus prohibited in

                                    this alternative -->

</wsp:All>

<wsp:All>

<! Addressing required, only use makeConnection for reply -->

<wsam:Addressing>

            <-- since neither nested assertion raised, both

wsa:anonymous and connectable URIs prohibited for

responses -->

</wsam:Addressing/>

<wsmc:MakeConnection/>

</wsp:All>

</wsp:ExactlyOne>

</wsp:Policy>

 

 

 

The biggest advantage of alternative a) is that it does not require a 
definition of
“connectable” URI.  The addressing nested policy assertion types specify 
the universe
of responses associated with WS Addressing.   However, the policy 
expression is slightly
more complicated, since using makeConnection must be treated as asubset 
of nonAnonymous response behaviour.

 

Alternative b) results in a simpler policy expression since 
makeConnection is a behaviour
outside of the scope of using either wsa:nonAnonymous or wsa:anonymous 
responsed.
Its main disadvantage is that is requires “connectable” URI to have 
meaning is a transport
independent manner.


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

Received on Tuesday, 27 February 2007 15:20:42 UTC