See also: IRC log
<trackbot> Date: 09 March 2010
<Bob> scribe: Katy
Bob: Trying to schedule F2f for
conclusion of public review
... of LC documents. Tentative dates mid April would require that we have reached LC this week
... but review must be 3-6 weeks
Ram: Will hold provisional date 13-15 April
Bob: This may be de-coupled from last call if we close MOAP today, else we may have F2F to resolve MOAP and might move the date in.
Dug: We are making MOAP progress but not there yet. Within the next day or so there should be a proposal to review
<DaveS> Join the call in a few seconds.
Ashok: Before we all go off and spend lots of time on this, I would like to check that we all agree on the basic use case.
<Dug> +1 to the usecase
Ashok: Use case: We use policy assertions to specify capabilities of Endpoints. We would like to add further policies to the messages not recognised by that policy assertion
<Dug> QoS for the feature operations
<gpilz> s/not recognized/implied/
Ashok: With change use case correct
Asir: The use case is a very general statement
<gpilz> We use policy assertions to specify capabilities of Endpoints (e.g. wst:TransferResource). We would like to add further policies to the messages implied by that policy assertion (e.g. wst:Get).
<gpilz> (a) as a whole (i.e all the operations of WS-T)
Ashok: Does the group think it would it be useful to specify policy for individual implicit feature operations (rather than them all)
<gpilz> (b) individually (i.e. separate policies for wst:Get from wst:Put)
Asir: This level of granularity is useful
Gil: If we don't need to solve this use case then the solution could be far simpler. But it sounds like we agree that we'd like policies to apply to individual implicit operations (rather than to al lthe implicit operations)
<Dug> LOL RTFM is the answer!
<asir> the general use case is valid
<asir> as Ashok mentions .. solutions are in the WS-Policy specs
Bob: I hear agreement on the use
... So, which parts of the proposals to we agree to and which parts are contentious?
Gil: The use case is not already
solved with the existing WS-Policy specs (Asir suggested this
earlier). The WS-Policy specs did not properly anticipate the union
of the implict and application operations and how policy might be
used to target implict OR application operations but not both
... There may be the mechanisms to solve this but we need to explictly explain how to use the existing mechanisms
Dug: I agree with Gil. And this is the core of the disagreement in MOAP - how we want the spec to explain the particular use case
Asir: When Ashok and I described the features, we were specifically discussing how to attach policies to specific operations. My confusion is how the union causes a problem.
Gil: Adding a <wst:TransferREsource> causes WST operations to be added to my application endpoint. I think that the current mechanisms provided by WS-Policy does not provide a way to apply policy to just WS-T Get (for example) and not app operations.
Asir: In that scenario there are 2 different porttypes, one supports app operations and the other provides WST operations. Put the WSDL with implicit attachments in the policy feature assertion.
Gil: But the policy intersection algorithm will not work with WSDL parameter as the WSDL will be a parameter in the feature assertion and is processed by the transfer domain.
Asir: make it a sibling of transfer
Gil: doesn't work because they are the same service
Tom: I would like a clarification. MOAP proposal has mechanism to confgure aspects of endpoint but I am hearing some don't need this
Bob: I would like to understand
points of contention wrt the MOAP proposal. Specific points and how
to move forward.
... Can we get to first part of the proposal where we have issues. I would like to get to the text.
Dug: MOAP v6, example 8-5
Dug: To Tom, problem isn't ise case per say, just what the spec should say about the use case
Dug: Ex 8-5. The nested policy assertion on line 6 is contentious.
Bob: Does this nested policy conform to WS-Polcy
<Dug> (01) <wsa:EndpointReference ...>
<Dug> (02) <wsa:Address>http://services.example.org/stockquote</wsa:Address>
<Dug> (03) <wsa:Metadata>
<Dug> (04) <wsp:Policy>
<Dug> (05) <mex:MetadataExchange>
<Dug> (06) <wsp:Policy> ... </wsp:Policy>
<Dug> (07) </mex:MetadataExchange>
<Dug> (08) </wsp:Policy>
<Dug> (09) </wsa:Metadata>
<Dug> (10) </wsa:EndpointReference>
<Dug> line 6 is the question
Ram: There are a number of different mechanisms external PAs, WSDL, nested. We could remove the contentious line and have a separate issue to talk about after LC
<li> is this example normative or informative?
Ram: or we leave it there but suggest discussion after LC
Bob: This is non-normative text. Which part of the normative text do you disagree with?
Ram: Section 11.1
This extensibility point allows for additional WS-MetadataExchange specific metadata to be included within the policy assertion - e.g. WS-MetadataExchange WSDL, or nested policy assertions related to the WS-MetadataExchange message exchanges. Any metadata that appears is scoped to the operations and features of the WS-MetadataExchange specification.
<Ram> Ram's proposal for Example 12-1: http://lists.w3.org/Archives/Public/public-ws-resource-access/2010Mar/0000.html
Ram: Would be acceptable to go last
call with 1) Mark examples using nested assrtion as work in
progress and may change 2) Incorporate additional example showing
binding in 12-1
... Aspects to be marked example 9.1 text in 11.1 example 8.5
Bob: Any objection to this amendment to MOAP to be used as the resolution 6463 8031 8198?
Ram: I would like clarity on the health warning
<Ram> The use of nested policy expression as described here is subject to changeas it is being currently discussed in the WG.
<Ram> The above is the health warning.
Bob: Any objection to above plus
... no objections
RESOLUTION: MOAP 6463 8031 8198
<scribe> ACTION: Bob to inform ANtoine [recorded in http://www.w3.org/2010/03/09-ws-ra-minutes.html#action01]
<trackbot> Created ACTION-144 - Inform ANtoine [on Bob Natale - due 2010-03-16].
Bob: Editors (Doug) how long will it take to incorporate changes?
Dug: Next couple of days
Bob: Need to take editors' drafts, freeze them, make last call
<Dug> amazing how Tues feels like the end of the week :-)
Bob: Please review docs for any
further 2119 issues
... LC vote will be 1st order of business next call. Any objections?
Asir: What about 8289
Bob: After Doug sends note saying issues in docs, all need to review
<asir> may be a week break after entering LC :-)
<asir> what about the next F2F? You wanted to discuss
Bob: Aim publication 23rd, would a minimum 3 week review be acceptable for F2F or should we move the F2F out.
<asir> Starts on March 17th
Bob: publishing morotorium on 17th
might mean date of publish moves to 30th
... have later date
... for F2F
... 11th-13th May proposed for next F2F
Ram: Microsoft still willing to host
Bob: This might be a good meeting to
have in Europe
... Meeting 11-13 May, WCoast, subject to confirmation by MSFT