Agenda Review

agenda approved

Approval of minutes 2007-01-29

http://lists.w3.org/Archives/Public/public-ws-addressing/2007Feb/att-0001/29-ws-addressing-minutes.html

Minutes approved

Does WS-Addressing agree that the means described in the WS-Policy WG feedback is adequate to express our resolution to CR33?

http://lists.w3.org/Archives/Public/public-ws-addressing/2007Feb/0006.html

Comments from Paco: http://lists.w3.org/Archives/Public/public-ws-addressing/2007Feb/0013.html

Paco sent regrets for today's call

cferris: WS-Policy WG not saying WSA WG got it wrong, is expressing some concerns
... Nested expressions not stating requirements, capabilities
... absence not saying anything about capabilities
... when neither presence or absence of expressions expresses requirement not clear what intersection means
... example (from mail) descibed
... adovcating use of wsp:Optional in 3.1.6 allows broader intersection even when policies may not compatible
... WS-Policy WG proposed two alternateives
... 1 Use policy expressions, but make firmer requirements
... (descibes option from message)
... should still compose with MC, wouldn't need to do CR33 all over again
... 2 If these are informational use parameters
... wouldn't participate in intersection
... (on to other points)
... Use of wsp:Ignorable is not appropriate
... (describes points D and E from message)

anish: Tried to make our assertions positive, doesn't say anything about what is or isn't supported
... we want to advertise a capability, not a requirement
... is #2 the right way to do that?

cferris: that's one way to do it
... if you don't want it to participate in intersection
... it is not clear that is an acceptable use of wsp:Ignorable with nested expression

tomr: if you have a policy expression with policy alternatives that gives us what we needed
... use anonymous, notanonymous, or MC with WSA
... need to know at time of decorating WSDL, but this doesn't seem to be a problem

anish: allowing service to be created deployed without rm
... later letting someone make service reliable without changing wsdl

cferis: saying policy doesn't change either?

anish: wsdl says addressing required and anon, as policy in the wsdl

<bob> s/scferis/cferris

cferris: if you change the qos, you have a new policy

anish: you can get policy through other mechanisms, wsdl just one
... adding rm at a later stage, provide that information to endpoints later, but nested policy in WSDL conflicts

cferris: not sure I agree with that

tomr: agree we talked about this, not sure it is important any more

anish: sounds like the policy in the wsdl would need to change

<cferris> I recall discussions where we wanted to enable RM without having to REDESIGN the WSDL MEPs... I don't recall a discusion about not changing the metadata (WSDL/Policy)

katy: parameters were discussed before

<cferris> it depends on what you define as the policy's scope

katy: 1st option was discussed before, thought we couldn't compose with MC anonymous

cferris: see note where we point out the scope of the assertion
... it does seem possible to have two policy alternatives scoped to a single message exchange
... possible to say you require use of SSLor message level as seperate alternative, pick one
... Policy WG would agree that you can have different alternatives that even say conflicting things so long as proper scoping is used

katy: will look through minutes to see how we got to our conclusion on this

cferris: so long as message matches one of the alternatives provided you are good to go

katy: so how can the sitution with expressing use of wsa:anon and accept message using mc anon be handled?

tomr: we were looking at option, providing the MC assertion as an alternative is the way to do this

anish: if you want addr with anon or MC, provide alternatives for WSA+wsa:anon and WSA+MC assertion

tomr: sent example that shows that

gpilz: we're trying to do to much to cover other peoples cases
... we can adopt chris' proposal for 1, we should state our requirement for wsa:anonymous and requirement for anything else

<cferris> +1 to Gil

gpilz: not our job to worry about how to say something like MC uri only

bob: so long as what we do doesn't put road blocks in front of other specs

gpilz: composition with other requirements not something we need to specify in our spec

cferris: agree with Gil, MC could be sibbling of wsa assertion or nested in the wsa assertion
... former seems to make more sense
... agree that isn't this groups problem

katy: need to look into this more, looking at Tom's example can see how this would work

bob: thinks people have good understandig of chris' comments
... do we have a way forward?
... Tom, can you help Tony with text for this?

tomr: yes
... just for normative text, examples will be later

bob: review text from Tom for next weeks call.

Next meeting schedule, face to face possibility?

bob: see note on possible get together for testing

http://lists.w3.org/Archives/Public/public-ws-addressing/2007Feb/0004.html

scribe: Katy confirmed, anyone else?

anish: Maybe, need to confirm

MrGoodner: don't think we will be able to, will inform if situation changes

bob: we need two for CR criteria

AOB

none

call adjourned at 1:59 PST