Re: NEW ISSUE :Clarify usage of assertions with no behavioral requirements on the requester

Re: NEW ISSUE: New Attribute keyword to identify 'local' policies #3721Hi

Thanks for the comments. 

Ashok : "wsp:Optional is used to indicate that an assertion may or may not be used."

I don't think this is a complete definition. My reading of the spec is that wsp:Optional marks assertions which may or may not be used by a requester. I don't see any text which would suggest otherwise. Not do I think it's of any use to work with assertions which a provider may choose to ignore. It's a key thing IMHO. No assertions, irrespectively of how they're are marked, can be ignored by a provider.
For ex, lets consider, oasis:infoConfidential.

Example 1 (syntaxis may be not correct) :
<Policy>
   <oasis:infoConfidential/>
   <sp:security/>
</Policy>

Provider here requires a requester to understand what <oasis:infoConfidential/> is.
Example 2.
<Policy>
   <oasis:infoConfidential wsp:optional="True"/>
   <sp:security/>
</Policy>

Provider here indicates that a requester is free to ignore oasis:infoConfidential or use it as a base for selecting this service. However, by no means a provider is saying that it may choose to keep an info non-confidential. If an assertion is advertized then a provider makes a commitment. Provider will keep the info confidential even if a requester does not understand what <oasis:infoConfidential/> is, doing so won't affect a requester communicating with this service.

Ashok : I support an attribute that marks such assertions as "non-operational" and so takes them out of the intersection algorithm.  This would simplify policy processing.

The thing is I do want knowledgeable requesters, those who might be looking for services guaranteeing the info confidentiality, be able to include, should they wish to, oasis:infoConfidential into the intersection algorithm.

Do you think it's unreasonable ? I want the requesters be able to use this info if they can.

I feel if we introduce another attribute like wsp:advisory which would indicate assertions which a client may or may not ignore then it would overlap with the wsp:optional and will make things more complicated. I'd prefer to clarify the wording for wsp:optional (or even drop it. just joking :-)).

wsp:local is what we thought of in this respect when we wanted to mark assertions which are completely out of clients' radar, that is a client should not include them in the intersection algorithm and must ignore them.

Cheers, Sergey


  I'm sorry, but I disagree with this direction.  wsp:Optional is orthogonal to assertions that
  that have no behavioral requirements (or do not affect the wire format).

  wsp:Optional is used to indicate that an assertion may or may not be used.  For assertions
  that do not affect the wire format this has no meaning.  These assertions are in some sense
  just advertising.  The provider says "I will keep yr information confidential" -- well fine, but how
  would Optional apply to such an assertion or, more strongly, make sense with such an assertion.
  Would you want two alternatives that say keep it confidential and don't keep it confidential?
  OK.  If you want that you can say that but that has no relation to whether the assertion impacts
  the wire format or not.

  I support an attribute that marks such assertions as "non-operational" and so takes them out 
  of the intersection algorithm.  This would simplify policy processing.

  All the best, Ashok 





----------------------------------------------------------------------------
    From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Paul Cotton
    Sent: Friday, October 06, 2006 10:57 AM
    To: Sergey Beryozkin; public-ws-policy@w3.org
    Subject: RE: NEW ISSUE :Clarify usage of assertions with no behavioral requirements on the requeste


    >1. Add an example to a primer and/or policy guidelines 

     

    Can you formulate your required example even in outline form?

     

    >2. Explain why policy authors should make such assertions optional for those requesters which are not aware of them.

     

    I assume you want this text in the primer and/or guidelines doc.  Is that correct?

     

    If so can you offer proposed text?

     

    > 3. Make any necessary changes to the wsp:optional related wording so that a policy author can use wsp:optional as a recognized but not a workaround way to mark such assertions.

     

    Can you please clarify what you mean by "so that a policy author can use wsp:optional as a recognized but not a workaround to mark such assertions"?

     

    Are you saying the Framework should warn policy assertion authors from using wsp:optional to describe "assertions with no behavioural requirements on the requester"?

     

    /paulc

    Paul Cotton, Microsoft Canada
    17 Eleanor Drive, Ottawa, Ontario K2E 6A3
    Tel: (613) 225-5445 Fax: (425) 936-7329
    mailto:Paul.Cotton@microsoft.com






----------------------------------------------------------------------------

    From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Sergey Beryozkin
    Sent: October 6, 2006 6:27 AM
    To: Sergey Beryozkin; public-ws-policy@w3.org
    Subject: Re: NEW ISSUE :Clarify usage of assertions with no behavioral requirements on the requeste

     

    Hello,

     

    This is the resolution I think would adequately address this issue :

     

    1. Add an example to a primer and/or policy guidelines
    2. Explain why policy authors should make such assertions optional for those requesters which are not aware of them. 
    3. Make any necessary changes to the wsp:optional related wording so that a policy author can use wsp:optional as a recognized but not a workaround way to mark such assertions.

     

    Thanks, Sergey

       

      http://www.w3.org/Bugs/Public/show_bug.cgi?id=3789

      Target : WS-Policy Framework and policy guidelines

      Justification :

      There's a class of policy assertions which have no behavioral requirements on the requester but can be still usefully processed by 
      requesters which are aware
      of what assertions mean.
      For example : <oasis:Replicatable/>

      An assertion like this one can be a useful source of information for requesters. Providers having expected properties like 
      <oasis:Replicatable/> can be chosen/searched.
      At the same time, given the fact assertions like <oasis:Replicatable/>
      have no behavioral requirements on the provider it's important to ensure
      policy-aware clients which have no knowledge of these assertions can proceed
      consuming the service advertsing this assertion.

      Currently the way to advertise such an assertion is to use a normal form with two policy alternatives(simple case), with only one 
      alternative containing this assertion thus making it optional, or, in other words, giving a chance to requesters to ignore it.
      Such normal form expression is equivalent to a compact form with the optional assertion marked with wsp:optional attribute with a 
      value 'true'.

      However, at the moment the primer recommends using wsp:optional when one needs to mark asssertions which identify optional 
      capabilities/requirements with behavioral requirements on a requester should the requester wishes to use it.

      Thus marking assertions like <oasis:Replicatable/> with wsp:optional is considered to be a wrong approach.

      Proposal :

      Clarify the text describing the optionality in the policy guidelines and in the Framework spec on how a policy author should use 
      assertions like
      <oasis:Replicatable/>.
      It's important that assertions like these can be usefully interpreted by knowledgeble requesters and safely ignored by requesters 
      unaware of them.