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

["Ashok Malhotra" <ashok.malhotra@oracle.com>]

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