See also: IRC log
Resolution: New issue concerning version of policy namespace accepted
Resolution: Minutes of last meeting accepted
Proposals for E, with New proposal F.
Proposal E: Parameters
Proposal F: This new alternative F takes the approach of nested support
> assertions, however
> non presence of a nested policy assertion now implies that the
> associated response mode is not supported.
Gil: my concern is with nonAnonymous assertion. Non presense of non anonmous means non anymous supported. Due to wide open definition of non anonymous
<Zakim> anish, you wanted to ask about composibility with rm assertion
The policy expression can compose with ws make connection, by also asserting nonAnonymous support
Anish: rm is optional, use anon back channel. Need two alternatives, anon another non anon as well as rm
We can do examples for all of these cases.
Composition with RX should be shown to everyone's happyness.
Gil: Reply to anon, fault to is non anonymous. These assertions cover responses as a Bob: can we enumerate use cases for an email discussion.
<MrGoodner> http://lists.w3.org/Archives/Public/public-ws-addressing/2007Mar/0043.html
Marc G: we have been talking about another alternative with nested assertions, (alternative G). This mail is differnent says addressing without nested policy says only ws addressing is supported. It retains required language, but they cannot be used on same alternative.
Tom: what is difference between new G and the old alternative A?
Bob: I did not see your mail Marc.
General agreement on use of nested policy.
Gil: Client can look at parameters to determine if it can interact with a server
<monica> Need to also ensure we understand how this is handled in the default intersection algorithm. Consider how such assumptions may have an influence with other composable specifications. Particularly if you wish to leverage what is defined in WS-Policy.
Paco: I agree with that.
Tom: we need to understand the requirements before we can decide on parameters of nested policy assertions.
<anish> i don't understand the schema ns issue. i.e., why is it an issue?
Marc G: we worked on this new proposal G, since we find value in doing the intersection matching.
<gpilz> anish - because then we are likely to argue about what version of WS-Policy we reference
Gil: if we used nested parameters we wuld not need the wsp namespace in our schema.
Anish: this metadata spec in w3c has w3c restrictions. anyway.
Marc G: I agree with anish. and the fix to the new issue is to change to CR reference.
Bob: can we agree that alternative e is unacceptable, since intersection mechanism.
No objection:
Bob: can Marc explain the differences.
MarcG: G stays with requirements semantics. F has empty addressing meaing no responses, G empty means addressing is fully supported. for mixed mode F has both, for G use unqualivied addressing assertion.
MarcG: both compose with make connectib
Tony: what about no responses?
MarcG: G does not allow saying no responses. But none is allowed in both
Tom: how important is use case for no responses supported?
Bob: is more time required for us to decide between the alternatives?
general agreement to discuss both over email.
Bob: Is one week ok for next
meeting?
... April 2 for next meeting?
Agreed, next meeting April 2.
<plh> regrets for next meeting
Marc: it is a simple bug fix.
Bob: does everyone agree to resolve by plugging in the new namespace from CR version of WS Policy.
Resolution: New issue resolved by fixing to CR version of WS Policy.
Agreed to have use case discussion for proposals F or G on email.
<monica> http://www.w3.org/ns/ws-policy
Bob: Policy interop in May in
Ottawa. IBM can test metadata interop but we need at least one
other company.
... Other companies should come forward, so we can meet our
interop requirement of 2.