WS-Policy F2F

Introduction / Administrivia

[agenda bashing]

Chris: Moving versioning discusison to Wednesday to accommodate DaveO. Giving Felix some time to present W3C positions on various issues this afternoon. This works great since we're moving the versioning discussion. We'll move Bijan issues (to Thurs) as well… Would be great when discussing issues if we could have Bugzilla updated in real time.

Ashok: You still have to send a separate email after updating Bugzilla… that's a pain

Chris: Yep, we're trying to fix that.

Felix: There is a separate mailing list which gets Bugzilla notifications - it's a pain to read all that on public-ws-policy.

[discussion of Bugzilla vs. email]

Review and approval of telcon minutes

Minutes approved.

RESOLUTION: minutes 9/6/2006 approved

Future WG meetings

No meeting next week.

Paul will chair on the 27th

[Discussion of meeting exceptions in the schedule]

LC schedule review

Proposed schedule to get to Last Call: Schedule for development of Last Call WDs

Chris: Trying to get closure on everything and approve LC drafts at the F2F in Nov. Need to tease out all the issues this week if at all possible.

Touf: Dave and I got some issues privately from UDDI TC…. Will submit them or get them submitted this week…

DaveO: People should really submit their own issues as per our process.

Paul: Yup, we should point people to Bugzilla if we receive communications like this.

Editorial team report

http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0017.html

<bijan> Last call?

Maryann: Two new issues from last phone call, two pending issues from F2F, other than that we're complete.

Approval of WDs

Chris: Could approve current drafts and ask W3C to publish, satisfying heartbeat requirements… any objections?

DaveO: We could pull in resolutions from this F2F in real-time, then publish right after…

Felix: Am away next week, so waiting a bit wouldn't be bad…

Paul: Would rather publish and then try to close issues with rest of F2F

Asir: Tagged all the files, so we can change things and use the tagged version for publishing.

[wg has no objection to publishing tagged versions plus status sections]

<Asir> http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.html?rev=1.31&content-type=text/html;%20charset=utf-8&only_with_tag=Approved-as-Second-Public-Working-Draft

<Asir> http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-attachment.html?rev=1.41&content-type=text/html;%20charset=utf-8&only_with_tag=Approved-as-Second-Public-Working-Draft

<Asir> http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.html?rev=1.31&content-type=text/html;%20charset=utf-8&only_with_tag=Approved-as-Second-Public-Working-Draft

<Asir> http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-attachment.html?rev=1.41&content-type=text/html;%20charset=utf-8&only_with_tag=Approved-as-Second-Public-Working-Draft

RESOLUTION: Publish current tagged versions (Approved-as-Second-Public-Working-Draft) as our new WDs.

Review Action Items

http://www.w3.org/2005/06/tracker/wspolicy/actions/open

<Asir> Tag = Approved-as-Second-Public-Working-Draft

ACTION-39 is PENDING, due 9/27

ACTION-48 is PENDING

ACTION-75 is DONE

ACTION-79 is DONE

ACTION-83 is DONE

ACTION-85 is DONE

ACTION-86 is DONE

ACTION-87 is DONE

ACTION-88 is DONE

ACTION: Chris to update the Scribe FAQ with note from Dean [recorded in http://www.w3.org/2006/09/12-ws-policy-irc]

<trackbot> Created ACTION-92 - Update the Scribe FAQ with note from Dean [on Christopher Ferris - due 2006-09-19].

ACTION-91 is DONE

Detailed Review of WS-Policy Framework

http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.html

Frederick: Raised issue 3703 this AM

<Frederick> http://www.w3.org/Bugs/Public/show_bug.cgi?id=3703

ACTION: Frederick to kick off email discussion on Issue 3703 [recorded in http://www.w3.org/2006/09/12-ws-policy-irc]

<trackbot> Created ACTION-93 - Kick off email discussion on Issue 3703 [on Frederick Hirsch - due 2006-09-19].

Glen: suggest pulling parens around "or capability" in sec 3.1

RESOLUTION: editors to remove parens as above

<Asir> Related editors action is http://www.w3.org/2005/06/tracker/wspolicyeds/actions/6

Paul: Is "root EII" an official technical term?

Jeff: root being used as adjective?

Paul: finds reference in infoset spec and it is being used as adjective… no change required

Vlad: is there special reason for strongly typed assertions?

Maryann: reason for strongly typed was for intersection… we would have to revisit intersection

Ashok: framework only uses qname… thinks that vlad is saying that isn't enough

Vlad: Do we really need "strongly typed" here?

Chris: should the policy engine validate against something like schema? Is that the question?

[discussion of "schema" vs. "XML Schema"]

Proposal is to remove "strongly" from "strongly typed"

RESOLUTION: Remove "strongly" from section 3.1 / para 2

<Asir> updated action 6 http://www.w3.org/2005/06/tracker/wspolicyeds/actions/6

DaveO: Looked into rewriting the third para of 3.1. Hasn't yet bubbled into the commons yet… Don't quite like the use of "domain" everywhere. Might be better to just talk about "assertions".

ACTION: Maryann to open an issue re: examining the use of "domain" in the spec [recorded in http://www.w3.org/2006/09/12-ws-policy-irc]

<trackbot> Created ACTION-94 - Examine the possibility of eliminating the word \"domain\" from the spec. [on Editors - due 2006-09-19].

Glen: we use domain in speciic usage in many places, and in others in generic manner… we don't want to change the specific terms

Glen: We use "domain" in some generic ways, which seem right (i.e. "assertions are domain-specific"). I gather the issue is about clarifying the more technical terms like "domain expression"…

DaveO: Issue is about generally examining the use of "domain".

ACTION: Editors to add a link to sec 4.2 from "policy expression nesting" [recorded in http://www.w3.org/2006/09/12-ws-policy-irc]

<trackbot> Created ACTION-95 - Add a link to sec 4.2 from \"policy expression nesting\" [on Editors - due 2006-09-19].

Paul: Should we make "nested policy expression" a defined term?

<Asir> Updated editorial action to include this - http://www.w3.org/2005/06/tracker/wspolicyeds/actions/6

<David> I'd like somebody to propose a definition for Policy Expression Nesting

Yakov: We could define policy nesting as an official part of the model in sec 3.

<David> How about a nested policy expression IS a policy expression that is contained within a policy assertion

<David> editors, how about that definition at the start of "policy assertion nesting"?

<Asir> with a minor change - how about - 'A nested policy expression is a policy expression that is a child element of a policy assertion element.'

<Asir> in section 4.3.2

<David> Asir, close… I'd replace child with descendent…

<Glen: para 3 and 4 of 3.1 we should be crisp about what we mean about nesting versus paramerization

<maryann> i entered the bug for "domain-specific" ….it is bug 3706

Paul: s/additional assertion content/policy assertion parameters/

Paul: can we be consistent and say "policy assertion parameters" instead of "additional assertion content" in para 5?

<David> How about the start of 4.3.2 is "Any Policy Assertion may contain a policy Expression. A nested policy expression is a policy expression that is a descendent element of a policy assertion.

<Asir> Updated our editorial action - http://www.w3.org/2005/06/tracker/wspolicyeds/actions/6

[summarizing what we decided in sec 3.1]

<monica> We should be careful using descendant, child, etc. There has been confusion in other groups about this (i.e. enclosed, immediately enclosed, child, etc). Need to be explicit.

<Fabian> we use child everywhere else and direct child where applicable

<monica> As long as we are consistent and understand what it means. Thanks, Fabian.

<Asir> Editorial action for section 3.2 is http://www.w3.org/2005/06/tracker/wspolicyeds/actions/7

Glen: Should be careful with first para of 3.2 - "and only those asserions" might imply too much. (it doesn't mean anything about stuff outside the vocabulary of the policy expression)

<Asir> monica, fabian and David - I like the word child (covered by children in the infoset document)

[discussion about "vocabulary of a policy alternative" vs. "policy vocabulary"]

Dan: We use "policy alternative vocabulary" later, in intersection

Frederick: We need a definition for "policy alternative vocabulary" specifically

<Asir> Updated editorial action = http://www.w3.org/2005/06/tracker/wspolicyeds/actions/7

ACTION: Glen to investigate usage of "policy alternative vocabulary" - should it exist separately, and does 4.4 justify it? [recorded in http://www.w3.org/2006/09/12-ws-policy-irc]

<trackbot> Created ACTION-96 - Investigate usage of \"policy alternative vocabulary\" - should it exist separately, and does 4.4 justify it? [on Glen Daniels - due 2006-09-19].

<Asir> Updated editorial action = http://www.w3.org/2005/06/tracker/wspolicyeds/actions/7

Asir generalizes the "(or capabilities)" parenthesis removal action

<Asir> New editorial action for 3.3 is http://www.w3.org/2005/06/tracker/wspolicyeds/actions/8

Yakov: We don't need "at the abstract level" at the beginning of sec 3.3, ie s/At the abstract level //

RESOLUTION: Remove "at the abstract level" in sec 3 since sec 3 is all about an abstract model by definition.

<Asir> Updated editorial action = http://www.w3.org/2005/06/tracker/wspolicyeds/actions/8

<Asir> new editorial action for 3.4 = http://www.w3.org/2005/06/tracker/wspolicyeds/actions/9

Chris: Sec 3.4 relates to the definition of an interaction issue

Yakov: Issue 3672 relates to this too.

ACTION: Chris to follow up on usage of "web services model" with respect to issue 3672. [recorded in http://www.w3.org/2006/09/12-ws-policy-irc]

<trackbot> Created ACTION-97 - Follow up on usage of \"web services model\" with respect to issue 3672. [on Christopher Ferris - due 2006-09-19].

Paul: We should be careful not to reinvent the WS-Architecture group…

Moving on to section 4 because 3672 might affect almost all of sec 3.4.

Jeff: you would be happy with s/Applied in the Web services model, // ?

Chris: yes

Paul: Text at the beginning of section should be reworded to let reader know what's upcoming in the subsections.

<Asir> Created an editorial action = http://www.w3.org/2005/06/tracker/wspolicyeds/actions/10

Vlad: Do we need a canonicalization algorithm for signing, etc?

Paul: Why wouldn't we just use C14N?

Glen: Intro (sec 1) is really hard to read peppered with the definitions like that… could it forward-ref?

ACTION: Glen to find/reopen or open a new issue re: clarifying section 1 and making definitions point to the sections where terms are normatively defined. [recorded in http://www.w3.org/2006/09/12-ws-policy-irc]

<trackbot> Created ACTION-98 - Find/reopen or open a new issue re: clarifying section 1 and making definitions point to the sections where terms are normatively defined. [on Glen Daniels - due 2006-09-19].

<maryann> the current reference to WSS may not be sufficient and we may need to reference XMLdsig

Glen: Please add reference to sec 4.3.2 to the end of paragraph which begins "If an assertion in the normal form…" in sec 4.1. i.e. s/policy alternative./policy alternative (see sec 4.3.2)./ (with link)

<Asir> updated editorial action = http://www.w3.org/2005/06/tracker/wspolicyeds/actions/11

[Discussion of generally capitalizing MAY/SHOULD/MUST]

<Asir> updated editorial action = http://www.w3.org/2005/06/tracker/wspolicyeds/actions/11

<Asir> RFC 2119 action is recorded at - http://www.w3.org/2005/06/tracker/wspolicyeds/actions/12

<David> For the record, I don't believe that capitalizing all 2119 compliant must/should/shall/may terms.

<David> … is required

<Frederick> added issue for Security Considerations section in Framework, issue 3708

Paul: Jeff, should it be "owner element" in brackets?

Jeff: possibly

Paul: owner element is just an infoset term. owner property should be owner element. Pick out the terminology of the infoset

<fsasaki> change is necessary in several subsections of 2

<prasad> See "owner element" in http://www.w3.org/TR/xml-infoset/#infoitem.attribute

<Asir> updated editorial action = http://www.w3.org/2005/06/tracker/wspolicyeds/actions/11

<fsasaki> now sec. 4.2

Chris:first half of 4.2. before the examples is fine

Paul: is #P1 correct?

<fsasaki> (agreement that this is correct)

<fsasaki> Asir on xml:ID versus wsu:ID

Ashok: are you talking about two different styles of ID?

Dan: it says "some ID", we don't specify the type

Tony: How do you get interoperability?. if I e.g. not support xml:ID?

Paul: so the choice should be implementation defined?

Ashok: to take wsu:ID out?

Tony: no, the other one. how do I determine that this is xml:ID "ID"?

Paul: open an issue on this

Tony: will do

<Asir> Related issue is 3560 - for the record

Asir: this is an extensibility point in the schema

Chris:section 4.3 now. nothing on this, next: 4.3.1

[discussion on the true / false value of wsp:Optional]

Ashok: 1,0, false are the lexical space

Paul: the value space is true or false

<Asir> [Definition:] The phrase actual value is used to refer to the member of the value space of the simple type definition associated with an attribute information item which corresponds to its ?normalized value?

Ashok: that's o.k. then

Paul: " 0 " would be normalized to normalized value "0", and the actual value will be "false". actual value should be "xml schema actual value"

Paul: if the actual value (see xmlschema part 1) is…

[discussion on "the expression of the assertion"]

Frederick: get rid of "the expression"

Paul: +1

<Asir> updated editorial action = http://www.w3.org/2005/06/tracker/wspolicyeds/actions/16

Chris: how about A policy assertion that contains a wsp:Optional [attribute information item] whose value is the actual value (see xml schema part 1) is true is equivalent to the following:

Paul: you need to make changes on "assertion" in several places, otherwise the context is strange. I would just say "assertion"

Frederick: this goes back to the introductory text , we don't have to do wordsmithing here

<maryann> i think we should also capture what dan said about the expression of optional as being part of a compact form authoring style

Chris:there is no term for "assertion", not for "policy assertion"

Paul: there is colloquial english in 4.3.1 reffering back to "policy assertion"

Chris:change "the assertation" to "that assertion". at sec. 4.3.1

<Asir> Updated editorial action = http://www.w3.org/2005/06/tracker/wspolicyeds/actions/16

<cferris> s/that is a syntactic shortcut for expressing policy alternatives with and without the assertion./that is a syntactic shortcut for expressing a pair of policy alternatives, one with and one without that assertion./

<Asir> See http://en.wikipedia.org/wiki/Syntactic_sugar

Maryann: replace "syntactic shortcut"

<maryann> so the addedum is to replace "syntactic shortcut" with compact authoring style

<fsasaki> now discussing the examples

Chris:term references in the prose are missed. do we have a general action item to have links for all terms?

David: do we want all occurences replaced?

<Asir> Updated editorial action = http://www.w3.org/2005/06/tracker/wspolicyeds/actions/16

Paul: you should do it everywhere, otherwise definitions are not clear

<fsasaki> Now 4.3.2

Frederick: definition of /Assertion/wsp:Policy says you "MUST include an empty <wsp:Policy/> Element Information Item in its [children] property;". later it says " If this is not done". It is a must, how can it not be done?

Chris:this means "the reason why this is like that: …"

Frederick: that should be made clear

Chris:assign this to the editors?

Frederick: another item

<fsasaki> Discussion on "descendant" in the definition of /Assertion/*/wsp:Policy

Frederick: change "descendants of an assertion" to "descendants of an assertion parameter", that would resolve my issue

Chris:we don't want that XPath expression with "descendant"

<Asir> a descendant is a child or a child of a child and so on; thus the descendant axis never contains attribute or namespace nodes

Frederick: the XPath is wrong, you need to say parameters to make it clear. I agree with Chris: have a note, get rid of the XPath terminology

Asir: "descendant" is incorrect here

Chris: my proposal to resolve this: This specification does not define processing for arbitrary wsp:Policy Element Information Items in any context other than as an Element Information Item in the [children] property of an Element Information Item that is in the [children] property of an element Information Item defined in section 4.1.

<Ashok> M-W says the spelling is descendant … variant descendent

Frederick: are parameters opaque to the policy processing model. that is the question

[issue, are parameters opaque to the processing model?]

ACTION: Frederick to create an issue on parameters opaqueness [recorded in http://www.w3.org/2006/09/12-ws-policy-irc]

<trackbot> Created ACTION-99 - Create an issue on parameters opaqueness [on Frederick Hirsch - due 2006-09-19].

<cferris> I think that the text I suggested above should be included as a note (not an editor's note)

<Asir> A nested policy expression is a policy expression that is a child element of a policy assertion.

<cferris> actually, it is an EII in the [children] property

<fsasaki> (Asirs note is text drafted from David)

Ashok: question: the nested policy can have other policy expressions in it, right? Should we say s.t. about it?

<David> Asir, is it actually s/child element/Element Information Item in the [children] property/?

<David> ah, thx chris.

<fsasaki> (discussion on policy assertion nesting)

<Frederick> opaqueness issue created: http://www.w3.org/Bugs/Public/show_bug.cgi?id=3710

[David leaves the room]

Chris:we have substitute text for the definition, were is an editorial action to incooporate that. now we have an issue if we want /Assertion/*/wsp:Policy as an XPath expression, and Frederick has created the issue

<Asir> Asir is not recording an editorial action already done by David for changing the def for nested policy expression

<Asir> Dave just committed the necessary change

Chris:on the word "compact": it is not defined. "compact policy expression" is not defined

Paul: change "compact nested policy expression" to "policy expression in compact form …"

Chris:an editorial change

<Asir> Proposal is s/For example, consider the following compact nested policy expression:/For example, consider the following policy expression in the compact form:/

Paul: a general issue: any time you can use a term, use it (and hyperlink it). Don't create new terms like above

<maryann> so, reword For example, consider the following compact nested policy expression:

<maryann> to be something like a policy with nested assertions expressed in a compact form

[agreement on maryanns proposal]

<Asir> here is what I got - Proposal is s/For example, consider the following compact nested policy expression:/For example, consider the following policy expression with nested policy expression in a compact form:/

Chris:"The normalized form of this policy" should be like "The normalized form of the example above"

<fsasaki> now sec. 4.3.3

<Asir> Editorial action re labelling examples - http://www.w3.org/2005/06/tracker/wspolicyeds/actions/18

<fsasaki> (discussion on role of operators)

Frederick: have a definition of the term "policy operator"?. All, ExactlyOne

Chris:proposal: sec. 4.3.3 needs an introduction which describes what it is about. we need an editorial AI for that

<Asir> Editorial action for introduction in section 4.3.3 is http://www.w3.org/2005/06/tracker/wspolicyeds/actions/19

<fsasaki> now 4.3.4

ACTION: Frederick to open an issue on rules in 4.3.3 [recorded in http://www.w3.org/2006/09/12-ws-policy-irc]

<trackbot> Created ACTION-100 - Open an issue on rules in 4.3.3 [on Frederick Hirsch - due 2006-09-19].

<fsasaki> (discussion on description of the use of wsp:PolicyReference)

Chris:a wsp:PolicyReference can be used in any place where you can use wsp:Policy

<Frederick> Issue (and proposal) for 4.3.3 rules: http://www.w3.org/Bugs/Public/show_bug.cgi?id=3711

Paul: so getting rid of everything before "…" in "/wsp:Policy/…/wsp:PolicyReference" is the issue?

Chris:yes

<fsasaki> now sec. 4.4

Paul: "a requester and a provider" is fine because of "For example," before?

Yakov: yes

<Asir> Toufic - please see http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-primer.html?content-type=text/html;charset=utf-8#compatible-policies

Dan: assertion authors can do domain independent intersection

Toufic: why is this part of the framework?

Dan: if it would not be, you would have to go to the domain specific elements

Yakov: we provide some capabilities. You can have multiple policies in the same domain. So you need a domain-independent means to combine them. this section provides some very valuable

Chris:Toufic, please create an issue on this

<Asir> Toufic mentioned that Section 4.4 is his favorite section

ACTION: Toufic to create an issue on sec. 4.4 [recorded in http://www.w3.org/2006/09/12-ws-policy-irc]

<trackbot> Created ACTION-101 - Create an issue on sec. 4.4 [on Toufic Boubez - due 2006-09-19].

Toufic: The main point of the Policy Intersection section is to compare two different policies (presumably requester and provider) and find an "intersection" i.e. a policy alternative that is acceptable to both. But as a provider, I don't care about the mechanism that the requester used, as long as they submit a request that is policy compliang

<Asir> I wanted to say that policy negotiation is one of the use cases for intersection

<Asir> Definetly … not the only use case

<Ashok> My proposal is that we remove policy intersection and normalization from the WS-Policy spec

<Asir> :-)

<toufic> And as a requester, I shouldn't care about the mechanism as long as I produce a request that is policy compliant

<Ashok> Then we add a spec that talks abt "How to Use Policy" which has these sections and has other sections on other ways to use Policy

<toufic> so the question is: why does the framework provide this section if it's not needed by requester or provider?

<vladB> Issue for 4.3.4: http://www.w3.org/Bugs/Public/show_bug.cgi?id=3712

<prasad> Back from break

Primer: Presentation from Maryann and Ümit

<cferris> http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0054.html

Maryann: earlier we gave an outline on the primer. Now we filled that wit text, see mail… the presentation describes the text, going through the TOC

[slide 2]

Maryann: the material could also be input to the spec, i.e. for some clarifications. target of the primer: assertion authors as primary authors, not requesters / providers. question: should people make comments to this document?

Paul: you had an AI to create a document. Now the WG has to decide what to do next

[slide 3]

[slide 4]

Ashok: there are various specs you can attach policies too. Why are you focusing on UDDI and WSDL?

Maryann: don't know the w3c process, if other use cases not in the spec are o.k… the WG has to decide what the scope of the primer will be

<PaulC> Charter text re primer:

[slide 5]

<PaulC> Author a primer that includes guidance on the use of policy expressions to facilitate Web services interoperability and guidelines for authoring policy assertions

<vladB> Issue for 4.3.4: http://www.w3.org/Bugs/Public/show_bug.cgi?id=3712

Maryann: three tasks as general guidelines: assertion definition, scoping, composition

[slide 6]

Maryann: need to explain usage of compact and normal form

[slide 7]

[slide 8]

Maryann: subitems for modeling assertions: single domain, new policy domain, nested assertion

Paul: don't advice people not to define their own assertions. Better say: look for existing assertions in your domain

<fsasaki> Ashok gives an example of problems in assertions for authorization

Yakov: there is an discussion in OASIS currently ongoing on this

Maryann: for such topics you need guidelines

Yavov: for specifing new domains

Ashok: assertions can have quite different rules

Maryann: that is why we need guidelines

Paul: how deep do you go into domains with a policy? That is very important to decide

<Paul: how deep into the domain do you go with policy?. e.g. security policy never describes anything explicit about the tokens. it depends on the domain how far you go

Maryann: we have to gather exising experience on these issues

Toufic: I made a distinction between "internal" and "external" (policies on the wire) policies in my company. we are still struggeling with that distinction. it would be good to know what policy says about that

[slide 17]

intend: "applying best practices for policy attachment"

[slide 8 (again)]

Maryann: primer could reflect changes in the normative text, i.e. explain why we did s.t.

[slide 12]

Maryann: about intersection, was important topic today

[slide 14]

Maryann: levels of abstraction in WSDL

[slide 15]

Maryann: lifecycle of assertions. Leveraged by David extensibility discussion

[slide 17 …]

Maryann: different attachment models, e.g. used by wsrm versus security. end of presentation

Chris:issue by the editors: do we have one primer? Two?. do we have an explanatory doc for the spec, and / or also guidelines for authors?. we need to resolve this: were should we go? One primer with different audiences. or two separate audiences? Do we make a REC-track document? Or WG note?

Monika: having one document for several audiences is difficult, e.g. with the basic definitions

Chris:what is needed more?

Frederick: we have the primer which is in good shape, but has a different purpose. we should keep primer as it is, the other topic is important as well

Ashok: the guidelines document talks about *one* way of using policy. I would like s.t. like "these are the ways of using policy"

Maryann: how would you split that between the documents?

Ashok: the attachment stuff should be taken out

Ashok: example audience: a computer science student. what should he start with?

Paul: not sure if we need one or two documents. charter says "we may do s.t. about using policy". we have to take existing feedback into account. The "understanding WS policy document" had a good feedback on MSM. Frederik maybe said "we have a good document already", which might mean: we should stick with this. esp. in terms of our resources

Yakov: the scope of the specification is difficult. use cases are complicated

Yakov: need additional ue cases. in the primer: I could think of having some use cases, e.g. browser > ws client

Ashok: 5 people will define new assertions, 100 people will use assertions

Paul: don't agree, see e.g. XML Schema. we need to have the infrastructure to allow people to define them. we should have documentation for people writing assertions.

Frederic: I said primer is useful, and we should keep it. but it is not everything. the current proposal is very different. you need a short higher level document (like the MS whitepaper) and a longer one

Jeff: we need to tell people how this will be used

Yakov: I still would prefer one document. we need to tackle several audiences

<Frederick> suggest primer with focus on technology + higher level "management paper": e.g. Assertion Author and Deployer Guidelines,which is most of the new material in Maryann's slides

Felix: do you have the time for two documents? With the current resources?

Frederick: we should keep the primer, and have the other document starting e.g. as an FAQ

Jeff: we will not fall out of the sky if we take some time to do this

<vladB> VladB: for one document, assertion authoring guidelines are important because of the large audience (comparing to policy framework implementers)

Chris:summary: there seems to be agreement that there is value on having guidelines

<Frederick> faq could be used as starting point before deciding on final document form (faq, merged or separate document)

Chris:esp. for people who are not participating in developing the spec. so there is value on both topics. primers in WG I have been in, were developed by people who are interested in explaining things to the "outside". example of XML Schema primer. "using policy" doc does that. the "guidelines for policy": such guidance is clearly needed. question: who could not life with different document?

Paul: who wants to do the work?. this means 10 % of your time

Jeff: a "chicken and egg" question

Frederick: is Maryann & Ümit's doc not enough?

Paul: some people asked for new material

Felix: who wants it on the TR track or as a WG note?

Paul: TR track means "the doc has to be maintained". WG note means "this was produced by the WG in 2006", that's it

Yakov: why not 2,4,5, documents?

Jeff: let's people do the work, and see what the WG means

<Yakov> Compromise prosal was to start from one document and to split it later into separate docs if needed

Frederick: would like to work on exisiting doc

Felix: when should the docs be ready? This year? Next year?

Chris:summary : concerns about resources and schedule. I think: it depends on the individuals who spend their time. I don't think that guidelines must be a REC. it could be a WG note

Paul: answer to Felix question: when do we need it?. we need the primer material ASAP. let people know what we are doing. "guidelines about policy assertions" are needed during CR. guidelines are not necessary, but helpful to leave CR

Chris:two documents. materials are developed independently. and we have to think about timing (e.g. guidelines ready during CR)

Paul: so have a WD primer soon out. and focus on the guidelines later. let's try to get the primer done, later on getting the guidelines done. as the primer WD is public, we will get feedback

Jeff: and the decision of REC track or not?

Paul: we have not decided yet. I would publish a WD and note in the status section "we have not decided yet". primer should be ready in about 1 month. that the WG can consider WD publication. we also support Maryann and Ümits work and see if we get work and review going

RESOLUTION: we have a primer (Understanding WS-Policy) and we will have Guidelines for Authors as separate docs, we should support the work that maryann and Ümit are doing and get a document going and review scheduled to get the material out for public review

s/Using/Understanding/

Paul: Maryann, is the document ready for WG review?

Maryann: not yet

ACTION: Maryann to prepare guidelines document - due to 2006-09-16 [recorded in http://www.w3.org/2006/09/13-ws-policy-minutes.html#action01]

<trackbot> Created ACTION-102 - prepare guidelines document [on Maryann Hondo - due 2006-09-13].

Chris:we also have to think about David's versioning material

ACTION: Editors to prepare an editor's draft of the primer (ETA - determined by editors) and send it to the WG [recorded in http://www.w3.org/2006/09/13-ws-policy-minutes.html#action02]

<trackbot> Created ACTION-103 - Prepare an editor\'s draft of the primer (ETA - determined by editors) and send it to the WG [on Editors - due 2006-09-20].

Frederick: I offer to help Maryann

Felix (W3C) positions on some issues

<fsasaki> See mail at http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0064.html

ashok: the usingAdressing says how you annotate wsdl. would like to put these on equal basis

<jeffm> From a practical perspective what is the difference between saying " xxx is out of scope" and "oh i'm sorry, xxx is really in scope, but the time alloted by the powers that wrote the charter don't allow us to address xxx.

paulc: my recommendation would be to take this to the director

felix: good hope that it will be resolved like that

paulc: chris and I should draft a note to Bob. if we go fast enough, we can solve their problem. the farther along the process… the more comfortable they will be with a reference

jeffm: see my comment in IRC above