W3C home > Mailing lists > Public > public-ws-policy@w3.org > January 2007

Re: NEW ISSUE 4130: Ignorable assertions must be ignored

From: Tom Rutt <tom@coastin.com>
Date: Tue, 09 Jan 2007 11:19:16 -0500
To: Sergey Beryozkin <sergey.beryozkin@iona.com>
Cc: Anthony Nadalin <drsecure@us.ibm.com>, Ashok Malhotra <ashok.malhotra@oracle.com>, public-ws-policy@w3.org, public-ws-policy-request@w3.org
Message-id: <45A3C084.2050801@coastin.com>

Sergey Beryozkin wrote:
> Hi
>  
> Here's how I understand it.
To clarify:

I only suggested the new attribute "informational" if we agree (I myself 
do not yet see the need) on an asertion which always must be ignored.

This is not the same as the current ignorable.

Tom Rutt
> Suppose a requester working in a lax mode has these requirements :
>  
> <Policy><A/><B/></Policy>
>  
> A provider has this policy :
>  
> <Policy>
>    <A/>
>    <B wsp:ignorable="true"/>
>    <C wsp:ignorable="true"/>
> </Policy>
>  
> For the intersection to work requester's <A> and <B> must match 
> provider's <A> and <B>. It doesn't matter that the provider's <B> is 
> marked as wsp:ignorable. This is per the description on how the 
> intersection works in a lax mode : every non-ignorable assertion in a 
> requestere's alternative must match an assertion in a provider's 
> alternative and vice versa.
>  
> So now that the intersection is completed the next question is what to 
> do with "C" above. In a fully automated mode it can be truly ignored. 
> If we have an environment with a user sitting infront of the UI tool 
> then one option would be to show 'C' to a user so that a user can make 
> an additional note/cancel the intersection result, etc... This is how 
> I reckon one can advertize some features...
>  
> In a strict mode the intersection won't work for the above two 
> policies because according to the rules in a strict mode every 
> assertion in the requester's policy should match an assertion in a 
> provider's policy and vice versa. wsp:ignorable is not taken into 
> account. This is to address a case where requesters do not want to be 
> told that some assertions has to be ignored.
>  
> I suppose even in a strict mode one might offer a chance to users 
> sitting in fron of UI tool to act upon wsp:ignorable assertions which 
> caused an intersection failure as many wsp:ignorable assertions can be 
> truly safe to ignore.
>  
> One other minor concern is that we have now strict and lax modes, and 
> wsp:ignorable. As far as I understand one of the main motivations 
> behind the introducation of these two seperate modes is to be able to 
> break during the intersection when wsp:ignorable assertions are 
> encountered as described above. And we also have "you know what", I'm 
> afraid to refer to it :-), wsp:optional. One should use wsp:optional 
> to indicate assertions which require the requesters to optionally do 
> something.
>  
> But one can use in the anti-pattern way wsp:optional to mark the 
> assertions to achieve the ignorability in both strict and lax modes 
> and hence I'm concerned that may be a strict mode is something which 
> is not always working as well as on how to present in a crystal-clear 
> way that wsp:optional should not be used when wsp:ignorable is really 
> needed and vice versa.
>  
> Would it make sense to rename wsp:ignorable to wsp:informational ? Or 
> at least to present wsp:ignorable as a marker to be used for 
> informational assertions only. Will it clarify better what 
> wsp:ignorable assertions are all about ? Is it what Tom suggesting ?
>  
> For ex, in our case, we have iona:highlyAvailable assertions with no 
> wire manifestations which unaware requesteres can ignore but those who 
> undertand it would need to do something about it in the client 
> runtime. This assertion should be marked as wsp:optional as confirmed 
> by Asir in his reply to my earlier message.
> All other assertions with no behavioral requirements on the requesters 
> which can be ignored at the intersection should be marked as 
> wsp:ignorable/wsp:informational
>  
> Cheers, Sergey
>  
>  
>
>     ----- Original Message -----
>     *From:* Anthony Nadalin <mailto:drsecure@us.ibm.com>
>     *To:* Sergey Beryozkin <mailto:sergey.beryozkin@iona.com>
>     *Cc:* Ashok Malhotra <mailto:ashok.malhotra@oracle.com> ;
>     public-ws-policy@w3.org <mailto:public-ws-policy@w3.org> ;
>     public-ws-policy-request@w3.org
>     <mailto:public-ws-policy-request@w3.org>
>     *Sent:* Monday, January 08, 2007 7:27 PM
>     *Subject:* Re: NEW ISSUE 4130: Ignorable assertions must be ignored
>
>     So with Lax and Strict what is the usecase for ignorable ? as with
>     Lax you can make the choice to ignore the fact there is not an
>     intersection
>
>     Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
>     Inactive hide details for "Sergey Beryozkin"
>     <sergey.beryozkin@iona.com>"Sergey Beryozkin"
>     <sergey.beryozkin@iona.com <mailto:sergey.beryozkin@iona.com>>
>
>
>                             *"Sergey Beryozkin"
>                             <sergey.beryozkin@iona.com
>                             <mailto:sergey.beryozkin@iona.com>>*
>                             Sent by: public-ws-policy-request@w3.org
>                             <mailto:public-ws-policy-request@w3.org>
>
>                             01/08/2007 12:35 PM
>
>     	
>
>     To
>     	
>     "Ashok Malhotra" <ashok.malhotra@oracle.com
>     <mailto:ashok.malhotra@oracle.com>>, <public-ws-policy@w3.org
>     <mailto:public-ws-policy@w3.org>>
>
>     cc
>     	
>
>     Subject
>     	
>     Re: NEW ISSUE 4130: Ignorable assertions must be ignored
>
>     	
>
>
>     Hi
>
>     "- ASSERTIONS THAT THE OTHER PARTY SHOULD NEVER SEE
>     Such as logging. These are private to my implementation.
>     Glen: Such assertions should be removed prior to intersection and
>     never exposed to the other party.
>     Ashok: They can be included in the policy and always 'ignore' d."
>
>     S.B. Ashok what you're suggesting is exactly what we were trying
>     to pursue with our wsp:local proposal, without success :-). We
>     wanted a standard attribute which can be used to mark private
>     assertions (would be useful for writing generic tools, etc),
>     furthermore we were agreeing that such assertions must be stripped
>     of, but ignored by requesteres if leaked (inadvertently or due to
>     some constraints).
>     Now that we have wsp:ignorable I don't see a way of getting
>     back...So I agree with Glen.
>
>     As was noted before, you can now use a lax mode if you want your
>     provider assertions be ignored. Otherwise, why to expose
>     assertions which need to be always ignored ? Assertions are for
>     requesters.
>
>     "
>     - ASSERTIONS THAT CANNOT BE MATCHED BY MACHINE
>     A: I think these are useful to include in policies for advertising.
>     For example, legal or privacy policies. Users cannot match on
>     these but will look at them and decide whether to use a particular
>     service or not based on their contents.
>     These too must be always 'ignore' d during intersection.
>     G: Such assertions should not be included in policies but, rather,
>     included in some other metadata bucket.
>     A: But we have not defined any other metadata buckets. "
>
>     S.B. I agree that these are useful to include in policies for
>     advertising. Two options :
>     * Make these assertions as "ignorable" and use the lax mode to
>     handle such policies. This will require a smart requester UI tool
>     which will offer users a chance to vote on "ignorable" provider
>     assertions which have not been understood during the intersection.
>     * As Tom noted, you can use a strict mode too. This will require
>     requesteres though to be aware of these assertions in advance.
>
>     "- ASSERTIONS THAT THE OTHER PARTY MAY BE ABLE TO MATCH
>     G: If he can match the assertions, great! If not, he should be
>     able to proceed even if he cannot match. This is the rationale for
>     lax and strict matching.
>     A: I accept this usecase but that's not what I was thinking of."
>
>     So if you agree with Glen here then I'm not qute sure what exactly
>     is your scenario...
>
>     Thanks, Sergey
>
>
>
>
>     Glen Daniels and I had a chat about 'ignorable'.
>
>     It turns out, not surprisingly, that we had different usecases in mind
>     and different ideas as to how they should be handled.
>
>     Here is a summary of our positions. Please respond if you have
>     views on
>     them.
>
>     Glen, please correct me if I have misrepresented your positions.
>
>     - ASSERTIONS THAT THE OTHER PARTY SHOULD NEVER SEE
>     Such as logging. These are private to my implementation.
>     Glen: Such assertions should be removed prior to intersection and
>     never exposed to the other party.
>     Ashok: They can be included in the policy and always 'ignore' d.
>
>     - ASSERTIONS THAT CANNOT BE MATCHED BY MACHINE
>     A: I think these are useful to include in policies for advertising.
>     For example, legal or privacy policies. Users cannot match on
>     these but will look at them and decide whether to use a particular
>     service or not based on their contents.
>     These too must be always 'ignore' d during intersection.
>     G: Such assertions should not be included in policies but, rather,
>     included in some other metadata bucket.
>     A: But we have not defined any other metadata buckets.
>
>     - ASSERTIONS THAT THE OTHER PARTY MAY BE ABLE TO MATCH
>     G: If he can match the assertions, great! If not, he should be
>     able to proceed even if he cannot match. This is the rationale for
>     lax and strict matching.
>     A: I accept this usecase but that's not what I was thinking of.
>
>     All the best, Ashok
>
>     > -----Original Message-----
>     > From: _public-ws-policy-request@w3.org_
>     <mailto:public-ws-policy-request@w3.org> [mailto:public-ws-policy-
>     > _request@w3.org_ <mailto:request@w3.org>] On Behalf Of Ashok
>     Malhotra
>     > Sent: Tuesday, January 02, 2007 6:37 AM
>     > To: _public-ws-policy@w3.org_ <mailto:public-ws-policy@w3.org>
>     > Subject: NEW ISSUE 4130: Ignorable assertions must be ignored
>     >
>     >
>     >
>     >
>     > Title
>     >
>     > Ignorable assertion must be ignored
>     >
>     > Description
>     >
>     > At the last f2f meeting the WS-Policy WG agreed to add an
>     attribute called
>     > 'ignorable' to the WS-Policy assertion syntax. We think this is
>     a step in
>     > the right direction. The WG, however, blunted the effect of this
>     change
>     > by
>     > allowing the ignorable attribute to be ignored during policy
>     intersection
>     > by
>     > allowing two intersection modes one of which honors the ignorable
>     > attribute and the other which ignores it.
>     >
>     > We argue this creates a problem as the parties attempting to
>     agree on a
>     > policy alternative may use different forms of the intersection
>     algorithm
>     > and come up with different solutions. A standard that allows such
>     > variation is not very useful.
>     >
>     > We suggest that the policy intersection algorithm be changed so that
>     > assertions marked ignorable are always ignored.
>     >
>     > Justification
>     >
>     > See above.
>     >
>     > Target
>     >
>     > WS-Policy Framework
>     >
>     > Proposal
>     >
>     > 1. In section 4.5 Policy Intersection, add a third bullet after
>     the first
>     > two bullets that says:
>     > o Assertions with ignorable = 'true' are ignored in during policy
>     > intersection.
>     >
>     > 2. Remove the first bullet, including its sub-bullets from the
>     second set
>     > of 2 bullets.
>     >
>     > 3. Add an ignorable assertion to the following example.
>     >
>     >
>     >
>     >
>


-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133
Received on Tuesday, 9 January 2007 16:19:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:45 GMT