See also: IRC log
paul: update on primer
... agreed to 2 documents
... this is important because one or more of your items may need to be targetted to one or more of the documents
david: there is a missing step to publishing the primer
paul: the assumption is that the editors will convert the understanding paper into the prime
paul: do it on reqtrac with the
flexibility of publishing later
... modified the agenda, the first item this morning is item 13
paul: bugs 3617, 3590, 3662
... digression- who has bugs outstanding
glen has one
toufic has 2
paul: we currently have 30 bugs
daveorchard: is success measured
by moving the number up or down?
... tie in the versioning info for the primer
asir: item 12 on the agenda
daveorchard: we need to discuss this
paul: action #28 is being moved to be part of the dicussion of item c under agenda topic 13
<asir> Most recent e-mail on 3617 is http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0045.html
<Fabian> got it
paul: looking at bug 3617 and
... asir, can you summarize umit's proposal
asir: namespaces in policy
... 3rd bullet in section 2.3
<PaulC> Modifications to the pattern facet of a type definition for which the value-space of the previous definition remains valid or for which the value-space of the preponderance of instance would remain valid.
paul: the material after the or is the same as the information before the or
asir: doesn't hurt to change the
... formulated a concrete proposal
dave: the proposal for the 3rd bullet, would have expected you keep the other part
asir: read the 3rd bullet as dealing only with pattern facet
jeff: it doesn't say that though
paul: the second clause doesn't relate to the pattern facet,
dave: there are many topics here
jeff: what does preponderance
... i've only seen it used in a legal context
... the majority of the instance ?
fred: clear definitions might be put in the primer
dave: there might be a case where
some cases might not be valid as we go forward
... backward compatible not by type but by usage instances
jeff: so someone is considering a change, what's the test to see if it meets this criteria?
dave: you go to the working group and it comes up with its own hueristic
fred: why preponderance?
paul: to announce that the working group will make this decision
jeff: if we didn't have this verbiage, if we made any changes we'd have to have a new namespace
pau: we have a difference of opinion
paul: david has one interpretation,
dave: reconsidered, and i agree
... this bullet has raised a good point and i don't want this point closed off
... move the preponderance of instances to apply more broadly
paul: look at text before the
... this is just examples not all cases
... what do you want to do to bullet 3?
dave: trying to figure out what umit was referring to, i prefer to keep the status quo
paul: why isn't it a repetition?
dave: its talking about a pattern facet changing, and that some of these are not valid
paul: leave the text and explain
to umit, the first part has no impact, all the old cases remain
... the second part says if we change the pattern facet does not impact the majority of cases, the working group can agree to not change the namespace
... its common for the working group to lock down the namespace in CR
jeff: preponderance means 50%
... vast majority is different than preponderance
fred: i don't understand
... what are we saying? its majority vote?
paul: its always consensus
... we're leaving it subjective
jeff: there's still an issue, if i have an early implementation, what does my implementation do with this thing it doesn't expect
paul: summarize..... we change "preponderance" to "vast majority, no change to bullet 1 and make the change to bullet 3
fred: what's the 4th bullet?
david: you can change value by changing min occurs or extending max occurs
ashok: its peoples inability to parse the sentence
<dorchard> technology is hard. c'est la vie.
<PaulC> Re bullet 1: No change is necessary
<asir> Related editorial action is http://www.w3.org/2005/06/tracker/wspolicyeds/actions/23
<PaulC> Re bullet 2: change "preponderence" to "vast majority"
<PaulC> Re bullet 3: s/cardinality of elements/cardinality of elements (i.e.
<PaulC> modifications to minOccurs or maxOccurs attribute value of an element
paul: we need someone to update the bug with this decision
asir: combine 3590 and 3662
paul: why do we have 2 bugs?
dave: because you told me to
paul: can we mark 3590 as a dup?
dave: 3590 the key thing is to have an element extensiblity point for reference
<dorchard> 4. The PolicyReference Element is modified to add an element extensibility
<dorchard> point. This should be for any namespace, which means a slight change to the
<dorchard> notation section. This includes specifying that unknown element child content
<dorchard> is ignored.
dave: propose for any namespace, asir prefers other
<PaulC> Point 4 in 3590:
<PaulC> 4. The PolicyReference Element is modified to add an element extensibility point. This should be for any namespace, which means a slight change to the notation section. This includes specifying that unknown element child content is ignored.
dave: add element extensibility
and close the issue
... then we can decide in 3662 which one
RESOLUTION: for 3590
<asir> Related editorial action is http://www.w3.org/2005/06/tracker/wspolicyeds/actions/23
RESOLUTION: for 3590 is adopting the first sentence in point 4 - The policy reference element is modified to add an element extensibility point
<dorchard> #4 is agreed to by WG, but element extensibility of ##other vs ##any is decided in 3662
RESOLUTION: for 3617 - make changes to bullet 1,2 3 as indicated above and anchored by http://www.w3.org/@
paul: how many people think it
should be ##any, ##other,no opinion
... ##any ? - 6
... ##other? 2
RESOLUTION: 3662 is ##any
<asir> related editorial action is http://www.w3.org/2005/06/tracker/wspolicyeds/actions/25
<PaulC> Re 3662 no one could not live with ##any
paul: this proposal is changes for primer
dave: guidelines vs primer
paul: primer is aimed at people to understand the framework and the guidelines are for policy authors where does this belong?
dave: this is a little
... the primer is for people who don't understand the spec
... and guidelines is for people who are writing assertions
... there is a secition in what is now the "primer" that talks about versioning
paul: so will you update the section?
asir: this is extending the language
<asir> CVS version of the primer is http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-primer.html?content-type=text/html;charset=utf-8
paul: what's wrong with
targetting this at the primer?
... and then seeing what if anything should move to the guidelines?
paul: is your material to supplement or replace section 3.7
dave: there's also 4.4.7
... this would be a new 4.4.8
asir: 2 questions- as a user of
the framework how do i extend the framework
... how can 3rd parties extend
... what is the working group strategy for v.next
... separate the content to determine if this goes into the nornative document
dave: the problem is that....i
gave a number of scenarios, it gives suggestions, but that's
... there's a couple of best practices
... the material in here is not normative, and not worth being promoted
... its more examples
asir: i will point out..... " we can imagine a future version"
paul: is there any material that belongs in the framework doc in a non-normative annex
vlad: need to consider assertion version in the guidelines
RESOLUTION: accept this for text to the primer
<asir> related editorial action is http://www.w3.org/2005/06/tracker/wspolicyeds/actions/26
RESOLUTION: fixed with the working group draft -- one of the editors to update bug
<PaulC> proposal in http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0027.html
<Fabian> yes, can see
paul: does this address 2.0
... if we adopt this there may be an issue
dave: the value facet might change
paul: for what data type?
dave: you might find an issue about conformance....with the preponderance
paul: we would have changed the
schema without changing the namespace
... if there were complaints we wouldn't do that
monica: i sent a note to umit, do
we want more detail with respect to conformance
... there is work in
... OASIS on conformance
... asking if we want more detail
paul: this is the same level as wsdl
monica: yes, but do we want more detail
paul: well here's a proposal to
put it it
... there would be a way by putting more MUSTS in the spec
monica: if you look at the reference above, you can see the difference between basic and advanced functionality
paul: exit criteria for CR will tease this out
monica: we just might want to address some advanced functionality
<asir> related editorial action is http://www.w3.org/2005/06/tracker/wspolicyeds/actions/27
RESOLUTION: 3559 with the text in http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0027.html
http://www.w3.org/2005/06/tracker/wspolicy/actions/48 will be an action for the next meeting
paul: startup again
... glen opened bug 3720 --- terms should be defined....
<asir> related editorial action is http://www.w3.org/2005/06/tracker/wspolicyeds/actions/28
paul: there is a new bug
... not sure how to deal with this yet
a) Using UsingAddressing Extension Element as a WS-Policy assertion, PLH
asir: in the addressing
specification there is a "UsingAddressing" element
... which can be used as a wsdl element or a policy element
... question from phillipe on whether the current doc should have the "generic" text replaced with a more specific reference to our spec
ashok: simple question...says points to a policy assertion.....is this one assertion?
glen: the text was meant to be
generic since the policy framework was not yet within the
... question is, should we now make it a wsp:Policy assertion
asir: i can't see why there
wouldn't be a normative reference
... there are 17 references already in the primer
... timing will be a challenge
... phillipe looked at the examples in the primer and approved
paul: this is a process heavy issue---- was raised at the CG
fabian: i have some confused questions about who is defining the assertions
<paulc> glenn: +1
fabian: we need to make clear that its addressing that should be defining the assertion but its ok to have a reference in the primer
paul: are you talking about 3619?
<GlenD> (I was +1-ing the idea that we wouldn't talk about the assertion, and leave it to WSA to define it and any text about how the WSDL extension and the Policy Assertion would coordinate)
vlad: more common question....if
addressing defines this, its "outside" the framework if its a
... it says it "might be an assertion"
asir: it can be either a plain wsdl assertion or a policy assertion
vlad: how do we process it if its a wsdl element?
asir: that's the 3rd question
vlad: its about all kinds of extensions and how they relate to alternatives
paul: this may be related to the other thread
paulc: we have to gain some experience with this
jeff: should we separate this into 3 items/
glen: great for wsa to put in a reference to policy and they should define what the assertion is and what it should mean if there are the two
paul: that's the ideal, but you
ignored the process problem, because they would have to go back
to working draft and they are already in cr
... maybe the text in the wsa doc should be something like "as a policy assertion in a policy framework" ---such as wsp: Policy
jeff: we don't want to restrict the e.g. to just wsp:Policy
<paulc> From WS-A WSDL binding:
<paulc> (e.g., as a policy assertion in a policy framework
<paulc> maybe this could changed to:
<paulc> (e.g., as a policy assertion in a policy framework such as WS-Policy
jeff: the group could do this as
a separate note
... you could do this as a req track note
paul: and it would normatively
tie the two together
... suggest that if the timing of a normative change would impact their work, they could do something like the "such as"
paul: you didn't answer the
question, you ack'd the issue
... what happens if they're both there?
... if you want to make the information more broadly understood, you would express it in both ways
... suggest that at a minimum we should suggest they make the non-normative reference
prasad: as long as they are logically consistent, you could use both representations
RESOLUTION- 3656 is to make the non-normative change as a minimum, #2 yes there are examples in our primer and #3 we don't think there's an issue with both methods of expression
<scribe> ACTION: Asir to respond to phillipe and bob with the resolution for 3656 [recorded in http://www.w3.org/2006/09/13-ws-policy-minutes.html#action03]
<trackbot> Created ACTION-104 - Respond to phillipe and bob with the resolution for 3656 [on Asir Vedamuthu - due 2006-09-20].
yakov: expand the scope of the
... includes 5 entities in a web services model
... each of these might specify policies
... example given was authorization
... don't see any limitations in the specification to preclude this
... replace requestor/provider with entity
asir: do we get time to review this?
paul: how long do you need?
i asserted that Tony had some concerns and might not have time to repsond
paul: put the discussion on the agenda for tomorrow morning
ashok: section 4 allows you
attach policies to wsdl 1.1 so this indicates the spec sees
attachment to 1.1 important but when you try to do this with
external attachment you have no uri mechanism
... you may not be able to add the policies to the wsdl
... this spells out a uri scheme to refer to wsdl 1.1 components using the external attachment
... take the uri and use it as a domain expression
... use the algorithms in 4.1 to work out the effective policies
... at the end also talk about how to attach to other things
... talk briefly about http and jms
paul: obvious question, wouldn't
other people find these uri's useful
... is there a model of where this goes?
ashok: that's one of the things
we can talk about
... can't ask wsdl because they're not going to work on 1.1 anymore
... whether we want it as normative or non-normative thats ok
paul: can it be a note?
ashok: that is another option
jeff: notes you don't maintain
ashok: what about as an appendix?
vlad: does anyone own 1.1?
... don't think policy should really own this?
... what about wsi?
jeff: too difficult to do that
prasad: clarification.....we refer to wsdl 1.1 or 1.0?
prasad: when you have your namespace fragment your token should be 1.1
ashok: yes that's a useful thing
<prasad> ac pr
asir: question..in attachment draft there is a section 4 that talks about attaching policy to wsdl 1.1 ... this describes a model and a mechanism....is any of this material required to make this work?
ashok: this is something
... using the external attachment are different ways of doing the same thing.....to do when you can't annotate the wsdl
prasad: here you inline it so not required for section4
asir: uri fragment identifiers
are pieces of domain expressions
... domain expression is independent...considering the timing an the amount of work to make this work why is this in scope?
ashok: what work?
asir: more work needs to be done to make this into working draft
paul: ashok is asserting that
this can be dropped in....
... there might be a sentence or two that needs to be added
asir: why are we considering domain expressions as part of the work of the working group
paul: not sure this is domain specific
dan: this is domain dependent
paul: why does the external exist then?
asir: external attachment has points of extensibility section 3.4
prasad: so this is within the charter because its just defining a wsdl 1.1 external attachment
jeff: are you making an explicit request for this to be out of scope?
asir: phillipe has mentioned that the w3c sees this as out of scope
vlad: then we make external attachment unusable for implementors
paul: there are no motions on the
... there are no examples
... we need an example of how it would be used
ashok: you would put this in the
external attachment where it says domain expression
... need to look at the schema for applies to
... so I'll have to wrap it in an element
paul: if you have a definition of an element it would be a usage of the extensibility point
dan: i see that we're supposed to
create an attachment for 1.1 and trying to
... to do another one, but is it possible to copy the wsdl and inline it using the existing mechanism
... now we'll have 2 mechanisms
ashok: wsdl 2.0 spec defines this and you can do exactly this with 2.0
paul: if you put this is the spec, we will need to test this in CR
dan: the current proposal for 2.0 is an inline method only
paul: same issue exists for 2.0
vlad: this could be an extension to the existing document for only wsdl 1.1
prasad: bigger question on the table is are we in scope or not?
ashok: maybe i should talk to my lawyer :-)
paul: we have an idea of what the
technical material is
... applies to requires element content so anything inserted has to be wrapped
... ms and w3c assert that this is out of scope
... oracle, sap, layer 7
yakov: include it
<prasad> From the charter it seems out of scope but could be a useful (simple) addition
paul: dale "general purpose"
mechanism .... ambiguous
... glen, monica, its useful
fred: how much work?
asir: should we ask who will implement?
paul: too early to ask this
... at risk...when you are in CR you can delete something if you didn't get successful interop, you have to go back to working draft, so when we go into CR the question will be asked
... you explicitly identify features at risk when you go into CR
touf: how is the decision made to remove it?
monica: doesn't this relate to my question on exit criteria?
monica: you can't use exit criteria to indicate something is optional?
paul: just because something is optional doesn't mean you can get away without testing it
jeff: proper way to state it, is
later on in the process we will set what the exit criteria is
... to some extent we have latitude to set that
paul: the minimum is 2 and w3c prefers one open source
jeff: some set of things you have 4 implementation, for others you might only have pairwise interoperabiltiy
paul: we have to tell the director when we go into cr
fred: what is the risk?
<Fabian> can we please honor the queue?
fred: in scope
fabian: i don't think anyone can
interoperate on external attachment
... as it is today
paul: i have always thought we had to pick a domain for testing
fabian: this is not the same
... i don't see why we couldn't define the same thing for policy attachment
... in scope
jeff: its premature to talk about
what is at risk
... not the concept of at risk, but the specific features that are at risk
<Fabian> I was saying: Internal attachment to WSDL 1.1 is clearly defined, no reason why we couldn't do the same for external attachment
asir: more technical work to be done....
paul: we have a sketch
asir: there's is an rfc that talks about fragment ids, for 2.0 there was also a new media type that needed to be defined
paul: the spec didn't define a media type?
asir: 3023 is the rfc
paul: question is ...are there any conflicts with these frag ids and the way people do it today>
ashok: we will look at that
paul: so unless we define a mime type and the frag ids within the mimetype we might have an issue
<asir> Paul - please project http://www.w3.org/TR/2006/CR-wsdl20-20060327/#ietf-draft
paul: so if we have these
fragment ids we need an annex in the document to define the
... this could be why the w3c thnks this is out of scope
... summary- the current proposal needs some more work for sectoin 3.4 and there is a concern for defining fragment ids
<scribe> ACTION: paul to discuss the summary of the proposal with the w3c [recorded in http://www.w3.org/2006/09/13-ws-policy-minutes.html#action04]
<trackbot> Created ACTION-105 - Discuss the summary of the proposal with the w3c [on Paul Cotton - due 2006-09-20].
<Ashok> scribe: Ashok
Restarting after lunch
PaulC: Consider using XPtr to point directly into the XML --- Bug 3599
<scribe> ACTION: Ashok to review 3599 proposal ked using XPtr [recorded in http://www.w3.org/2006/09/13-ws-policy-minutes.html#action05]
<trackbot> Created ACTION-106 - Review 3599 proposal ked using XPtr [on Ashok Malhotra - due 2006-09-20].
Items 18b and c queued up for Thu morning
Agenda for this afternoon:
20. Issues requiring more discussion or proposal (con't), Chair (11:00 am PDT)
d) Optional Assertions may not be usable in all circumstances, Umit
e) Semantics of successful intersection determined by domain-specific assertion content, Glen D
<scribe> ACTION: item to [recorded in http://www.w3.org/2006/09/13-ws-policy-minutes.html#action06]
f) The absence of an assertion should not mean that the behavior is "explicitly prohibited"
Asir: on 3564, Umit took an action to prepare text for the primer
This was Action 83 ... it's closed ... pts to 3577
<asir> link to the minutes http://www.w3.org/2006/08/30-ws-policy-minutes.html#item24
asir: Action was recorded incorrectly
PaulC: we fixed that
PaulC: has anyone looked at this material? I bet not.
<PaulC> We think the operative material for 3564 is at:
PaulC: The guidelines doc has
some wording to handle this -- Maryann says
... Let's wait for Maryann to get back ... you all shd review material
... Start discussion on 3577 ... there has been email discussion
<asir> There are two e-mails on this issue
danroth: issue is abt
domain-specific intersection ... spec speaks only abt Qname
... this is often not enough so we need to say something abt domain-specific intersection
... onus is on intersection doer to understand domain-specific intersection
<PaulC> DavidO: we are on 3577 agenda item 20 e)
<daveo> thx pc
Discussion of when domain-specific assertion is required
<PaulC> Dan: the requirement for domain specific intersection requirements can be queued off the QNAME
<PaulC> If the policy processor understands the QNAME then it should know if specific intersection knowledge is needed and available.
GlenD: wsp:Policy element
proliferation is a problem
... Take some usecases and say if yr mail addresses them
<PaulC> DavidO is next on the queue
Frederick: Isn't there a case where you may not understand that a particular QName has special semnatics?
danroth: I cd not come up with a case that requires this flag.
<PaulC> DavidO: would really like an motivated use case for a change here
GlenD: Explains use of the
... Another solution is to disallow domain-specific intersection. That's a bad idea.
... So lets look at test and see if we can clarify
Frederick: This mustUndertand come out in the wash...
PaulC: No consensus for change
GlenD: last para of section before 5 explains domain-specific ... need to make much clearer ... soemthing up at the top of the section
PaulC: If domain-specific intersection alg is required you will know that by lookig at the Qname. This needs to be clearly stated in the spec.
DaveO: Is there some guidance for assertion authors?
General confusion abt what Dave said
DaveO: You can decide to use many QNames or one QName with parameters
PaulC: If you don't recognize the QName you fault
GlenD: need a generic domain independent intersection algorithm
PaulC: Cannot do that
<asir> Guidance in the framework and guidelines for authoring assertions
<asir> if there is domain specific intersection, it is indicated by the QName of the assertion.
PaulC: No consensus for adding metadata bit ... there is a design issue on granularity of design of assertions... need some words to say that
danroth: guidance on using parameters or nested policy ... nested policy used in intersections ... parameters are not
PaulC: I see 2 actions. Resolve
by asking editors to add text in IRC re mapping from Qname to
... Guidelines for authoring assertions.
<PaulC> If domain-specific intersection alg is required you will know that by lookig at the Qname. This needs to be clearly stated in the spec.
<scribe> ACTION: Asir, to add above text in spec. [recorded in http://www.w3.org/2006/09/13-ws-policy-minutes.html#action07]
<trackbot> Sorry, couldn't find user - Asir,
<scribe> ACTION: asir to add above text [recorded in http://www.w3.org/2006/09/13-ws-policy-minutes.html#action08]
<trackbot> Created ACTION-107 - Add above text [on Asir Vedamuthu - due 2006-09-20].
<asir> related editorial action is http://www.w3.org/2005/06/tracker/wspolicyeds/actions/29
Above text is: If domain-specific intersection alg is required you will know that by lookig at the Qname. This needs to be clearly stated in the spec.
RESOLUTION: 3577 by these changes
PaulC: Add sentence ... If you do not recog Qname it is a mistake to do domain independent intersection.
<PaulC> Glen is going to correct this.
GlenD: amends above
<GlenD> If you don't recognize a QName, you cannot guarantee anything about the compatibility of the intersected alternatives.
<scribe> ACTION: maryann to add this guidance in guidelines document [recorded in http://www.w3.org/2006/09/13-ws-policy-minutes.html#action09]
<trackbot> Created ACTION-108 - Add this guidance in guidelines document [on Maryann Hondo - due 2006-09-20].
<asir> Updated editorial action is http://www.w3.org/2005/06/tracker/wspolicyeds/actions/29
Vlad: There is no domain independent intersection
<asir> I don't understand the statement 'there is no domain independent intersection'
<GlenD> in other words, it doesn't do you much good to do intersection if you don't actually understand the QNames involved, because of the possibility that any of those QNames might require domain-specific stuff.
danroth: text in 3.2 says
assertion whose type is part of policy vocab and is not
included in alternatives is explicitly prohibited.
... what does this mean?
<vladB> intersection mechanism must know (i.e.recognize) the assertion, which is domain-dependent
danroth: if a client sees an
assertion in one alternative and not in another he cannot send
a msg ... explictly prohibited
... another interpretation is that all it means that I don't do that but you can try
maryann: you are supposed to declare what you know ... so if it's not there you cannot do it
<toufic> Dan's proposal: http://lists.w3.org/Archives/Public/public-ws-policy/2006Aug/0110.html
Ashok: wording is correct ... no change is needed
danroth: if we clarify that client can send the msg that wd fix the problem
<scribe> ACTION: Ashok to send additional clarifying wording for 3602 [recorded in http://www.w3.org/2006/09/13-ws-policy-minutes.html#action10]
<trackbot> Created ACTION-109 - Send additional clarifying wording for 3602 [on Ashok Malhotra - due 2006-09-20].
<scribe> DONE with 3602
START WITH 3613 --- Frederick's issue
Frederick: Suggested minor editorial changes ... and there is a suggestion in a subsequent msg for some wording in the primer
PaulC: What kind of example do you want in the primer?
FH: We may not need example if we resolve another issue ... so no change needed
RESOLUTION: Close 3613 with the explanation in the msg above.
<scribe> ACTION: FrederickHirsh to close issue with above another [recorded in http://www.w3.org/2006/09/13-ws-policy-minutes.html#action11]
<trackbot> Sorry, couldn't find user - FrederickHirsh
<scribe> ACTION: FrederickHi to close issue with above anchor [recorded in http://www.w3.org/2006/09/13-ws-policy-minutes.html#action12]
<trackbot> Sorry, couldn't find user - FrederickHi
<scribe> ACTION: FrederickHirsch to close issue with above anchor [recorded in http://www.w3.org/2006/09/13-ws-policy-minutes.html#action13]
<trackbot> Sorry, couldn't find user - FrederickHirsch
RESOLUTION: Close 3549 with proposal in above mail.
<asir> related editorial action is http://www.w3.org/2005/06/tracker/wspolicyeds/actions/30
PaulC: You had updated 3577 with material you proposed to add to the guidelines document
Correction .... 3564
PaulC: WG shd review the text
<maryann> ashok: there's a sentence in the spec that indicates that assertions are not ordered
<maryann> ashok: there are assertions in securitypolicy that specifically add ordering as part of the assertion type
<maryann> glen: do they want a specific order to the processing?
<maryann> ashok: yes
<asir> Dan's e-mail is at http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0011.html
<toufic> oops, scooped! :)
<maryann> glen: instead of qname....do you want something else?
<maryann> ashok: so if we accept dan's premise we should add some text
<maryann> paul: it says that already
<maryann> ashok: you can add assertions that indicates runtime behavior
<maryann> ashok: it wold be good to have some text to that effect
<PaulC> Add the following text after the quoted text in 3638:
<PaulC> However, domain authors can write assertions that control the order in which behaviours are applied.
<asir> related editorial action is http://www.w3.org/2005/06/tracker/wspolicyeds/actions/31
<maryann> ashok: what we would like is a method of referring from a message to the policy
<PaulC> See thread at http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0032.html
<maryann> ashok: you could use this mechanism to indicate a selected althernative
<maryann> glen: do you want us to define a soap header?
<maryann> ashok: yes
danroth: in my mail i argued any option is acceptable
<maryann> dan: you could use any of the alternatives that were produced from the intersection of the client/provider
<maryann> glen: might have an assertion that doesn't show up on the wire
<maryann> glen: the header would tell you which policy alternative was selected
<maryann> vlad: if you look at the message exchange you might need more
<maryann> vlad: if you have message exchanges you might want to indicate the alternative selected for the response as well
<maryann> asir: there is a separation of concerns of protocol vs metadata
<maryann> relying on metadata at runtime violates the protocol
<maryann> glen: it might be useful
<maryann> asir: but its not required
<maryann> paul: no one has defined a header for this
<maryann> asir: if its not mandatory, this could be expressed as a behavior
<maryann> ashok: how is it added?
<maryann> paul: use the extensibility to do this
<maryann> ashok: it would be nice to do it one way
<maryann> ashok: you don't have to use it but if you want to do it, there is a standard way
<maryann> paul: once you put the must understand on it
<maryann> jeff: that's always true
<maryann> glen: if you're going to send this information, there is a well known structure for it
<maryann> dan: just talking about one solution for solving the ambiguity problem on the wire
<maryann> dan: there's lots of ways to do this
<maryann> yakov: there is a usefullness for this mechanism
<maryann> yakov: i don't see how we can do it as a soap header
<maryann> yakov: i see the need, but we would need a specific proposal
<maryann> paul: there may be consensus that there's a need, but not a need to do it in the framework
<maryann> paul: with the schedule we have its pretty compelling to be able to do it with the existing extensibility
<maryann> paul: should we put this on hold?
<PaulC> use the extensibility mechanism to define a asseriont called "notify" that does what 3639 asks for.
<PaulC> in this way the framework does not have to be modified AND the assertion can be written and used RIGHT away.
monica: will send mail usecase that applies to 3639
PaulC: I sent mail that this was out of scope
GlenD: We discussed on call and
people said they needed to see more
... Its not a fully-fleshed proposal just to give people a hint ...
<PaulC> Glen's proposal: http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0028.html
<asir> MEX is at http://schemas.xmlsoap.org/ws/2004/09/mex/
GlenD: Need to decide how policy attached to Endpoint interacts with policies attached to other WSDL subjects.
PaulC: W3C did not add this to charter because it thought solution may come from other parts of the industry
JeffM: You are talking abt a private spec --- MEX
GlenD: How many layers of the stack do I need to know to get work done
<jeffm> acutally, why are we talking about MEX - -isn'
<jeffm> isn't that out of scope?
jeffm: we have an epr ...
which has a metadata container which has a MEX container which can contain a policy
GlenD: lets have a strawpoll to ask if this is in scope
<PaulC> acl asir
asir: explains MEX ...
<monica> thanks prasad - typo
<PaulC> DavidO: we are on agenda 25 a)
<PaulC> Policy Attachment to WS-Addr EndpointReferences
Monica: we shd separate whether issue is in scope with whether MEX is in scope
DaveO: Glen said "when it is
standarized by W3C" ... that may or may not happen
... Issue abt which spec decides what goes in a MEX section
... Or if MEX shd decide where and how what goes into MEX
JeffM: Clarify yr conclusion, pl, Dave
DaveO: I wasn't drawing a conclusion ... just clarifying tradeoffs
JeffM: I don't understand what
Schema has to do with this at all
... We have a problem ... we can use the hook the we have to put policy in an EPR
... Why wait some unknown ant of time. If MEX went to standards track today we cd not use it for an year or year and a have.
PaulC: I will take strawpoll
GlenD: When we designed the
metadata section in WS-Addr we used policy as a usecase
... So that when had policy we cd use it immediately
STRAWPOLL: Is this in scope?
MS: Out of scope
Oracle: In scope
W3C: Out-of scope
Sonic: In scope
PaulC: I don't see a consensus
for doing this work. I'm decalring this out of scope.
... Can anyone not live with not doing the vote. Yes from Sonic, Oracle
FH: can we do more work so that some votes may change?
GlenD: Explains what the Ws-Addr spec provides
CORRECTION: PaulC: Can anyone not live with not doing the work. Yes from Sonic, Oracle
Discussion on whether Glen's solution is useful. DaveO pushes back
JeffM: The issues that Dave just raised isn't going to get defined by MEX but needs to be defined by the Policy WG.
PaulC: It was explicitly left out
of the charter. So I'm going to rule it's out of scope.
... If Oracle and Sonic want to approach the W3C they are welcome to.
... 3620 is closed. I will assign to vNext.
... ... It's not vNext, it's Future Consideration.
... We will do Bijan's 3 issues at 9AM tomorrow. Then 3602 for which Ashok will provide wording.