Re: [ws-tx] Issue 045 - WS-AT: Meaning of "wsp:Optional"

["Mark Little" <mark.little@jboss.com>]

Title: Re: [ws-tx] Issue 045 - WS-AT: Meaning of "wsp:Optional"

+1


Ashok Malhotra wrote:
> Thanks, Monica, I missed that para in the latest WS-Policy spec.
> Here is how, I think, the three semantics Ian discussed can be encoded.
>
> Assertion present with WS-Optional = false  -- MUST
> Assertion present with WS-Optional = true -- MAY
> Assertion absent -- MUST NOT
>
> All the best, Ashok
> 
>
>> -----Original Message-----
>> From: Monica.Martin@Sun.COM [mailto:Monica.Martin@Sun.COM] On
>> Behalf Of Monica J. Martin
>> Sent: Monday, May 15, 2006 4:40 PM
>> To: Ashok Malhotra
>> Cc: Ian Robinson; Ram Jeyaraman; ws-tx@lists.oasis-open.org
>> Subject: Re: [ws-tx] Issue 045 - WS-AT: Meaning of "wsp:Optional"
>>
>>
>>> malhotra: Although WS-Policy does not define the semantics
>> of missing
>>> assertions, it is not unreasonable to assume that if a particular
>>> policy assertion does not appear, it means "don't do that".  For
>>> example, if an endpoint does not have a Reliable Messaging
>> assertion in
>>> its policy it's fair to assume that it does not want a reliable
>>> protocol used.  And if there is no encryption assertion,
>> this seems to imply that messages shd not be encrypted.
>>> But there are some tricky areas.  For example, if there is
>> no encoding
>>> assertion does this mean that no encoding shd be used?  It seems to
>>> depend on whether the absent assertion is among the set of
>> 'known assertions'.
>>> In any case, I think WS-TX is free to adopt the
>>> absence-means-don't-do-it semantic but it would be good if
>> this was spelt out clearly in the spec.
>>> All the best, Ashok
>>>
>> mm1:  This statement from WS-Policy actually does give
>> guidance around missing policy assertions, Ashok (as
>> previously stated).
>>
>> (1) In Section 3.2 of WS-Policy:
>>
>> ..."An assertion whose type is part of the policy's
>> vocabulary but is not included in an alternative is
>> explicitly prohibited by the alternative."
>>
>> Interpretation of the above WS-Policy text indicates that the
>> WS-AT description of the compact shortcut,
>> wsp:Optional="true", has to be the policy alternatives "MUST"
>> and "MUST NOT" rather than the current specified alternatives
>> of "MUST" and "SHOULD NOT". Otherwise, WS-AT is misusing WS-Policy....
>>
>> We should consider both client and server side behavior. For
>> example, what happens when the server doesn't recognize the
>> transaction? There is a need to clarify and be explicit here.
>>
>> Thanks.
>>
>>>> (1) In Section 3.2 of WS-Policy [reference 2]:
>>>>
>>>> "An assertion whose type is part of the policy's vocabulary
>> but is not
>>>> included in an alternative is explicitly prohibited by the
>>>> alternative."
>>>>
>>>> Interpretation of the above WS-Policy text indicates that the WS-AT
>>>> description of the compact shortcut, wsp:Optional="true", has to be
>>>> the policy alternatives "MUST"
>>>> and "MUST NOT" rather than the current specified alternatives of
>>>> "MUST" and "SHOULD NOT". Otherwise, WS-AT is misusing WS-Policy.
>>>>
>>
>>
>
>