W3C home > Mailing lists > Public > public-ws-addressing@w3.org > April 2007

Re: Consolodated changes for alterngive G prime

From: Tom Rutt <tom@coastin.com>
Date: Tue, 03 Apr 2007 17:01:06 -0400
To: David Illsley <david.illsley@uk.ibm.com>
Cc: Anish Karmarkar <Anish.Karmarkar@oracle.com>, WS-Addressing <public-ws-addressing@w3.org>, public-ws-addressing-request@w3.org
Message-id: <4612C092.4020805@coastin.com>

Negation is never mentioned in either alternative G or F.

The idea for alternative G is unqualified "addressing" assertion means 
adressing supported, while the nested policy assertions are
expressing application restrictions (i.e., anon only or non anon only).

Alternative F states that empty implies no response eprs other than NONE 
may be used.  This is closer to negation, but still does not use the word
:negation or negatory or whatever.

Tom

We are hoping to define this without discussion negation whatsoever.

Tom

David Illsley wrote:
> Hi Anish,
> Unfortunately, in speaking to one of our policy experts, there seems to be 
> a negation concern with at least one scenario - the one in the example in 
> fact... consider the following
>
> What is the meaning of Alternative 1 in this situation?
>
> Example 3-8. Client looking for an endpoint which supports Addressing, and 
> does not require support for responses (will intersect with anything)
> <wsp:Policy>
>     <wsp:ExactlyOne>
>         <wsp:All>
>             <wsam:Addressing> <-- supports all response types -->  
> Alternative 1
>                 <wsp:Policy> 
>                 </wsp:Policy>
>             </wsam:Addressing>
>         </wsp:All>
>         <wsp:All>
>             <wsam:Addressing> <-- requires Anonymous responses --> 
> Alternative 2
>                 <wsp:Policy>
>                     <wsp:ExactlyOne>
>                         <wsp:All>
>                             <AnonymousResponses />
>                         </wsp:All>
>                     </wsp:ExactlyOne>
>                 </wsp:Policy>
>             </wsam:Addressing>
>         </wsp:All>
>         <wsp:All>
>             <wsam:Addressing> <-  requires nonAnonymous responses --> 
> Alternative 3
>                 <wsp:Policy>
>                     <wsp:ExactlyOne>
>                         <wsp:All>
>                             <NonAnonymousResponses />
>                         </wsp:All>
>                     </wsp:ExactlyOne>
>                 </wsp:Policy>
>             </wsam:Addressing>
>         </wsp:All>
>     </wsp:ExactlyOne>
> </wsp:Policy>
>
> My reading (of Framework, 3.2) is that because the AnonymousResponses 
> assertion is found in Alternative 2 that the negation rule means that 
> Alternative 1 includes a 'must not do AnonymousResponses meaning'. And 
> similarly that because of Alternative 3, Alternative 1 includes a 'must 
> not do NonAnonymousResponses meaning'.  If so, Alternative 1 (in this 
> context) does not mean "supports all response types", but in fact 
> "Addressing is supported but you must not send Anonymous or Non-Anonymous 
> response EPRs". 
>
> Do you agree with this interpretation? 
> David
>
>
> David Illsley
> Web Services Development
> MP211, IBM Hursley Park, SO21 2JN
> +44 (0)1962 815049 (Int. 245049)
> david.illsley@uk.ibm.com
>
> public-ws-addressing-request@w3.org wrote on 04/03/2007 12:30:50 AM:
>
>   
>> On the negation of nested assertion issue that we talked about today on 
>> the call. I asked our internal policy expert (aka Ashok) about this and 
>> his explanation was that the proposal as it is written, wrt the negation 
>>     
>
>   
>> issue, is fine. I.e., we can say (as we have) that absence of either of 
>> the nested assertion means support for both (or that no claim is made).
>>
>> Negation applies *only* when there are two (or more) alternatives: P and 
>>     
>
>   
>> Q. P contains an assertion A (either top-level or nested) and Q does 
>> not. If one chooses alternative Q, then that is equivalent to negation 
>>     
> of A.
>   
>> HTH.
>>
>> -Anish
>> --
>>
>> Tom Rutt wrote:
>>     
>>> attached is html showing all changes agreed today
>>>
>>> MarcG alternative G proposal: 
>>>
>>>       
> http://lists.w3.org/Archives/Public/public-ws-addressing/2007Mar/0043.html
>   
>>> as amended by Tom Rutt Email 
>>>
>>>       
> http://lists.w3.org/Archives/Public/public-ws-addressing/2007Mar/0053.html
>   
>>>
>>>       
> ------------------------------------------------------------------------
>   
>>>     3. Indicating Use of WS-Addressing
>>>
>>> This specification supports a mechanism for indicating, in a WSDL 
>>> description, that the endpoint conforms to the WS-Addressing 
>>> specification. That mechanism uses WS-Policy Framework [WS Policy 1.5 
>>>       
> - 
>   
>>> Framework <#WSPolicy>].
>>>
>>>
>>>       3.1 WS-Policy Assertions
>>>
>>> The mechanism for indicating that a binding or endpoint conforms to 
>>>       
> the 
>   
>>> WS-Addressing specification is through the use of the Web Services 
>>> Policy - Framework [WS Policy 1.5 - Framework <#WSPolicy>] and Web 
>>> Services Policy - Attachment [WS Policy 1.5 - Attachment 
>>> <#WSPolicyAttachment>] specifications. This specification defines 
>>>       
> three 
>   
>>> policy assertions.
>>>
>>> The wsam:Addressing policy assertion applies to the endpoint policy 
>>>       
> subject.
>   
>>> For WSDL 1.1, these assertions may be attached to |wsdl11:port| or 
>>> |wsdl11:binding|. For WSDL 2.0, they may be attached to 
>>> |wsdl20:endpoint| or |wsdl20:binding|.
>>>
>>> A policy expression containing the wsam:Addressing policy assertion 
>>>       
> MUST 
>   
>>> NOT be attached to a wsdl:portType or wsdl20:interface. The 
>>> wsam:Addressing policy assertion specifies a concrete behavior whereas 
>>>       
>
>   
>>> the wsdl:portType or wsdl20:interface is an abstract construct.
>>>
>>>
>>>         3.1.1 Addressing Assertion
>>>
>>> The wsam:Addressing policy assertion is a nested policy container 
>>> assertion. The meaning of this assertion, when present in a policy 
>>> alternative, is that WS-Addressing is required to communicate with the 
>>>       
>
>   
>>> subject. The wsam:Addressing assertion indicates that there are no 
>>> restrictions on the use of WS-Addressing unless otherwise qualified by 
>>>       
>
>   
>>> assertions in its nested policy expression.  In order to indicate that 
>>>       
>
>   
>>> the subject supports WS-Addressing but does not require its use, an 
>>> additional policy alternative should be provided which does not 
>>>       
> contain 
>   
>>> this assertion. This may be done in WS-Policy compact form by adding 
>>>       
> the 
>   
>>> attribute wsp:Optional="true" to the wsam:Addressing assertion.
>>>
>>>
>>>
>>>
>>>         3.1.2 AnonymousResponses Assertion
>>>
>>> The wsam:AnonymousResponses element MAY be used as a policy assertion 
>>> nested within the wsam:Addressing assertion in accordance with the 
>>>       
> rules 
>   
>>> laid down by WS-Policy Framework 1.5 section 4.3.2.
>>>
>>> The appearance of this element within a policy alternativethe 
>>> wsam:Addressing policy assertion indicates that the endpoint expresses 
>>>       
>
>   
>>> explicitrequires support for request messages with to use 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 forrequires 
>>>       
>
>   
>>> the use of 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.
>>>
>>> The None URI ("http://www.w3.org/2005/08/addressing/none") may appear 
>>>       
> as 
>   
>>> the value of [address] in place of the anonymous URI; this value MUST 
>>>       
> be 
>   
>>> accepted.
>>>
>>>
>>>         3.1.3 NonAnonymousResponses Assertion
>>>
>>> The wsam:NonAnonymousResponses element MAY be used as a policy 
>>>       
> assertion 
>   
>>> nested within the Addressing assertion in accordance with the rules 
>>>       
> laid 
>   
>>> down by WS-Policy Framework 1.5 section 4.3.2. The 
>>> wsam:NonAnonymousResponses policy assertion MUST NOT be used in the 
>>>       
> same 
>   
>>> policy alternative as the wsam:AnonymousResponses policy assertion.
>>>
>>> The appearance of this element within a policy alternativethe 
>>> wsam:Addressing assertion indicates that the endpoint expresses 
>>>       
> explicit 
>   
>>> support forrequires request messages with to use response endpoint 
>>>       
> EPRs 
>   
>>> that contain something other than the anonymous URI as the value of 
>>> [address]. In other words, the endpoint guarantees support forrequires 
>>>       
>
>   
>>> the use of 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.
>>>
>>> The None URI ("http://www.w3.org/2005/08/addressing/none") may appear 
>>>       
> as 
>   
>>> the value of [address] in place of a non-anonymous address; this value 
>>>       
>
>   
>>> MUST be accepted.
>>>
>>>
>>>         3.1.4 Examples (Compact Form)
>>>
>>> /Example 3-1.// Subject supports WS-Addressing, no statement on 
>>> supported response EPRs/
>>>
>>> <wsp:Policy>
>>>
>>>     <wsam:Addressing wsp:Optional="true">
>>>
>>>         <wsp:Policy/>
>>>
>>>     </wsam:Addressing>
>>>
>>> </wsp:Policy>
>>>
>>> /Example 3-2.// Subject requires WS-Addressing, no statement on 
>>> supported response EPRs/
>>>
>>> <wsp:Policy>
>>>
>>>     <wsam:Addressing>
>>>
>>>         <wsp:Policy/>
>>>
>>>     </wsam:Addressing>
>>>
>>> </wsp:Policy>
>>>
>>> /Example 3-3. Subject supports WS-Addressing, explicitly (and 
>>> optionally) supports anonymous and non-anonymous response EPRs/
>>>
>>> <wsp:Policy>
>>>
>>>     <wsam:Addressing wsp:Optional="true">
>>>
>>>         <wsp:Policy>
>>>
>>>             <wsam:AnonymousResponses wsp:Optional="true"/>
>>>
>>>             <wsam:NonAnonymousResponses wsp:Optional="true"/>
>>>
>>>         </wsp:Policy>
>>>
>>>     </wsam:Addressing>
>>>
>>> </wsp:Policy>
>>>
>>> /Example 3-4. Subject requires WS-Addressing, requires explicit 
>>>       
> support 
>   
>>> of anonymous or non-anonymous response EPRs/
>>>
>>> <wsp:Policy>
>>>
>>>     <wsam:Addressing>
>>>
>>>         <wsp:Policy>
>>>
>>>             <wsp:ExactlyOne>
>>>
>>>                 <wsam:AnonymousResponses/>
>>>
>>>                 <wsam:NonAnonymousResponses/>
>>>
>>>             </wsp:ExactlyOne>
>>>
>>>         </wsp:Policy>
>>>
>>>     </wsam:Addressing>
>>>
>>> </wsp:Policy>
>>>
>>> /Example 3-53.// Subject requires WS-Addressing and explicit 
>>> supportrequires the use of non-anonymous response EPRs/
>>>
>>> <wsp:Policy>
>>>
>>>     <wsam:Addressing>
>>>
>>>         <wsp:Policy>
>>>
>>>             <wsam:NonAnonymousResponses/>
>>>
>>>         </wsp:Policy>
>>>
>>>     </wsam:Addressing>
>>>
>>> </wsp:Policy>
>>>
>>>
>>>         3.1.5 Examples (Normal Form)
>>>
>>> /Example 3-46. Subject supports WS-Addressing, no statement on 
>>>       
> supported 
>   
>>> response EPRs/
>>>
>>> <wsp:Policy>
>>>
>>>     <wsp:ExactlyOne>
>>>
>>>         <wsp:All/>
>>>
>>>         <wsp:All>
>>>
>>>             <wsam:Addressing>
>>>
>>>                 <wsp:Policy>
>>>
>>>                     <wsp:ExactlyOne>
>>>
>>>                         <wsp:All/>
>>>
>>>                     </wsp:ExactlyOne>
>>>
>>>                 </wsp:Policy>
>>>
>>>             </wsam:Addressing>
>>>
>>>         </wsp:All>
>>>
>>>     </wsp:ExactlyOne>
>>>
>>> </wsp:Policy>
>>>
>>> /Example 3-57. Subject requires WS-Addressing, no statement on 
>>>       
> supported 
>   
>>> response EPRs/
>>>
>>> <wsp:Policy>
>>>
>>>     <wsp:ExactlyOne>
>>>
>>>         <wsp:All>
>>>
>>>             <wsam:Addressing>
>>>
>>>                 <wsp:Policy>
>>>
>>>                     <wsp:ExactlyOne>
>>>
>>>                         <wsp:All/>
>>>
>>>                     </wsp:ExactlyOne>
>>>
>>>                 </wsp:Policy>
>>>
>>>             </wsam:Addressing>
>>>
>>>         </wsp:All>
>>>
>>>     </wsp:ExactlyOne>
>>>
>>> </wsp:Policy>
>>>
>>> /Example 3-8. Subject supports WS-Addressing, explicitly (and 
>>> optionally) supports anonymous and non-anonymous response EPRs/
>>>
>>> <wsp:Policy>
>>>
>>>     <wsp:ExactlyOne>
>>>
>>>         <wsp:All/>
>>>
>>>         <wsp:All>
>>>
>>>             <wsam:Addressing>
>>>
>>>                 <wsp:Policy>
>>>
>>>                     <wsp:ExactlyOne>
>>>
>>>                         <wsp:All/>
>>>
>>>                     </wsp:ExactlyOne>
>>>
>>>                 </wsp:Policy>
>>>
>>>             </wsam:Addressing>
>>>
>>>         </wsp:All>
>>>
>>>         <wsp:All>
>>>
>>>             <wsam:Addressing>
>>>
>>>                 <wsp:Policy>
>>>
>>>                     <wsp:ExactlyOne>
>>>
>>>                         <wsp:All>
>>>
>>>                             <wsam:AnonymousResponses/>
>>>
>>>                         </wsp:All>
>>>
>>>                     </wsp:ExactlyOne>
>>>
>>>                 </wsp:Policy>
>>>
>>>             </wsam:Addressing>
>>>
>>>         </wsp:All>
>>>
>>>         <wsp:All>
>>>
>>>             <wsam:Addressing>
>>>
>>>                 <wsp:Policy>
>>>
>>>                     <wsp:ExactlyOne>
>>>
>>>                         <wsp:All>
>>>
>>>                             <wsam:NonAnonymousResponses/>
>>>
>>>                         </wsp:All>
>>>
>>>                     </wsp:ExactlyOne>
>>>
>>>                 </wsp:Policy>
>>>
>>>             </wsam:Addressing>
>>>
>>>         </wsp:All>
>>>
>>>         <wsp:All>
>>>
>>>             <wsam:Addressing>
>>>
>>>                 <wsp:Policy>
>>>
>>>                     <wsp:ExactlyOne>
>>>
>>>                         <wsp:All>
>>>
>>>                             <wsam:AnonymousResponses/>
>>>
>>>                             <wsam:NonAnonymousResponses/>
>>>
>>>                         </wsp:All>
>>>
>>>                     </wsp:ExactlyOne>
>>>
>>>                 </wsp:Policy>
>>>
>>>             </wsam:Addressing>
>>>
>>>         </wsp:All>
>>>
>>>     </wsp:ExactlyOne>
>>>
>>> </wsp:Policy>
>>>
>>> /Example 3-9. Subject requires WS-Addressing, requires explicit 
>>>       
> support 
>   
>>> of anonymous or non-anonymous response EPRs/
>>>
>>> <wsp:Policy>
>>>
>>>     <wsp:ExactlyOne>
>>>
>>>         <wsp:All>
>>>
>>>             <wsam:Addressing>
>>>
>>>                 <wsp:Policy>
>>>
>>>                     <wsp:ExactlyOne>
>>>
>>>                         <wsp:All>
>>>
>>>                             <wsam:AnonymousResponses/>
>>>
>>>                         </wsp:All>
>>>
>>>                     </wsp:ExactlyOne>
>>>
>>>                 </wsp:Policy>
>>>
>>>             </wsam:Addressing>
>>>
>>>         </wsp:All>
>>>
>>>         <wsp:All>
>>>
>>>             <wsam:Addressing>
>>>
>>>                 <wsp:Policy>
>>>
>>>                     <wsp:ExactlyOne>
>>>
>>>                         <wsp:All>
>>>
>>>                             <wsam:NonAnonymousResponses/>
>>>
>>>                         </wsp:All>
>>>
>>>                     </wsp:ExactlyOne>
>>>
>>>                 </wsp:Policy>
>>>
>>>             </wsam:Addressing>
>>>
>>>         </wsp:All>
>>>
>>>     </wsp:ExactlyOne>
>>>
>>> </wsp:Policy>
>>>
>>> /Example 3-610. Subject requires WS-Addressing and explicit support 
>>> ofrequires the use of non-anonymous response EPRs/
>>>
>>> <wsp:Policy>
>>>
>>>     <wsp:ExactlyOne>
>>>
>>>         <wsp:All>
>>>
>>>             <wsam:Addressing>
>>>
>>>                 <wsp:Policy>
>>>
>>>                     <wsp:ExactlyOne>
>>>
>>>                         <wsp:All>
>>>
>>>                             <wsam:NonAnonymousResponses/>
>>>
>>>                         </wsp:All>
>>>
>>>                     </wsp:ExactlyOne>
>>>
>>>                 </wsp:Policy>
>>>
>>>             </wsam:Addressing>
>>>
>>>         </wsp:All>
>>>
>>>     </wsp:ExactlyOne>
>>>
>>> </wsp:Policy>
>>>
>>>
>>>         3.1.6 Finding Compatible Policies
>>>
>>>
>>>         When a client is looking for an endpoint with compatible 
>>>       
> policy,
>   
>>>         one common method used is to take the policy intersection
>>>         between the policy which the client is looking for, and the
>>>         policy asserted in the WSDL document; a non-empty intersection
>>>         is sought. The policy used by the client must be written
>>>         carefully to avoid unexpected results. This is most obvious 
>>>       
> when
>   
>>>         the client is not looking for explicit support of a particular
>>>         kind of response; failing to take care could mean missing a
>>>         compatible policy.
>>>
>>> /Example 3-7. Client looking for an endpoint which supports 
>>>       
> Addressing, 
>   
>>> and which supports anonymous responses/
>>>
>>> <wsp:Policy>
>>>
>>>     <wsp:ExactlyOne>
>>>
>>>         <wsp:All>
>>>
>>>             <wsam:Addressing>
>>>
>>>                 <wsp:Policy>
>>>
>>>                     <wsp:ExactlyOne>
>>>
>>>                         <wsp:All>
>>>
>>>                             <AnonymousResponses Optional=?true? />
>>>
>>>                         </wsp:All>
>>>
>>>                     </wsp:ExactlyOne>
>>>
>>>                 </wsp:Policy>
>>>
>>>             </wsam:Addressing>
>>>
>>>         </wsp:All>
>>>
>>>     </wsp:ExactlyOne>
>>>
>>> </wsp:Policy>
>>>
>>> /Example 3-8. Client looking for an endpoint which supports 
>>>       
> Addressing, 
>   
>>> and does not require support for responses (will intersect with 
>>>       
> anything)/
>   
>>> <wsp:Policy>
>>>
>>>     <wsp:ExactlyOne>
>>>
>>>         <wsp:All>
>>>
>>>             <wsam:Addressing> <-- supports all response types -->
>>>
>>>                 <wsp:Policy>
>>>
>>>                 </wsp:Policy>
>>>
>>>             </wsam:Addressing>
>>>
>>>         </wsp:All>
>>>
>>>         <wsp:All>
>>>
>>>             <wsam:Addressing> <-- requires Anonymous responses -->
>>>
>>>                 <wsp:Policy>
>>>
>>>                     <wsp:ExactlyOne>
>>>
>>>                         <wsp:All>
>>>
>>>                             <AnonymousResponses />
>>>
>>>                         </wsp:All>
>>>
>>>                     </wsp:ExactlyOne>
>>>
>>>                 </wsp:Policy>
>>>
>>>             </wsam:Addressing>
>>>
>>>         </wsp:All>
>>>
>>>         <wsp:All>
>>>
>>>             <wsam:Addressing> <-  requires nonAnonymous responses -->
>>>
>>>                 <wsp:Policy>
>>>
>>>                     <wsp:ExactlyOne>
>>>
>>>                         <wsp:All>
>>>
>>>                             <NonAnonymousResponses />
>>>
>>>                         </wsp:All>
>>>
>>>                     </wsp:ExactlyOne>
>>>
>>>                 </wsp:Policy>
>>>
>>>             </wsam:Addressing>
>>>
>>>         </wsp:All>
>>>
>>>     </wsp:ExactlyOne>
>>>
>>> </wsp:Policy>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>         For more detailed descriptions of the use of wsp:Optional,
>>>         wsp:Ignorable, and strict and lax intersection, please refer 
>>>       
> to
>   
>>>         the WS-Policy Primer [WS Policy 1.5 - Primer 
>>>       
> <#WSPolicyPrimer>].
>   
>>>
>>>
>>>       
>
>
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
> 741598. 
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
>
>
>
>
>   

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133
Received on Tuesday, 3 April 2007 21:01:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:16 GMT