WS Policy WG (May 2007 f2f, day 1)
23 May 2007

<cferris> RESOLUTION: minutes from 5/16 approved as posted

<dorchard> scribe: dorchard

<scribe> scribenick: dorchard

<whenry> I got a 403 error when I tried that Link above

<maryann> thank you william

future meetings

<maryann> (we;re talking about the F2F)

<fsasaki> http://www.w3.org/2007/07/ws-policy-f2f-logistics.html f2f in Ireland, hosted by Iona

<whenry> Go ahead talk about me behind my back ! ;-)

almost everybody present here will be present at next f2f

<whenry> Excellent!

<whenry> Charlton, Fabian, William there too!

Thursday will be discussion on follow on f2f

editors report

<cferris> http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0249.html

sent off the guidelines doc last week, primer the week before.

<fsasaki> dorchard: one action was not completed

<fsasaki> chris: on the agenda

AI review

279 review: have on their agenda a 2nd lc of wsa metadata

<whenry> Peaceful ..

AI 286: maryann will have BOF table @ lunch today.

<Fabian> The microphones are picking up several people speaking

<Fabian> uncertain identities :-)

Agenda item 7

AI 290

<cferris> RESOLUTION: issue 4522 closed with resolution proposed in http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0051.html

Bug 4567

4572 suggests it should be lowercase..

<PaulC> 4567 and 4572 proposal: http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0265.html

<cferris> RESOLUTION: issues 4567 and 4572 closed with proposed resolution in http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0265.html

Bug 4568: latest namespaces

<cferris> http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0266.html

<cferris> RESOLUTION: issue 4568 closed with proposal in http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0266.html

Bug 4571: QNames/NCNames

<cferris> http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0233.html

<cferris> RESOLUTION: issue 4571 closed with proposal in http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0233.html

Bug 4575:

<cferris> http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0258.html

<cferris> RESOLUTION: issue 4575 closed with proposal in the submitted issue http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0258.html

paulc: how will all the changes get in?

paulc/chris: could editors do in real-time?

asir: seems like impls have already done the "right thing" wrt these fixes

<cferris> http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0009.html

are nested policy assertions part of vocabulary?

related to scalability issue.

cferris: who agrees with ashok that Dan's answer is correct wrt to what it says, but would prefer that the policies intersect.
... ashok, dave

<monica> pong

dale: at the framework level or domain

all: at the framework level.

related 4561, can domain processing "opt-in" to intersection

cferris: if we went with the approach that the framework always intersects, which opposite of current

monica: are there cases in other domains that would take advantage of such matching?

<cferris> ack

monica: did other domains make a mistake assuming absence would match?

tom: seek stability
... ws-a does not want to rely on domain specific processing
... want stability, but could live with it IF we had done it before CR.

<Fabian> there is only one domain that introduced and uses nested policies. we should make sure we do what WS-SecurityPolicy requires.

<fsasaki> dorchard: problem I have: ws-addressing comes with something, others come with other requirements

<charlton> indeed

<fsasaki> .. there is no way to learn from ws-addressing implementation

<fsasaki> .. ws-addressing, ws-security ends up to have to do the same kind of workaround

<fsasaki> ashok: and we don't fix it

<fsasaki> paulc: you go back to WD and it will be done in 6 months

paulc: we could go back to WG and then take 6 months

cferris: who cannot live with the status quo?

<Fabian> can live with status quo, can not live with Dan's interpretation

cferris: on question 1

no hands

fabian: we need to coordinate with ws-security policy
... probably if we did the right thing for ws-security policy, we cover all the cases
... we introduced nested policy for ws-securitypolicy

<PaulC> no hands

<charlton> can live with status quo

<PaulC> pbc hand

<cferris> raise hand

<monica> raise hand

we have now learned that "xyz hand" is long form

<fsasaki> dorchard: runtime protocol specs said they will not wait for ws-policy

<fsasaki> .. "we will not rely on the CR version of the spec", like RM

<fsasaki> tRutt: rm does both

<fsasaki> dorchard: so policy is of the hook, they decided not to wait

<fsasaki> .. that gives us some room from a scheduling perspective

cferris: except ws-addressing

ashok: what would happen to ws-security policy asked by fabian
... if we adopt this, it would become easier to use securitypolicy
... could say <x509></x509> would match with all the myriad variations.
... make life much much easier

paulc: refutes ashok, assumes they wouldn't add anything under x509
... if they revved security policy after policy revved, then there would be a problem

monica: we have that condition anyways

paulc: if I explicitly state what I support, then I'm robust.
... if I then do wildcards, then somebody can add something new
... if you go look at ws-securitypolicy, they point to 1.5

<PaulC> SP: http://www.oasis-open.org/apps/org/workgroup/ws-sx/download.php/23821/ws-securitypolicy-1.2-spec-cs.pdf

<whenry> regrets, I must drop off for another call. Will be back afterward.

lines 171 to 173

monica: if we look at a nested policy expression, ... look at definitions

<maryann> since a nested assertion ( according to our definition) means that the behavior qualifies a parent assertion

<maryann> then at some level the "empty" does imply a certain level of behavior since the parent or root is expressing some behavior

monica: have to ask whether nesting is exclusive or additive?

felix: this would create versioning problems, and problems with proposal from ws-addressing

<maryann> the nested could be additive behavior rather than exclusive behavior that might conflict if you tried to match an empty with a specific sub-assertion

asir: go back to ashok's point that wildcard wouldn't break security policy

<Nadalin> yes it would break SP

<asir> Bottom of Section 3.9 http://www.w3.org/TR/2007/WD-ws-policy-primer-20070330/#nested-policy-expressions

<maryann> i think it depends on the assertion

<Nadalin> it would break anyone use of assertions

<maryann> and the fact that these assertions were designed with an assumption about how the algorithm currently works

asir: brings up httpstoken with parameters

<prasad> Yes in general we cannot guarentee that a nested one would always match empty. In some cases it would and some cases it may not. Depends on the specific case

ashok: no, that's domain specific.

asir: if you have a nested policy, then it indicates any behaviour.
... this is hard to imagine an app that supports all options

cferris: don't buy the argument that if I added new extension then I'd get a false positive.
... in the case if I had all the options (ie security policy) then compare all those
... vs letting subsequent behaviour figure out cipher suite..
... had we gone that direction, it might not have been that bad.

<Zakim> dorchard, you wanted to follow up on paul's rebuttal and to ask how ws-sp uses policy 1.5

<fsasaki> dorchard: paulc was arguing against the wildcard proposal based on ws-security policy does

<fsasaki> paulc: I looked at the ws-sx spec, you statement was wrong

<PaulC> Charter text: Web Services Policy should remain compatible with existing policy assertions and offer a smooth migration path for these assertions (where applicable). Existing policy assertions (in specifications that have been submitted to other standards groups) are Web Services Reliable Messaging Policy, Web Services Security Policy, Web Services Atomic Transaction, and Web Services Business Activity Framework.

<fsasaki> dorchard: am I talking against an implementation or a WG?

<fsasaki> paulc: reply is citation from charter text above

<fsasaki> paulc: dorchard said "other TCs have gone ahead without policy, so we can do what the want". That is not true

<fsasaki> .. ws-sx will reference also the CR version of policy

<fsasaki> dorchard: how will security policy use policy?

<fsasaki> .. what will the impact of the change be to security policy? It will break their current work, but they might benefit in the future

<fsasaki> .. what is the compatibility issue?

<fsasaki> paulc: go back to WD, change the NS

<fsasaki> dorchard: they have a reference, but how is policy used?

<fsasaki> maryann: it is more than just a reference, it is deep in the spec

<fsasaki> asir: it is a normative depdendecy

<PaulC> I supplied my comment above in the Charter text.

<cferris> we are breaking for 20 mins

<cferris> ---------------------

<Fabian> Charlton, seems like you got the P6 and P9 wrong :-)

<Dug> http://www.soaphub.org/interop/status/WSPolicyInteropStatus (pwd: wspolicy)

<maryann> <break conversation for posterity> there are issues for security policy, when a service takes the option of wildcarding...the use case for the customer side is easier to illustrate.

<maryann> when the service is the one doing wildcarding it becomes very difficult with all the extensibility points in security & security policy, to understand what the service is willing to do....

<maryann> in some sense it would be asserting it could do "anything" that the customer would have in its own policy, and it would be difficult to see how this range of options would be determined, assessesed for interoperability

<maryann> the customer "could" extend with tokens, that the service was not aware of

<maryann> there would need to be more constraints on these extensiblity points

bug 4558 is related..

<fsasaki> continuing meeting

cferris: dispose this, then get back to 4558.
... we have consensus that Dan's message has described the spec.

<fsasaki> Ashok: not technical points, but about the process

ashok: security policy agreed to refer to policy 1.2 and policy 1.5

<fsasaki> .. Paul mentioned that security policy agreed to refer to policy 1.5

ashok: not whole story
... they also have charter to change policy reference(s) (1.2 and 1.5 CR) to policy 1.5 rec

paulc: are you inferring that they were expecting 1.5 ns to change?

This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

<cferris> paul, concerned that were we to place the /ne/ namespace in jeopardy, that the sx, et al tcs might change their direction

ashok: 2nd point, tired of the stick "you really want to make this change, it'll go back 6 months"
... if we have to go back, then ok.
... let's not use this to stop discussion

cferris: trying to finish this agenda item..
... for those left in the queue, I'd like to close this agenda item.
... do any of you have concerns related to this thread that are not captured by 4558 or 4560 or 4544

asir: what is disposition of this is the example?

prasad: leaving default behaviour as is, and give assertion authors chance to over-ride in domain specific

cferris: 4561

<TRutt__> Empty as wildcard has problems for nested policy, it woujld be better to define a standard wildcard, which can be put into scope for parent policy for which wildcarding is appropriate for matching. I believe wildcarding is not approporated for all assertions which have nested policy assertion types This could be addressed in v.next

cferris: asir, please open issue wrt need better example of empty nested policy item.

<cferris> http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0210.html

<asir> New issue is http://www.w3.org/Bugs/Public/show_bug.cgi?id=4577

<cferris> RESOLUTION: issue 4577 closed with proposal in http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0210.html amended to change 'default' to 'framework'

4544 policy vocabulary will not be applied

paulc: how will we proceed?
... what are people's favourite items to talk about?
... perhaps each person talk about what they think is most important.
... heard a suggestion from ashok that dorchard's taxonomy be the starting point.

<prasad> http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0264.html

<fsasaki> (now discussing mail from dorchard above)

<fsasaki> dorchard: tried to describe actual differences between 4 positions I see

<fsasaki> .. in terms of requester / and provider and "pseudo set theory"

<fsasaki> .. I had a single scenario to describe the differences

<fsasaki> (dorchard describes the mail, agreement that the mail is correct until "Strict intersection yields no intersection.")

<fsasaki> now discussing the part starting "There is a policy <Z/> ..."

<fsasaki> cferris: there are two flavors of that: talking about assertion vs. behavior

<fsasaki> dorchard: let's talk about assertions only now

<fsasaki> cferris: ok

<fsasaki> dorchard: nobody is proponent for 1. about "2. AIN Closed world flavour : "

<fsasaki> asir: nobody advocates 2 now

<fsasaki> cferris: agree

<fsasaki> .. IBM never advocated 2

<fsasaki> paul: let's skip history and get through analisys

<fsasaki> dorchard: +1. (now going through option 3/4)

<fsasaki> TRutt: is "client" and "behavior initiator" the same?

<fsasaki> dorchard: for the purpose of this yes

<fsasaki> ashok: question on 3: one use case: both provider and requester have published policies

<fsasaki> dorchard: the scope here is the simplist possible case, somebody starts an HTTP connection and picks up stuff

<fsasaki> ashok: (starts to ask question on 3)

<fsasaki> paul: hold the question, answer will come

<fsasaki> dorchard: now about the table

<fsasaki> maryann: why the "will" column?

<fsasaki> dorchard: client has an intersection result and it will do a,b. It is not a "MUST" because of the intersection

<fsasaki> paul: so this is for the lax intersection case

<fsasaki> dorchard: yes, for strict case the table is boring

<fsasaki> .. will or will not is about the intersection, must and "must not" are about both requester and provider

<fsasaki> .. so will and will not is about the requester only

<fsasaki> paul: everybody agrees with the "will" column?

<fsasaki> ashok: is the will column about requester and provider?

<fsasaki> paul: david said that

<fsasaki> cferris: I think "will" column applies to both

<fsasaki> (discussion on the restructuring of the column currently done by cferris)

<fsasaki> cferris: important to see "who initiates the behavior?" that is different than requester / provider

<fsasaki> .. I am only constraining the initator

<fsasaki> dorchard: I don't agree

<fsasaki> .. in a single interaction, a provider behaves as a response

<fsasaki> cferris: I am not constraining the behavior of a response

<whenry> But how do you really feel?

<maryann> there is a bit of a passionate discussion happening live

<maryann> for those of you remote, we ask your tolerance

<fsasaki> (problems of following the discussion for remote participants, paulc says nothing we can do about that in the current discussion)

<maryann> and we will try to capture the discussion in the scribed text

<whenry> May need to change the rating to "R" ;-)

<fsasaki> dorchard: what are the behaviors in the follow up of an interaction?

<fsasaki> paulc: cferris says the interaction does not constrain the provider

<maryann> chris does not believe that the intersected alternative constrains the provider behavior

<maryann> david seems to have a different view of the behaviors for either party

<maryann> david had tried to reduce the behaviors to a common set and chris feels the distinction is relevant and hence the reduction loses some characterization of behaviors thats important to capture

<fsasaki> dorchard: in the policy framework, there is no constraint on the provider whether it must do D (from cferris perspective)

<fsasaki> cferris: in the policy framework , there is no mechanism to tell which alternative I choose

<fsasaki> .. I'm trying to make a statement in the spec to make clear: if I know what an assertion means in terms of its behavior, and it is not in the alternative selected, it will not be applied

<fsasaki> paulc summarizes:

<fsasaki> paulc: requestor will exibit a,b,c and must not do E. Z,Y,C,D are out of scope

<fsasaki> (proposal is not on IRC)

<fsasaki> paulc: using intersection means "there is an entity that initiates the intersection", in cferris proposal

<fsasaki> .. if messages are going in the other direction, roles are changed

<prasad> ashoh hand

<fsasaki> ashok: I have a policy and do a policy intersection. What I must no do is: the behaviors which are in my policy included

<fsasaki> cferris: correct

<fsasaki> paulc: you do not the things which are in your policy, not talking about the other guy

<fsasaki> paulc: would ashok be happy with the words which asir proposed at http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0259.html ?

<fsasaki> ashok: yes, but with what we have now , we might reword them again

<fsasaki> paulc: cferris, are you fine with what we have now?

<fsasaki> cferris: vocabulary based AIN was subtly different. Now we are constraining what you know

<fsasaki> paulc: two tasked over lunch: 1) take cferris proposal with Asirs text: would that make ashok happy?

<fsasaki> .. and 2) request from dorchard to look more at open world proposal, and 3) from monica

<fsasaki> .. some editorial items

<fsasaki> monica: already in the mail archive

<fsasaki> .. what we have now on the screen should go to the primer

<cferris> we are taking a lunch break... back at 1:00 pm ET

<cferris> email that captures the "whiteboard" dicussion this morning: http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0269.html

<cferris> hi david

<cferris> we will be starting in 15 mins

<maryann> scribenick: maryann

<scribe> scribeNick: maryann

<scribe> scribe: maryann

just resuming

paul needed to leave but will be back

David Hull's CR issues discussion

wasn't intending to deal with subtleties, the motivation is to represent some things that came out of the work in WS-Addressing in their attempts to define assertions for the addressing behavior

david - trying to help offer some feedback on reading the policy document, thinks there are some simple ideas that didn't come across

david: some of the behavior you get with bags as a result of intersection is hard to grasp
... normalizing policy expressions seems to be indirect

starting with http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0000.html

<cferris> http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0243.html

takes a long time to get through the material, paul responded that we considered using other ways of expressing the rules, and it is acknowleged that in retrospect you can always see how you could do something different, but not advocating we do that at this time in the process

chris: is there a short path that could augment what is there with a simple summary?

david: normal form is just a policy

this could be a simplifying principle

chris: is there openess in the working group to try to create some rules to augment the current text?

more of when the rules apply

is the critical thing that is missing

commutivity applies because policies are unordered

that's not a normalization rule

assciativity applies pretty clearly

distributive would be good to state that its a normalization rule

a sentence or two at the beginning of each rule might help

ashok: think the spec would be better with more formal rules

chris: prescriptive, right?

ashok: yes

david: i agree this is formal without being rigorous

asir: i heard dave say he wanted an opening statement.

chris: : i'm talking about text to augment

david: more text for motivation and guidance on when these rules apply
... its kind of there in the examples, but it would be good to pull it out

asir: there is a mapping from the normal form to the policy

<cferris> http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0243.html

chris: this is a description of what the normal form is

<cferris> http://www.w3.org/TR/2007/CR-ws-policy-20070330/#normalization

<Levogiro> PUTOOOOOOOOOOOOOOOOOOOOS!!!!

asir: set of axioms are defined
... 4.1 states the mapping

ashok: what does that mean?

asir: data model

david: map from expression to a policy is first find normal form expressions and here are some normal form rules
... from a mathematical point of view there are some holes
... some of the text seems vague
... its a declarative and axiomatic approach

chris: are you asking for motivation in 4.3.6?

david: yes
... now that i understand i can go off and craft some specific statements

chris: that's what i was looking for

asir: 4.3.6 has hyperlinks to the axioms

<prasad> http://www.w3.org/TR/2007/CR-ws-policy-20070330/#normalization

chris: what i would recommend is that if you could come up with some specific statements to give this some motivation, the WG is happy to take a look at that

paul: normal form doesn't have a definition, it points to section 4.1 .....used the hyperlink to show the rules, isn't that what you want

david: i think its all in there someplace, but as a newcomer is its hard to find

paul: its a backward reference so maybe that was wrong
... and there is no definition and that phrase is used quite offten
... david is asking for a motivation

david: it says the intent is to facilitate interoperability
... really what it does is ground the mapping from expression to policy
... section 4.1

where it defines the element

david: not clear that putting out all lines in a normal form makes things simpler

paul: it says should
... and if you have a long policy that's a good reason

david: here we're saying that you will have to deal with non-normative expressions, the motivation seems odd
... i think we've hit most of the points

chris: i think the group understands your concerns

<PaulC> Consider changing: The following rules are used to transform a compact policy expression into a normal form policy expression:

chris: hopefully if you could express some suggested changes in the form of " please do x, y , z" ...preferably not a chinese menu :-)

<PaulC> to inlcude a reference to 4.1 for "normal form policy expression"

chirs: WG is willing to entertain improvements

<cferris> http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0007.html

chris: this thread led to the realization that your terms and asirs terms are consistent

<PaulC> and to include a reference to 4.3 for "compact policy expressions"

david: yes, there was some discussion back and forth
... so i understand that "a" is different from "a,a"
... alternatives that come out of intersection are going to be different than alternatives that come in from either side
... there is no requirement that a policy be reduced to a policy with only one alternative
... policies have set semantics and alternatives have bag semantics

chris: this is a general issue

david: i think the ambiguity is gone from the text

chris: 4552, policies are sets not bags,
... there's a proposal from asir, to add text

david: if that's what you want to say, yes

asir: yes that's what we want to say

<fsasaki> see mail http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0062.html from asir

paul: the code that needs to know about different parameters is not in our hands
... you can't tell at intersection that they are the same

davidO: in owl you can say two things are the same

david: you can tell if you have two assertions are spelled exactly the same
... same infoset
... doesn't mean same infoset it means same assertion

paul: what benefit do i get from eliminating duplicates?

ashok: the algorithm is that they take the alternatives and they pull out the assertions and they apply the same thing twice, like encryption

david: seems like the use case doesn't give the result ( in the primer)

<dhull> It seems that in most use cases it doesn't matter exactly what result comes back, just that it comes back at all

chris: we're sliding into the weeds......we could argue about whether polcies should be bags or sets of alternatives, i think it only matters that it might be simpler
... we have a proposal for a clarification
... so david, are you satisfied with that?

david: yes
... given that the group has discussed this and said they're ok with it, then i'm ok with it

davido: there is still an issue around duplicates at the end of intersection

monica: section 3.2 says that duplicates may exist

david: there is a direct testable assertion that should be in the interop tests

<cferris> RESOLUTION: issue 4552 closed with text in http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0062.html placed in Terminology section and referenced (linked) from uses of the term as deemed appropriate by editors

<cferris> RESOLUTION: issue 4556 is closed with proposal offered in issue description

<cferris> If two alternatives are compatible, their intersection is an alternative

<cferris> containing

<cferris> all of the occurrances of all of the assertions from each of the alternatives

<cferris> (i.e., the bag

<cferris> union of the two).

<cferris> If two alternatives are compatible, their intersection is an alternative

<cferris> containing

<cferris> all of the occurences of all of the assertions in both alternatives

<cferris> (i.e., the bag

<cferris> union of the two).

<cferris> RESOLUTION: issue 4553 closed with the above text modifying the existing text in section 4.5

david: 4555- the use of ther term "intersection" was confusing , but the definitions do explain what the group means
... i might consider "aggregation" or some other term

chris: i do think that our use of the term might introduce confusion, and would it help to have a link to see what we mean and disambiguate it from set intersection

david: some kind of softening might help

ashok: it would be good if we had an exact word

<dhull> "pairwise bag union of compatible alternatives"

paul: give us one
... i'm trying to make a proposal

<dhull> "Policy Intersection is an operation, analogous in some ways to set intersection ..."

paul: policy intersection does not appear in the terminology

<dhull> or "analogous in some cases ..."

ashok: would it be useful to say....and yyy is used for....

paul: that's what it says in 4.5
... you could introduce text and links
... introduce text in a note....."the use of the term intersection does not imply set semantics:

david: you could say policy intersection ....is analogous to set intersection in some cases....

asir: 3rd sentence in first paragraph

<PaulC> Org text:

<PaulC> Intersection is a commutative function that takes two policies and returns a policy.

<PaulC> New text:

<cferris> Policy intersection is communtative operation performed on two policies that yields a policy that contains a collection of the compatible policy alternatives. (Note: while policy intersection at times is analogous with set intersection, it does not imply formal set intersection semantics)

david: if i had had that term i would have had fewer false assumptions

<cferris> RESOLUTION: issue 4555 closed with the above definition for policy intersection added to Terminology section

http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0261.html

chris: there is a proposal from asir that may allow us to close this

issue 4554

david's reply http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0268.html

david: if that is what the WG means then it should be stated

<scribe> ACTION: Paul to make sure that the additional suggestions are not lost for the non-normative docs [recorded in http://www.w3.org/2007/05/23-ws-policy-minutes.html#action01]

<trackbot> Sorry, amibiguous username (more than one match) - Paul

<trackbot> Try using a different identifier, such as family name or username (eg. pknight, pcotton2)

<cferris> RESOLUTION: issue 4554 is closed with the proposal in http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0261.html to change the text in the first paragraph in section 4.5

<fsasaki> ACTION: pcotton2 to make sure that the additional suggestions are not lost for the non-normative docs related to issue 4554 [recorded in http://www.w3.org/2007/05/23-ws-policy-minutes.html#action02]

<trackbot> Created ACTION-300 - Make sure that the additional suggestions are not lost for the non-normative docs related to issue 4554 [on Paul Cotton - due 2007-05-30].

asir: the last issue from David's mail is the issue addressed in 4561

chris: resuming agenda item from before lunch

Issue 4544: policy vocabulary, will not be applied, oh my! Chris Ferris (11:00 am ET)

DavidO- would like to explore the open world

DavidO- this proposal is close to the one called "open world"

DavidO- I've had some trouble with the terms

DavidO- so i'd like to run through this on a more complicated message exchange

DavidO- terms initiatior is this protocol or wsdl in message

taking the Open world from the text proposed from David .....must do what is intersected and that's it

ashok: open world says nothing about what you must not do

david o - you said you can't live with this

chris-- the term "optional" means that there are two alternatives, not that the behavior is optional

davido- the requestor says RM optional

chris- its a matter of being precise in the use of the optional

davido- i don't understand the stridency of your position

davido- if the client choses to do something why is this so bad?

<whenry> Can the speakers speak up please?

i'll ask william, sorry

chris =- i'm making a big deal because if i don't use wsp:optional and I only have alternatives, and I am able to just select things to do anyway, then it negates the value of providing explicit alternatives

davidO: under my definition that's fine

dale: why did you put Y under must not? ( to chris)

chris -- no i didn't that's david's option

paul: your point is that optional is a macro

chris: yes

paul: imagine the case you have 16 alternatives

( to david)

paul: and you get back the one that doesn't have "e" in it, are you expecting that you can go back and if you find "e" is in it you can

davidO: i think its foolish for a client to do that, but its not necessary in the spec to say that

monica: i'd like to hear from dale, because he raised these issues about open & closed
... there was a long dicussion in WS-TX and they had a hard time characterizing their assertions because they didn't know how to represent it

davidO: i want to try to champion chris's point of view to prove that i understand it

daveO: the requestor has this policy and there might be a bunch of things that the provider does that it may or may not be able to do
... in intersection, it explicitly asked whether E was a behavior to do

<Zakim> daveo, you wanted to say chris' point

daveO: if you add behaviors that you didn't get back in intersection then you are throwing out the value of intersection

monica: they had a conundrum and they came to a point where they only expressed what they were required to do

chris: if you can do what you want, what's the value of policy?

paul: we could define the syntax, but intersection has no value

<whenry> +1

paul: its a contract, i'm going to get your policy and this is what i'm going to do as a result of that

daveO: I want to see this under a more complicated message exchange pattern, i don't know what an entity that engages in an interaction means

paul: you're going to do that make connection to someone
... then something comes back....its got to be going to something

chris: you already did from a reliable message connection ....from a web services perspective you already did policy intersection with paul to send them originally
... so you know what's going on here
... you are the entity engaging in that interaction
... conversely, asynchronously, paul;s going to send messages asynchonously and reliably

davidO- when you engage in an interaction, what do you mean?

chris: i have an endpoint

david: what about an endpoint with multiple messages
... its the first one, that you're engaging in

chris: angels dancing on the end of a pin
... you want to know how do i talk to paul
... so you go and get his policy

davidO; how does this map to the subjects we define

paul: that's what attachment states
... if you have some at one subject or at another subject, that's the one you have to apply the algorithm on that subject

that why we have subject granuarlity in the policy subjects

chris: we would just like to not have subjectivity in what you can do
... if we say you can do a or b, we want it to be either a or .b
... not that you can do a and b
... we want it to have predictability

david O --- why say in the spec MUST not

chris- it doesn't say must not

paul: is the only question about the verb

<whenry> What text?

paul: straw poll, how many people can live with the text "If an initiating entity includes a policy assertion type A in its policy, and this policy assertion type A does not occur in an intersected policy, then the initiating entity does not apply the behavior implied by assertion type A. If a policy assertion type Z is not included in the policies being intersected then the intersected policy says nothing about the behavior implied by the assertion type Z

(delay for cut and paste)

<whenry> only reading it now

5 can

2 cannot

(editing)

"If an initiating entity includes a policy assertion type A in its policy, and this policy assertion type A does not occur in an intersected policy, then the initiating entity SHOULD not apply the behavior implied by assertion type A. If a policy assertion type Z is not included in the policies being intersected then the intersected policy says nothing about the behavior implied by the assertion type Z."

<whenry> Can live with the inital text

6 can

<whenry> I can live with it

<whenry> Can live with should not but kinda like first one

P1 -"If an initiating entity includes a policy assertion type A in its policy, and this policy assertion type A does not occur in an intersected policy, then the initiating entity does not apply the behavior implied by assertion type A. If a policy assertion type Z is not included in the policies being intersected then the intersected policy says nothing about the behavior implied by the assertion type Z."

P2- "If an entity includes a policy assertion type A in its policy, and this policy assertion type A does not occur in an intersected policy, then the initiating entity does not apply the behavior implied by assertion type A. If a policy assertion type Z is not included in the policies being intersected then the intersected policy says nothing about the behavior implied by the assertion type Z."

<whenry> +1 to P2

P3- "If an initiating entity includes a policy assertion type A in its policy, and this policy assertion type A does not occur in an intersected policy, then the initiating entity should not apply the behavior implied by assertion type A. If a policy assertion type Z is not included in the policies being intersected then the intersected policy says nothing about the behavior implied by the assertion type Z."

<fsasaki> paulc: example : I have always RM in my policy. So even if I get a intersection result that has not RM in it, I will try to do it

<fsasaki> TRutt: could not live with SHOULD NOT

<fsasaki> ashok: wants to have a stronger word than "does not", e.g. SHOULD NOT or MUST NOT

<fsasaki> paulc: ashok does not want the flexibility in the spec. dave wants the flexibility. Tom is between ashok and dave

paul ( to tom) why did you vote that way?

tom: can we do a vote between 3 & 4

p4 "If an entity includes a policy assertion type A in its policy, and this policy assertion type A does not occur in an intersected policy, then the initiating entity must not apply the behavior implied by assertion type A. If a policy assertion type Z is not included in the policies being intersected then the intersected policy says nothing about the behavior implied by the assertion type Z."

<whenry> Are there penalties for MUST NOT? What will happen? What's the point. Even if we have a MUST NOT people are open to try the great thing is it won't work.

paul -- preference poll for 2, 3, 4

preference 2 - 0

<whenry> What's 1,2,3 ?

<whenry> 1 does not? 2 should not? 3 Must not?

( p1, p2, p3, p4 above)

preference 3- 7 1/2 or 8

preference 4- 1

<whenry> I like 2 "does not" better - let the best practices handle the shoulds

paul- strong preference for 3 and no one "can't live" with 3, so this is consensus

monica: is "entity" sufficient?

chris- i need to think about it over break

dave: i like getting rid if initiating because it gets rid of a lot of issues

<cferris> from the "whiteboard": If an entity includes a policy assertion type A in its policy, and this policy assertion type A does not occur in an intersected policy, then that entity SHOULD NOT apply the behavior implied by assertion type A. If a policy assertion type Z is not included in the policies being intersected then the intersected policy says nothing about the behavior implied by the assertion type Z.

<cferris> note, this link in the log is to the proposal that we have reached consensus on, modulo any "editorial" tweaks

asir: we need to remember that this was only one part of the original proposal

<cferris> http://www.w3.org/2007/05/23-ws-policy-irc#T19-29-06

<break>

<cferris> http://maps.google.com/maps?daddr=17+Eleanor+Dr,+Nepean,+ON,+Canada&saddr=3500+Carling+Ave,+Nepean,+ON,+Canada&f=d&sll=45.364584,-75.727365&sspn=0.007448,0.014377&ie=UTF8&z=12&om=1

<asir> ACTION: Asir to close issues from David Hull [recorded in http://www.w3.org/2007/05/23-ws-policy-minutes.html#action03]

<trackbot> Created ACTION-301 - Close issues from David Hull [on Asir Vedamuthu - due 2007-05-30].

<asir> This includes 4552-4556

resuming after break

4558 - DaveO's issues with performance

daveO- summarizing issues with wildcarding & issues with security policy

daveO- some new things emerged in the morning session if you were looking at introducing wildcarding at the provider side

daveO- there is a challenge with regard to scalability and ease of authoring

ashok: i think david raised issues about the performance side, but this is a usefull semantic to express

abbie: wildcarding?

ashok: yes

tom: from ws-addressing perspective the performance issues are not there ( there's only 2) but it may be that not every assertion can use the wildcard feature and we need to think about this more, so it could be a v-next issue

<fsasaki> +1 for v.next

<prasad> +1 to next version. This is not a show stopper

tom: we need to have a way to express whether or not the wildcarding holds or not

asir: we need some experience with examples, its like an application saying it does anything
... if you are worried about malicious behavior, you can use throttles
... you can have a limit on the number of alternatives
... overloading the existing empty will break existing implementations

<CGI234> ping

<Zakim> CGI, you wanted to respond on breaking issue

davidO: in the current model i don't think wildcarding breaks implementations
... every spec does not assume wildcarding, they list all the options

davidO- seems to me this is a compatible change

asir: i gave an example, from security policy,

<asir> From the primer - In another example, WS-Security Policy defines a sp:HttpToken assertion to contain three possible nested elements, sp:HttpBasicAuthentication, sp:HttpDigestAuthentication and sp:RequireClientCertificate. When the HttpToken is used with an empty nested policy in a policy expression by a provider, it will indicate that none of the dependent behaviors namely authentication or client certificate is required. A non-anonymous client who require

daveO-poll.....should we try to fix this now?

daveO- is there anyone else who is interested in solving this now?

exploring solving?

daveO- yes

monica- if we can establish that it won't break existing implementations then we can explore it

tom- asir, it will break implmentations

<asir> Bottom of Section 2.9 - http://www.w3.org/TR/2007/WD-ws-policy-primer-20070330/#nested-policy-expressions

chris- ashok and dave are the only ones interested in exploring this?

daveO- if its incompatible i'm not sure i'm interested in a change

tom- if you did a new qname for wildcard

tom- this would be a global qname, so i don't see how it could be backward compatible

daveO- i believe the compatability is around assertions,

felix- it(compatability) is about implementations and assertions

<fsasaki> CR requirements are about (not) breaking existing implementations, adding a new qname would be against that

chris- so we're dong interop now, and lets say we can up with a compatible solution that doesn't break the 1.5 implementations, ..this is just an exploration.....of where we are

chris- we have roughly a month to cross t's dot i's in anticipation of transition to PR in June

<dorchard> the key is the phrase "is required".

<dorchard> a non-anonymous client who requires authentication would put their restriction in httpsToken, and then get the right intersection.

chris - we have to each review these changes, deal with any test cases unresolved after this interop....let's asume we get there.....that puts us into PR in July........that requires an AC review...for a month...current course....Sept for PR... if we entertain introducing a new feature...how long would it take to work out a resolution to this?

ashok- couple of weeks

chris- then we're looking at pushing back a month

chris- it pushes us back to last call

ashok- different question....if we start PR process in June..........what will we do in July?

chris- we have primer/ guidelines

<Zakim> dorchard, you wanted to mention when "customrs" would get wildcarding feature..

daveO- it will take us 2 years to get a v-next out and my concern is that a 2 month slip is a tradeoff to a 2 year slipbecause we add it with some other features

chris- i'm asking does that seem fair, to have a week or two to assess and then move on

daveO- i do think we need to have a proposal on the table

chris- i'm just looking to see if people expect to leave the spec open to do this, or if we are aware of the impact to the current track

asir: implementors have spent a lot of time and it would be hard to get implementors to do anything else

<TRutt__> I only want to change the CR namespace in the PR if there is a change necessary to fix a broken spec, the spec is not broken. The wildcard is an enhancement.

asir- its a myth to think it can be done in 2 months

tom- i don't want to partition the space, i hope we can do this without versioning the namespace

tom- its not broken the way it is

felix: it might also involve groups like the WS- addressing

ashok- if what's required is that we write a proposal, then i will write one next week

chris- the proposal needs to have a solid backing and an understanding of how we get where we want to go

ashok: you might need to retest the intersection algorithm

chris: felix, would adding a feature trigger going back?

felix: yes that should have been done before last call

chris- not going to close the door, lets think about it tonight and look at it again tomorrow

chris: if we have to go back to last call, we'd be adding at least 3 months
... we would need to have a plan by June 6

felix: from my experiences and giving people more time, can start a feature creep

abbie: we should assess right now whether there is interest

<cferris> RESOLUTION: issue 4558 closed with no action as v.next

4561

Description: can a domain define domain-specific processing that could state

that empty nested policy IS compatible with non-empty nested policy? If so,

then I believe the spec should indicate with a MAY.

<cferris> http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0253.html

<charltonb> +1 to MAY

asir: the intersection states that domains can only specify parameters intersection

monica: there is another sentence .....that says " Because the set of bheaviors indicated tby a policy alternative, depends on the domain specific semantics of the collected assertions, determining whether two policy alternatives are compatible generally involves domain-specific processing."
... i don't understand why we would say that they CAN NOT

<Zakim> dorchard, you wanted to dispute the assertion that it's hard to get implementors to do anything else and to ask why closed extensibility model on domain specific affecting

daveO: i don't understand why we have this closed domain processing limit on the domain specific processing
... i think we will do harm and prevent this item we just put off for v.next if we do this

asir: I was explaining what's in section 4.5
... to say that two assertions are compatilbe you have to match the qname and the only thing that is delegated is the assertion parameter processing
... you need to determine if each assertion is compatible, and the key statement is that the only thing that is not covered is parameter processing

<TRutt__> The spec should clarify that the use of domain specific intersection processing requires that it be specified with the assertion type definition, In the lack of any domain specifric processing for intersection in the definition of an assertion type, the default intersection processing applies. If the intersection processor has to have a escape table (based on qname) for assertion types wanting to pull parameters into the algorithm, it costs no more

tom: we need to clarify if they don't put domains specific rules, the framework algorithm apples

<prasad> It only says: "As a first approximation, an algorithm is defined herein that approximates compatibility in a domain-independent manner". That is it is only a first approximation?

tom: when you pull in domain specific processing you may as well pull in everything......parameters & empty
... and the text is ambiguous

felix: the spec says the alogrithm is only an approximation, and v.next may be totally independent
... so I don't think it breaks v.next

ashok: asir talks about qnames and parameters, but what the spec says before that unless you have domain specific processing, so number one is if you have domain processing, and you can specify whatever you wish, if you don't then you fall back to the approximation

dale: similar to ashok, you can't say categorically that empty can't be interpreted in a domain specific processing, then they can do that
... that's what the wording says to me
... if a domain specific algorithm is required......then you say that you don't use the approximation, right now it seem s open

chris ( chair hat off)

chris: reasonable people are coming to resonably different interpretations which indicates that there is clarification needed
... there is no processing model for intersection, there are some steps, there is some prose, and it doesn't say explicitly whether you do domian first or second or part of the framework processing
... i think with soap we came up with a clear processing model which said, you can do it anyway you want but the behaviior has to be as if .....

anyone on the phone?

chris: we need to clear this text up

asir: clarification is fine

<TRutt__> if any spec defines an assertion type with domain specific processing, the implementation of that spec has to have a way to "overide" the default processing for that assertion qname. This can be very costly. In fact, an intersection implementation could be designed with a limitation of only doing default processing, and it would work only with policy definitions which rely on the default intersection algorithm In fact, I would ask if there are any

asir: section 4.5 is policy intersection
... everything is based on qnames
... the spec says what is not part of policy intersection
... if a domain says its not based solely on qnames then its a different algorithm

chris: how is that different?

daveO: why on earth do we say the domain can say that something falls out of intersection, but not in intersection

daveO- asir, you are saying that if you go through intersection and the qname match says yes, and the domain goes through and says no .......

<TRutt__> The framework should be clarified that the "domain specific" intersection is limited to processing of elements within the assertion element for a qname (i.e., only pertains to its parameters and nested assertions

asir: it says that in the first statement of the intersection

<fsasaki> +1 to TRutt

tom: the text does not say that anything under a qname is what is considered domain processing

daveO; this is a performance concern....the way it works it kind of scales because once you match, then you can do a lot of other processing and you know exaclty which domain processing to kick off

daveO: in one case you prune the tree of things that don't match, you know you only have to go into 2 to see if there is any domain processing to override the behavior

monica: if you look at the last paragraph in 4.5 you can have more than one assertion of the same type.... lean toward davids argument to allow domains to specify compatilbility

<fsasaki> adjourned for today