- From: Sergey Beryozkin <sergey.beryozkin@iona.com>
- Date: Tue, 9 Jan 2007 17:36:52 -0000
- 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 UTC