Re: NEW ISSUE 4130: Ignorable assertions must be ignored

+1

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 377 9295

"Sergey Beryozkin" <sergey.beryozkin@iona.com> wrote on 01/19/2007 
08:22:47 AM:

> Hi
> 
> "ignorableness is at the discretion of the policy consumer"
> 
> It would be nice for this statement be added to the primer IMHO...
> 
> Cheers, Sergey
> ----- Original Message ----- 
> From: Christopher B Ferris 
> To: Ashok Malhotra 
> Cc: Frederick Hirsch ; public-ws-policy@w3.org ; public-ws-policy-
> request@w3.org 
> Sent: Tuesday, January 09, 2007 5:40 PM
> Subject: RE: NEW ISSUE 4130: Ignorable assertions must be ignored
> 
> 
> Ashok, 
> 
> <hat mode="off"> 
> I think that you are still missing the point that ignorableness is 
> at the discretion of the policy consumer. 
> You have not, IMO, expressed a use case in which the policy provider
> needs to assert that the 
> assertion be ignored (must ignore) save for the use case in which 
> configuration information is 
> expressed, but I thought that we had agreed that you could use a 
> proprietary attribute for that 
> and filter these out prior to making the policy available to te 
> outside world. I believe you even 
> indicated that that was indeed what Oracle was already doing. You 
> had also expressed, 
> if I recall correctly, that that was perfectly adequate for your 
> needs. What am I missing? 
> </hat> 
> 
> Cheers, 
> 
> Christopher Ferris
> STSM, Software Group Standards Strategy
> email: chrisfer@us.ibm.com
> blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
> phone: +1 508 377 9295 
> 
> public-ws-policy-request@w3.org wrote on 01/09/2007 11:08:22 AM:
> 
> > 
> > Frederick:
> > The purpose of my note was to try and spell out the different 
> > usecases people had in mind for 'ignorable' and see if the current 
> > design covers all the usecases and ask for reactions.
> > 
> > So far, I have heard some people argue that we need another 
> > attribute, perhaps called 'informational' that indicates that the 
> > assertion is always ignored.
> > 
> > Sergey also seems to have a understanding of 'lax' semantics that 
> > is, at least, different from mine.
> > 
> > 
> > All the best, Ashok
> > 
> > > -----Original Message-----
> > > From: Frederick Hirsch [mailto:frederick.hirsch@nokia.com]
> > > Sent: Tuesday, January 09, 2007 7:47 AM
> > > To: ext Ashok Malhotra
> > > Cc: Frederick Hirsch; public-ws-policy@w3.org
> > > Subject: Re: NEW ISSUE 4130: Ignorable assertions must be ignored
> > > 
> > > This summary does not argue for any change to the framework, however
> > > this information could be helpful for the guidelines. Is that the
> > > intent?
> > > 
> > > Assertion authors should depend on business intentions and the
> > > details of the assertion semantics for decisions whether to include
> > > assertions and whether to mark ignorable, so we are not proposing
> > > rules, but rather considerations.
> > > 
> > > comments inline.
> > > 
> > > regards, Frederick
> > > 
> > > Frederick Hirsch
> > > Nokia
> > > 
> > > 
> > > On Jan 7, 2007, at 5:07 PM, ext Ashok Malhotra wrote:
> > > 
> > > >
> > > > 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.
> > > 
> > > They could not be ignored if the requestor wishes to use generic
> > > intersection for match, e.g. wants to be assured that provider does
> > > logging..
> > > 
> > > >
> > > > - 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.
> > > 
> > > Again they could be included in policy, marked as ignorable or not.
> > > 
> > > >
> > > > - 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] On Behalf Of Ashok Malhotra
> > > >> Sent: Tuesday, January 02, 2007 6:37 AM
> > > >> To: 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.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > > 
> > 
> >