See also: IRC log
agenda approved
Minutes approved
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.
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
none
call adjourned at 1:59 PST