See also: IRC log
minutes of dec 7th accepted with no objection
minutes of dec 13th, as corrected in email, approved
Actions related to issues 17, 20, 22, 33, 34 done.
See public-ws-chor link. They asked for review by end of January.
No volunteers to review; no one on the WG
Yin-Leng: I will review (after Mark threatens to volunteer someone:)
ACTION: Yin-Leng to review ws-chor and report by 1/13 for F2F
Mark: Where to send replies was removed from core spec. Yin-Leng pointed out that soap spec has similar language. We need owner for this issue i040.
ACTION: Arun to own i040
Mark to confirm Harris owns i041.
dims: did not have time to walk with William of HP yet; leave action open
Mark: MBaker's posting, originally merged into i006, but email discussion leaning toward a separate issue.
Jonathan: can we avoid going down the standard "mark baker" issues here?
Paul: I can't think of use cases right now for this. This seems more like a "nice to have" than a defect that needs to be fixed now.
David: said similar to Paul, but spoke first. :) I am guessing that an HTTP-aware application could leverage things that could be in ws-addr, but aren't now. seems to require new bindings.
Anish: nothing in ws-addr *prevents* these things being done.
ACTION: Mark to say WG declines issue regarding interaction with application protocols.
Anish: there are deeper issues, so my email re i017 didn't have proposed text. there are two issues, depending on resolution clarifying text might not be needed. we should provide guidelines about re-use of wsa:action wsa:action can satisfy operation-name mapping requirement; define in wsdl2.0 binding
Mark: at f2f we thought wsdl could address this, not ws-addr. change of opinion?
Anish: yes, wsa:action is useful for this
Discussion of whether or not this fulfills uniqueness requirement of operation-name mapping.
We could define a wsdl feature that says how to use ws-addr.
Anish: if not wsa:action is not unique, we cannot fulfill wsdl requirement should we allow wsa:action in wsdls to be non-unique? If so, make it explicit what the impact is.
Jonathan: description and metadata outside the wsdl must be supported.
Anish: I want to see a use-case where non-unique wsa:action makes sense If so, we need to explain the impact of this.
David: what about HTTP GET, where GET is the action? Are we going to limit how folks write wsdl?
ACTION: Anish review i017 to clarify description and sub-issues.
Mark: Let's have discussion of first sub-issue, hopefully resolve at next call.
ACTION: Anish to make strawmap proposal of operation-name manping. Due by 12/30
Anish: i020: what exactly is EPR trying to represent? It seems that this is similar to WSDL2.0 service/endpoint. what is relationship between wsdl's endpoint and ws-a endpoint reference uri? if EPR is a service reference, can we re-use what we have (in wsdl)
Mark: so explanatory text would close this issue?
Anish: yes. or WG decides that this "duplication" is an issue
Discussion of extensibility and constraints of wsdl 1.1, wsdl 2.0, and ws-addr eprs
For example, wsdl is design-time and ws-addr is runtime
<vinoski> this discussion is also related to issue i026
Mark: This is a central issue, let's discuss on list and at f2f
i014 Deferred since Paco and Hugo were not present
i034 Deferred.
Jonathan: Please review if message label is sufficient.
Mark: does wsa:attribute proposal address rich's security issues?
Rich: yes
Mark: have people reviewed the proposals?
Anish: I prefer Glen's proposal; sent email re: attribute proposal
ACTION: Rich to do security/vulnerabilty comparison of wrapper and attribute by 12/31
Mark: Please get all issues about i008 on the email list before next f2f
David: did a first draft of two one-way MEP proposals, a SOAP request and a SOAP response SOAP request is one-way sender to reciever, and protocol-level response comes back that the SOAP application doesn't necessarily see. Note that response can start to come back while request is still going out one-way HTTP binding sends message as POST body; HTTP status codes back HTTP response body is left as an extension point wsdl in-out maps to soap request-response mep, maps to soap 1.2 http binding a goal is to have a new request-response mep that uses two http bindings underneath the new binding might need to understand some ws-addr correlation issues, but i hope not if we don't do the mep we might have interop problems because this mep brought out some issues. this might help wsdl2.0, giving feedback on how to correlate two one-way MEP's, particularly when the request and rsponse transports are different.
Must look at common scenarios, determine applicability and scope to this WG
Mark: Issue i041 is to define use cases, so that's a way to capture it. Encourage people to read David's proposal. Concerned about schedule risk.
Mark: Seasons greetings, and to all a good night.