See also: IRC log
<fhirsch3> scribe: fhirsch3
Asir, David Orchard, Maryann, Prasad, Toufic
Whitepaper introducing web services policy with examples, normative spec references, story to illustrate, recently updated
optional deliverable in the charter for a primer
Microsoft would like to contribute this material to the working group
submission of Understanding WS-Policy has been made to working group
Paul Cotton asks if material appropriate for Primer
Umit suggests need for Primer to help domain authors to write policy, so this gap would need to be addressed with new material
<scribe> ACTION:Maryann and Umit to produce primer proposal, an outline [recorded in http://www.w3.org/2006/07/12-ws-policy-minutes.html#action01]
Paul Cotton - should we convert Understanding whitepaper to spec format
Maryann - would make it easier to include Understanding whitepaper into spec format
<scribe> ACTION: Editors to convert Understanding WS-Policy whitepaper to spec format [recorded in http://www.w3.org/2006/07/12-ws-policy-minutes.html#action02]
may be air conditioned, has more than one room
starting after break at 10:50 CT
about 5 minutes
editors meeting today after recess
Domain policy assertion usage scenario, security policy
<cferris> slides: http://lists.w3.org/Archives/Public/public-ws-policy/2006Jul/0014.html
Work is in OASIS WS-SX TC
Security domain assertions, of different types
Security domain drove need for nested policy, change from eariler ws-policy specification
focus on wire format in WS-SecurityPolicy
not configuration or other parameters
Contents of token also out of scope, token contents are opaque to protocol
token assertions - types of tokens included, aspects of them
binding - symmetric, asymetric or transport
can use XPath to specify encryption or signature, also assertions for body and header
will sign body and addressing header
second example, sign within addressing header
Dan Roth - not SOAP specific if you can XPath anything
Umit - is question whether could secure body using XPath
Tony - could use to reference attachment
Ashok - can XPath functions be used?
Tony - not limited, not mandating XPath version
Tony - can specify which XPath version you are using
Default is XPath 1, hence not shown
Specific X509 token and inclusion rule
Second example, specifies specific token, SAML 1.1 token using 1.1 profile
Possible issue with default values of properties
potential mismatch of policy with explicit value matching default
potential solution is to always include default
Ashok - schema validation will put in default
Tony - not how schema was done
Entire Header and Body Signatures property
simple way to say for all bindings sign headers and body
Security Header layout to speed up processing
lax - order can vary, strict requires a specific order
Transport binding with nested assertion for transport token, then nested algorithm for 256 RSA etc
Also require timestamp
Ashok - transport assumes certain addresses,
if policy requires reliable messaging, how is this related to transport security requirement
Do different policy domains need to be related?
Tony - Review of reliable messaging led to changes to security policy, e.g. adding basic and digest auth
Transport binding is a collection of assertions
Ashok - cannot express reliable messaging policy concerns in security policy
Maryann - need to decompose into the two policy domains
Dan - algorithm suite, should have policy wrapper around sp:Basic256Rsa16
example RST, RSTR
multiple message exchange - in symmetric binding, refers to use of multiple message exchange
Kerberos token with Algorithm suite, for symmetric binding
Similar issue with Policy element needed around sp:Basic128Rsa15 element
Same issue on Policy element for algorithm element
Note that AlgorithmSuite applies to all of the tokens
if included in RecipientToken then would only have applied to that specific token
like cert chaining
example - e.g. want token verified by bank, so additional token could state bank's confirmation, for example
endorsing - a second signature over the message signature
Transport binding with HTTPS transport token
added supporting token, a username token, no signing implication
example might be a token exchange
<fsasaki> I wonder if the policy wrapper was missing again on slide 23 ..., see sp:AlgorithmSuite
some endpoints might not want to support signature confirmation, hence the assertion
outlines different ways of referencing keys and tokens
enables means to indicate what implementation supports
wss11, references and support for signature confirmation
allow challenge response, and use of entropy in key derivation mechanisms
ws-securitypolicy for wire format for wss, ws-trust, ws-secureconversation
One issue has been determining how detailed to specify contents of tokens
Paul Cotton - at first F2F in December, security experts needed time to understand
some issues generated in WS-SX will lead to issues in WS-Policy, based on understanding
Will have fairly large of domain specific groups that may need assistance from WS-Policy working group
May be issue given schedule of WS-Policy
Charter does include liaison element
For WS-SX, WS-Policy, both email lists are public, no anticipated issue
David Orchard - WS-SX may be dependent on revised WS-Policy, related to issue of backward compatibility with submission
Paul Cotton - general issue, WS-Policy working group will have to consider these issues
Umit - went through this in WS-Addressing
David Orchard - WS-Addressing charter was not so rigorous
Paul Cotton - haven't started interop on security policy in WS-SX, possible to process secureconversation and trust first
WS-SX charter clear on normative references
Decisions to be made by WS-SX TC
WS-SX F2F in October
David Orchard - generally
David Orchard - generally description gets spec'd later than message wire formats
Paul Cotton - SecurityPolicy was published much later than other WS-SX specs
Tony notes substantial number of people participating in both WS-SX and WS-Policy
Frederick noted that WS-SX review indicates need to understand how wire formats relate to policy statements, make sure we understand how policy leads to wire format
Frederick also noted that bindings might be of different nature for Transport and others
Frederick notes that proposal like Ashok's document gives examples that helps if people walk through it
Note this document was submitted to WS-SX, to outline different security needs and how expressed in SecurityPolicy
Frederick also noted that some issues submitted to WS-Policy came up reviewing WS-SX, eg. policy assertion vs parameter etc
Paul Cotton notes that interop scenario documents also meet need Ashok is noting
included message examples
Ashok - should we add message examples to WS-SX interop scenarios
Paul Cotton - topic for WS-SX
Slide 1 - title
questions on WS-Policy from developers and custommers
"Based on Developer experience..."
actual concerns from developers and customers
can put anything into ExactlyOne element
can get strange policies
in programming strong typing enables early error checking
proposal - operators only allow assertions from single domain
glen - what are you detecting
glen - why should framework care
not sure agrees should be typed operator
assertions can be written in different time, places, how to know that are in same domain
Ashok - security policy is clear for things like message protection
Frederick - generic policy processor may not know about domain specifics
Asir - do we need educational material to help policy authors?
Jeff - how would help
Asir - best practices
discussion of guidelines versus tools to enable correct implemetation
Philippe - useful to have tools to check correctness of policy
RDF mentioned as means to relate policy assertions
Ruchith - policy parser, sees qname, calls extension for that policy
David Orchard- question of binding time, late binding using callback model
Umit - proposal is not clear
for example, what about alternatives
<dorchard> q Plus to ask Ruchith about "syntax checking time" on extensions
could lead to partial matching problem - e.g. four qnames
<dorchard> can somebody q Plus me? the plus key doesn't work.
issue is that this might become an issue for alternatives
Yakov - agrees with proposal, sees value in restriction
suggests adding another requirement, for unique domain descriptions
requirement on domain creator
David - when checking, not sure of value of not checking at run time
<Zakim> GlenD, you wanted to request that we move on to the next highly controversial slide
Glen - opening issue here
Frederick - agree with Yakov, use of URI to identify domain, still allow generic processing
Umit - need to consider implicit Alls and implications
"embedded polices too general"
nested policy should be related to containing policy
not too general
Glen - domain specific assertions can modify framework semantics, e.g. intersection algorithm
need to define how this works semantics and structurally
example, instead of saying wsp:Policy to embedd sub-policies, alternative is that schema could allow that
<cferris> ack tonyq+ frederick
Frederick - would change recurse model
Glen - need to explore
Tony - framework needs to be estensible
general framework does not know domain, so do not want to limit domain in this case
example - in security policy nestings can go deep
hence closed-end policy would restrict domain specific assertion develoment
maybe allow assertion to specify whether nesting is allowed or not
Ashok - when authoring assertion, need to specify what may come into it
Tony - guidelines are in security policy regarding what is nestable
<scribe> ACTION: Glen to submit issue of domain specific assertions impacting framework, specifically intersection [recorded in http://www.w3.org/2006/07/12-ws-policy-minutes.html#action03]
Glen - need to be clear on why sub-policies needed, then clarify why other data might be needed
<uyalcina> it seems to me that these are two separate concerns
<uyalcina> Ashok appears to be concerned about the toolability and validity checking of nested domains
<cferris> ACTION: Ashok to draft new issue regarding merits of nested policy [recorded in http://www.w3.org/2006/07/12-ws-policy-minutes.html#action04]
"what policy does a message follow"
are all policy assertions reflected in message content?
Group answers No
In web services any message has to be interpreted in context
Glen: previous statement
Glen - three operations for service, must call in order, no policy, but know out of band
Glen - context includes fact earlier message was or not sent
Umit - what is the issue
Ashok - cannot tell from message the policy
Umit - do not want this to be the case, may be for the endpoint
Umit - certain things may not be expressed in message, but such policies could be used
Already allow policies that are not expressed on wire
Umit - question, suggesting change to spec, or best practice? Proposal may not apply in all cases.
Ashok - later slides also talk about this approach and other benefits
Dave Orchard - sees motivation, how to determine whether message is self-describing, but haven't done this in past, no WSDL information or pointer in SOAP message
Dave Orchard - map content of messae with description later
could make more fragile messages, especially with regards to versioning
Toufic - similar points to Dave, WSDL great example. Why does this matter? You get message, could point to wrong policy, but decide on acceptance based on own policy
Raises issues related to state, functionality not needed for messaging. Want to keep it simple. Receiver decides based on policy enforcement mechanism
Jeff - Allow messages to point to policy, not require
Jeff - Moving complexity, not removing
Toufic - why introduce this if not needed
Jeff - Implicit material can make interop harder
<uyalcina> the problem is to determine when it is needed to include the pointer.
<dorchard> my response will be that adding in the policy is effectively a duplicate information item and may lead to tighter coupling
Maryann - Current framework would allow this to be used as extension point
<dorchard> in the policy is effectively a duplicate information item and may lead to tighter coupling
<dorchard> 1. how will "the policy" be pointed "to" under equivalence; 2.
Yakov - out of scope of specification, since it relates to policy enforcement
Ashok - will talk about other cases where this is useful
Paul Cotton - echo what David and Toufic said, another example against this is WS-I BP profile
If you can attach to WSDL, no need to add to every message
Ashok - difference, can take WSDL and message and determine conformance, with policy cannot since policy does not have material reflected in message
and test assertions etc)
David Orchard - "to point to the policy adhered to" - issue
what if multple policies that a message could match? Do you list all?
second issue: because policy will guide message content, have duplicate information, potential for error
<cferris> frederick: receiver has his own policy, that is all that matters
<cferris> jeff: it is senders problem if the receiver doesn't understand
Frederick - receiver policy is what receiver has to enforce, intersection with sender policy not essential, can be useful for debugging
Jeff points out that sender sharing their assumptions can make message clearer to receiver, intent.
Chris Ferris - can say endpoint conforms to WS-I profile, the WSDL itself
question about putting conformance claim in message, to say conformant message
concern about two paths to determine conformance
optional - absence does not mean not conformant. Similar issue for policy, optionality.
Policy anchor in message does not make a definitive statement
if this drives processing, then what happens if policy is not in message, different processing?
endpoint receiver can make requirements on message received, can process those
endpoint policy states capabilities of receiver
some material may not be communicated, so putting information in might not help
clarification - not everything may be captured in sender policy statement
"Allow messages to refer to policy expressions"
Break for lunch, resume in 1 hour, 1:35
ashok continues -- slide # 7 -- Allow messages to refer to policy expressions
daveo: wants to clarify isn't this about finding out about policy chgs - doesn't this get us down the pol-negotiation path
ashok - pol neg happens before conversation starts -- this is what when things chg during the conversation
daveo- seems to be the same thing to me
<cferris> SCRIBE: jeffm
slide 9 - Allow msgs to refer to policy expressions
paulc: can't u attach to wsdl
ashok: no, wsdl stays the same
maryann: couldn't this be achieved by putting policy in a hdr -- isn't this "not precluded" -- should we write it up in "advisory material"
asir: effective policies depends on the intersection of the policy subjects
ashok: assumption is policies do not chg during the conversaton
yakov: clarify -- not that amzn msgs are insecure - but that diff msgs in seq can have diff policies -- e.g. the final buy/submit msg has higher security requireemnts
jeffm: asks if ashok is describing a "static case",
<scribe> ACTION: ashok provide a more detailed example of slide 8, including msgs types, wsdl, etc. [recorded in http://www.w3.org/2006/07/12-ws-policy-minutes.html#action05]
ashok: said no - its the dynamic case
<Zakim> daveO, you wanted to ask about is it same message type that changes?
daveo: are we considering the "same" type of msgs?
slide 9 - Matching Policy Assertions
<Zakim> asir, you wanted to ask a question
paulc: notes that we already have issues for this about to be filed
<pbc1> don't the QNames define the semantics and clients and severs need to know the meaning of the QNames
ashok: how policy assertions are matched depend upon the particular assertion
asir: asks doesn't the policy assertion writer define the semantics
paulc: the soap body has a qname for the msg, if the client don't have the same meaning for body the same problem exists?
glen: soap processing model uses MustUnderstand -- to enforce that it is important to understand a header
paulc: how is this diff from both sides not having the same understanding
slide 10 - Matching Policy Assertions
frederick: talkd about this in ws-sx -- conclusion i came to is that if u go to the trouble to state something more specific, then u really care, and then u don't want to match the less specific
chris: related issue - if u have a null policy, according to the current rules, if qname matchs and it has msg policy that matchs then ....
<fhirsch3> there is issue on list for empty nested policy not matching no nested policy assertion
chris: thinks the null policy should match the bottom one on the slide, but it doesn't accroding to the current
... seems like this has to be domain specific
maryann: thinks there is txt in spec that says domain has to explain the rules
ashok: didn't see that
maryann: we may need to clean up the text
<pbc1> who is cgi-irc?
<dorchard> If you look up 6 lines, I said I was
<pbc1> Sorry DavidO - trying to watch for hands and the queue.
paulc: if we are debating actual text, then lets remember when we start exmaining the text
<scribe> ACTION: ashok investigate text to see if what it says about domains defining rules [recorded in http://www.w3.org/2006/07/12-ws-policy-minutes.html#action06]
tony: dangerous to classify the 2 egs. on the slide as being same, because you don't know the scope
<umit> There are two aspects of matching, assertions with parameters and assertions with nesting
<fhirsch3> also assertions with nested assertions
<umit> Matching guidelines for assertion developers for these two categories should be consistent.
the chair gets called for queue jumping - the crowd cheers :-)
<pbc1> the chair apologizes
<Zakim> cgi-irc, you wanted to echo that isn't up to the equivalence rules for extensions, and there's no other way to do it.
daveo: doesn't see how the policy framework can deal with these matching (equals) semantics --
... must be domain specific
ashok: what about where there is an empty policy embedded?
<umit> +1 to DaveO that empty policy matching is a separate problem
daveo: really 2 diff probs
<dorchard> problem one, shown on board, is how to say that certain values are equivalent to empty
frederick: need to make it clearer that domain specs ahve to be explicit about how matching works for their domain
<dorchard> problem two: empty versus null policy and equivalence of them
frederick: what do we do when domain specs don't specify the needed semantics
... authors should define how policy matching works for nexted policies
<fhirsch3> clarification: need to deal with case where domain spec does not define intersection - they won't always do so
tony: purpose was to have framework do the matching -- doesn't want to push it "down" to the domains
<fhirsch3> clarification - assertion having nested assertion may have attribute specifying strict or lax , lax allows match to without nested policy otherwise not etc
ashok: but assertions are domain specific
tony: but the matching should be done with just the framework
<umit> nesting vs, parameters strike again.
maryann: may need to clarify differences between nesting and parameter processing
slide 11 - Policy Versioning
paulc: asks if this is out of scope --lifecycle and mgmt
umit: you want something more specific than just versions, you want some specific semantics start/expire time
<umit> The last bullet is inconsistent with the requirement of having a version number. You probably want to refer to specific versions of the policy and QName may not be adequate for that.
frederick: why couldn't a domain policy doc define uri's and refer to them
... you are concerned with limiting validity by time
<fhirsch3> clarification: domain policy doc could use PolicyReference to refer to policy by URI. Corporation could define these URIs, store, and use PolicyReferences in its policy definitions
<fhirsch3> Issue appears to be around time vailidity of policy. Note clock skew etc issues.
daveo: notion of having "effective dating" of policies is obvsiou
... what happens those times change -- e.g. the project slips -- how do you go back and fix things up
<umit> I observe that Ashok did not ask about compatibility, only a versioning attribute.
daveo: doing compatibility processing (forwards and backwards) are difficult
... we should do enough to make sure we don't preclude versioning
... otherwise when we get to version 2, it will be too late
... maybe we should add versioning practices to primer/guide
<scribe> ACTION: daveo look at adding/developing versioning policy material to primer/guide [recorded in http://www.w3.org/2006/07/12-ws-policy-minutes.html#action07]
umit: what are we agreeing to do here?
daveo: these are some of things that could be done using the framework to facilitate versioning
... and provide examples of certain scenarios with an explanation of how to implement them
... commits to delivering in 2 weeks !!!
maryann: versioning and compatibility are not the same thing
... ashok did u look at how to "profile" using exsiting mechanism
<dorchard> scribe: I think Maryann asked whether they are the same
sorry NOT the smae
asir: lifecyle is an interesting problem -- should be attacked at a more general level, e.g. there is policy, wsdl, etc.
chris: wants to reiterate point -- if you don't deal with versioning at the beginning, you have no hope in the
... slapping a version attribute on is not the answer
... encourage the kind of thinking that daveo has done in wsdl/schema NOW
umit: is ashok looking for backwards/forwards compatibility rules, or just a simple version number?
ashok: wanted to raise this as a problem
jeffm: it is essential to define the version relation: x is a version of y iff <fill in the def>
jeffm: is it compatibility, same sematnics, additional semantics, etc.
<Zakim> dorchard, you wanted to respond to maryann about versioning and compatibility
daveo: for specific languages - what does compatibility mean?
... define foward/backwards compatibility -- syntactic structures, etc.
daveo: in ws-policy it is a bit more difficult because the language is used to describe other "things", e.g. you make a "compatible chg in the policy language sense" but it means that the "new messages" are no longer compatibile
dan: define specific versioning scenarios to concentrate on
<asir> Henry Thompson once said, 'Versioning is a scandal in Computer Science"
paulc: this is a known hard problem with several ph.d theses lurking within -- given the time schedule of the WG doesn't think we an attack the problem in its generality
ashok: i'm looking for at some more constrained scenarios
paulc: thanks ashok
... on behalf of the WG
... after the break, we will going to start going through the doc -- put it up on the screen and step through it
... identify as many issues as possible
... but not deep dive
... raise issues often and early
breaking now - return at 3:20 CDT
back from break
<umit> angel is called Isaac Newton
<cferris> tick tock
paulc: classify issues as to whether they need to be fixed before WD is published
charter say we need to publish in July
paulc: i will have a high bar
chris: put a ed note in doc is a possibility
paulc: 3 courses of ACTION: raise issue, raise issue and insert health warning, raise the issue and fix it
plh: namespace uri's are replace automatically by pub team
paulc: w3c wgs have to demonstrate "progress" every 3 mos -- usual way is to publish a WG
jeffm: reminds wg that pub of 1st WD triggers ipr process
paulc: triggers a Call for Exclusions
<cferris> felix references his note regarding parallel exclusion periods as noted in http://lists.w3.org/Archives/Public/public-ws-policy/2006Jul/0010.html
paulc: first Call for Exclusions is 150 days, there will be another Call for Exclusions when Last Call draft is
published with a 90 day period
... there are some details if the 2 periods overlap
<cferris> paulc membership system takes care of the relevant notifications
toufic: does doc use the word client?
paulc: uses requesters and providers
toufic: is it accurate to say "of a Web Service" in 1st para
<scribe> ACTION: Toufic propose change to Abstract [recorded in http://www.w3.org/2006/07/12-ws-policy-minutes.html#action08]
<bijan> Are we wordsmithing or just higher level issues?
plh: notes divided references to normative and other
<cferris> we are not wordsmithing, just identifying areas of concern, confusion or in need of change, etc.
<cferris> they may be technical or editorial
<bijan> Ok, thanks
plh: also upgraded the normative refs to be more recent versions
<cferris> the point is to raise issues early rather than allow things to fester unbeknownst to others (and the public)
chris: should raise issue about use of IRIs
<scribe> ACTION: felix add issue to ref RFC 3987 [recorded in http://www.w3.org/2006/07/12-ws-policy-minutes.html#action09]
frederick: what about ref to WSS 1
<fsasaki> action from yesterday on xml:id at http://www.w3.org/2006/07/11-ws-policy-minutes.html#action07
<scribe> ACTION: umit raise issue in sec 2.4 to consider usage of xml:id as a possible attribute of idness characteristic and would require a normative reference [recorded in http://www.w3.org/2006/07/12-ws-policy-minutes.html#action10]
<fhirsch3> note, wss 1.0 referenced due to need to reference wsu utility schema, no need for wss 1.1 in this doc
<cferris> note action 10 today is a dulicate of action 7 from yesterday
back to TOC
plh: Acknowledgements section is autogenerated, so don't worry if it is not correct
<scribe> ACTION: editors make sure all refs go through A.1 and A.2 [recorded in http://www.w3.org/2006/07/12-ws-policy-minutes.html#action11]
bijan: wonders whether there is a diff between the "grammar" and the "language"
... is WS Policy in 1st sentence a generic term,
glen: ans is yes it includes all the docs
<bijan> I notice that "grammar" is used in the second paragraph too
PROPOSAL: replace "grammar" with "language" in first sentence
<bijan> (and the last sentence of the second paragraph
<scribe> ACTION: editors make this change [recorded in http://www.w3.org/2006/07/12-ws-policy-minutes.html#action12]
<umit> RESOLUTION: Accepted proposal to replace
<Zakim> cferris, you wanted to note that we shouldn't be wordsmithing now
<ysverdlov> Poposed to provide web service definition in the context of this document o reliminate "XML" from "XML Web based service
chris: thought we were not goint to be doing wordsmithing, we seem to be falling into doing that
<scribe> ACTION: yakov consider wording of last sentence - "XML Web services-based system" [recorded in http://www.w3.org/2006/07/12-ws-policy-minutes.html#action13]
daveo: ok with removing XML, use the def of WS in the WS Arch WG Note if we want to put in the def
maryann: notes that Web Services Policy phrase came from a time when there more docs as part of the "package"
william: still confused about use of Web Services Policy in 1st sentence and WS Pol 1.5
<scribe> ACTION: william propose change to clarify the meaning of Web Services Policy in 1st sentence [recorded in http://www.w3.org/2006/07/12-ws-policy-minutes.html#action14]
<GlenD> What about simply using <b>old or <i>talics when referring to the documents?
plh: attempts to clarify the results of sprinkling pixie dust on the submission
glen: nice to see 1st usage of term highlighted and in glossary if needed
<scribe> ACTION: editors as early as possible in the doc, use the definition that are defined in the doc -- note - some people are concerned about being overzealous between use as common english and as technical term [recorded in http://www.w3.org/2006/07/12-ws-policy-minutes.html#action15]
ashok: observes the last sentence makes a "promise" that can't be fulfilled by the WG
PROPOSAL: Delete last sentence -- "Subsequent specs .... other common Web Service technologies"
RESOLUTION: proposal accepted unan
<scribe> ACTION: editors - remove the last sentence para 3 in Intro [recorded in http://www.w3.org/2006/07/12-ws-policy-minutes.html#action16]
<umit> +1 to Chris
chris: thinks Example 1-1 should have more operators in it - at least the ALL op, may want to add a policy ref
glen: the use of "A valid" interpretation implies there are other valid interpretations which is not true
<bijan> Kill it! Kill it!
paulc: wonders if it is appropriate to put the example in the Intro, rather than in the body of the doc
glen: agrees with chris should be a more comprehensive eg
<dorchard> bijan, we will have a primer based upon msft's submission.
<bijan> Then I think we shouldn't have primer like material in the spec
we did not yet decide what the primer will be based on -- maryann has an action to produce an outline
bijan: thinks we should kill the exmaple, and not have primer like material in the main spec
the crowd roars NOOOOOOOOOOOOOOOOOOO!!!!!!!!!!!!!!
off with his head
<dorchard> I can live with killing the example in the intro, but not in the rest of the doc
asir: notes the example was in a sep section
daveo: would be ok with no ex until section 4
<bijan> What does this example illustrate?
RESOLUTION: move the example to a better place - unan
<scribe> ACTION: editors find a better place for the example [recorded in http://www.w3.org/2006/07/12-ws-policy-minutes.html#action17]
<scribe> ACTION: editors to also consider the style of example, maybe simpler to more complex. Also editors to consider making it more comprehensive, at least adding back in ALL [recorded in http://www.w3.org/2006/07/12-ws-policy-minutes.html#action18]
dale: observes "this specification" does not actually define domain-specific policy assertions
<umit> I propose to replace "contains" with "is used to define"
<scribe> ACTION: dale to raise issue to clarify the above language [recorded in http://www.w3.org/2006/07/12-ws-policy-minutes.html#action19]
frederick: why are we using infoset
daveo: happy we are using infoset so that we dont invent yet another component model
<asir> +1 to DaveO
2.1 Notational Conventions
chris: add ellipses convention to 2.1
<dorchard> Ack Glen's point, that there are relationships that can't be expressed in infoset that must be expressed in some kind of model, be that an english or formal notation
<scribe> ACTION: editors add ellipses convention to 2.1 [recorded in http://www.w3.org/2006/07/12-ws-policy-minutes.html#action20]
paulc: raises question about where is the xml schema and what should really take precedence
plh: no recommended practice
... if the schema is not in the doc, or linked to it, it won't be normative
<plh> s/,or linked to it,//
umit: raises question about definition of "processor"
<fhirsch3> last sentence in 2.2 relates to issue raised regarding need to wrap assertions in wsp:Policy to distinguish from parameter elements
<dorchard> I'd like to see some suggested wording for that
<fhirsch3> Link to issue: http://lists.w3.org/Archives/Public/public-ws-policy/2006Jul/0022.html
<bijan> I would prefer a clear semantics to talking about a "processor", or rather, talking loosely about a "processor"
<bijan> (Just adding it to the record)
<scribe> ACTION: chris to open issue on undefined nature of processor sentences [recorded in http://www.w3.org/2006/07/12-ws-policy-minutes.html#action21]
<bijan> I'll note that 2.2 is the *only* place that "processor" is mentioned in the document
<bijan> There is a fair bit of use of "processing"
chris: we should include a namespace versioning policy -- should be refactored into section for the namespaces actually defined here (and how to version) and sep section for referenced namespaces
<umit> I noticed that the document does not have a conformance section. Don't we need one?
<scribe> ACTION: chris to respond to paul's namespace proposal with propsal on how to do versioning [recorded in http://www.w3.org/2006/07/12-ws-policy-minutes.html#action22]
<cferris> ACTION: Chris and D. Orchard to draft issue for refactoring XML Namespaces section [recorded in http://www.w3.org/2006/07/12-ws-policy-minutes.html#action23]
<Zakim> dorchard, you wanted to ask about "future" namespaces
RESOLUTION: accept all of proposal http://lists.w3.org/Archives/Public/public-ws-policy/2006Jul/0008.html except namespace document which is an action for chris to propose - UNAN
<dorchard> All future information items defined by policy will be identified by this namespace or a namespace of the form http://www.w3.org/@@@@/@@/policy/
daveo: wants to start our process for dealing with future versions
... wehn this spec becomes a REC the policy ns uri will be fixed - we should describe constraints on what future ns uri's will look like
<Zakim> bijan, you wanted to ask a question about 2.4
<umit> ACTION: Umit to raise an issue about the necessity of a conformance section [recorded in http://www.w3.org/2006/07/12-ws-policy-minutes.html#action24]
we will restart at 9:00 AM CDT