Re: NEW ISSUE 4130: Ignorable assertions must be ignored

Thanks, my idea was just to suggest a useful statement gets recorded :-)

Cheers, Sergey
  ----- Original Message ----- 
  From: Yalcinalp, Umit 
  To: Sergey Beryozkin ; Ashok Malhotra ; Christopher B Ferris 
  Cc: Frederick Hirsch ; public-ws-policy@w3.org ; public-ws-policy-request@w3.org 
  Sent: Monday, January 22, 2007 5:28 PM
  Subject: RE: NEW ISSUE 4130: Ignorable assertions must be ignored


  Great idea Sergey. 

  --umit




----------------------------------------------------------------------------
    From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Sergey Beryozkin
    Sent: Friday, Jan 19, 2007 5:23 AM
    To: Ashok Malhotra; Christopher B Ferris
    Cc: Frederick Hirsch; public-ws-policy@w3.org; public-ws-policy-request@w3.org
    Subject: Re: NEW ISSUE 4130: Ignorable assertions must be ignored


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

Received on Wednesday, 24 January 2007 12:56:18 UTC