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

Re: NEW ISSUE 4130: Ignorable assertions must be ignored

From: Sergey Beryozkin <sergey.beryozkin@iona.com>
Date: Tue, 9 Jan 2007 17:36:52 -0000
Message-ID: <008601c73414$bfc27150$3901020a@sberyoz>
To: <tom@coastin.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>

Hi

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

I agree that we don't need an atribute to mark the assertions which are always needed to be ignored.

> This is not the same as the current ignorable.
Agreed too.

It's just that I think wsp:ignorable assertions are purely informational assertions with no explicit  behavioral requirements on 
requesters. If a requester needs to do something to utilize the capabilities marked by this assertion then this assertion should not 
be marked as wsp:ignorable, should be a normal assertion, possibly marked as wsp:optional in the compact form... This is how I see 
it anyway...

if we had wsp:optional and wsp:informational then it might be clearer when to use wsp:informational as opposed to using 
wsp:optional.
Informational assertions are often naturally ignorable, though requesters working in a strict mode would have a chance to break at 
the intersection stage.

My own preference would be to either position wsp:ignorable as pure informational assertions which may or may not be ignored at the 
intersection stage or just rename wsp:ignorable to wsp:informational...


Cheers, Sergey



>
> 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 17:47:58 GMT

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