[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-tx] Issue 045 - WS-AT: Meaning of "wsp:Optional"
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. > >> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]