See also: IRC log
<mnot> Scribe: Hugo Haas
Jonathan: I sent a new proposal for i064
Mark: we'll take this up in this call
Jonathan: I sent a couple of issues that are not on the issues list
Mark: one is on the issues list, and the other one was a typo and it was dispatched to Marc
Umit: I would like more time to review the minutes
Mark: we'll approve them next week then
<scribe> ACTION: Marc Hadley to incorporate namespace policy into drafts and RDDL. [PENDING] [recorded in http://www.w3.org/2005/10/10-ws-addr-minutes.html#action01]
<scribe> ACTION: [DONE] Arun Gupta to iterate his testing document to categorize and reformat. Due 2005-10-10. [recorded in http://www.w3.org/2005/10/10-ws-addr-minutes.html#action02]
<scribe> ACTION: Editors to ensure we meet our charter with regard to backward compatibility warnings for WSDL 1.1, aligning it with the direction we took for SOAP 1.1 [PENDING] [recorded in http://www.w3.org/2005/10/10-ws-addr-minutes.html#action03]
<scribe> ACTION: [DONE] Jonathan Marsh to formulate a proposal for a migration guide. [recorded in http://www.w3.org/2005/10/10-ws-addr-minutes.html#action04]
<mnot> http://www.w3.org/mid/37D0366A39A9044286B2783EB4C3C4E849E1BD@RED-MSG-10.redmond.corp.microsoft.com
<mnot> http://www.w3.org/mid/37D0366A39A9044286B2783EB4C3C4E849E1E7@RED-MSG-10.redmond.corp.microsoft.com
Mark: it seems that the Group is happy with our comments
<mnot> http://www.w3.org/mid/37D0366A39A9044286B2783EB4C3C4E849E230@RED-MSG-10.redmond.corp.microsoft.com
<abbie> hi, can u please add me for the roll call
Jonathan: no, there was no pushback
Hugo: what's the status of our discussion about wsoap:action granularity?
Jonathan: we haven't made a decision yet
Hugo: in case we don't adopt this proposal, we should make this WG aware of it
http://www.w3.org/mid/433D6C7E.2070002@tibco.com
[ DaveH goes over his proposed issue ]
Hugo: I thought we had agreed not to talk about dispatching in the spec
DaveH: in that case, we should
maybe be a little more explicit
... I find this sentence in our spec very vague
... I'm happy with not getting into dispatching in the core,
but the SOAP bining may be different in that regards
... we're not really taking on dispatching, but we're implying
we are
Paul: it seems to me that you're talking about what WSDL does with the message
DaveH: my assumption about the outbound side is that the value of action will be used in outgoing messages
Paul: I don't think we should consider SOAP+WSDL as a big lump when it comes to action
DaveH: we say action is mandatory, but we don't say what it means
<inserted> ... how about its meaning, uniqueness, etc.
Hugo: action identifies the semantics of the message, and it is possible to have identical actions for multiple messages in the same operation if they have the same meaning
Mark: do people want to see this on our issues list?
Jonathan: it doesn't seem to harm
<uyalcina> +1 to Marc Hadley
Marc: I'd like to understand how the current draft is broken
DaveH: nowhere in this spec do we ever define what dispatching off of action means
Marc: I don't think we should go there
<pauld> WSDL position on dispatching is a rather unhappy compromise resulting from a lot of discussion and a minority opinion or two
Mark: we talked about raising the bar for accepting as issue
<RebeccaB> +1 to Marc's position that we don't need to go there
Mark: I would like to have issues
seconded by somebody
... does somebody want to second this issue?
Umit: given the history in WSDL, I don't think we should talk about this issue
RESOLUTION: proposed issue not accepted in the issues list
<mnot> http://www.w3.org/mid/37D0366A39A9044286B2783EB4C3C4E831ED79@RED-MSG-10.redmond.corp.microsoft.com
[ Jonathan describes the issue ]
<mnot> Minutes of i021 decision: http://www.w3.org/2002/ws/addr/5/04/20-ws-addr-minutes.html#item05
Mark: my concern is that we may
be reopening a previous issue (i021)
... it's not clear that an explicit decision was made at the
time
Hugo: I thought we considered
wsoap:module, but ended up with UsingAddressing because we
wanted to go beyond SOAP
... is that what we want to reconsider?
Mark: my recollection is that we wanted to have a cross-WSDL versions mechanism
Marc: I think the minutes are pretty clear about defining UsingAddressing beyond SOAP
Jonathan: so how would you use it beyond SOAP?
Rebecca: how about if you use multiple bindings, e.g. multiple ports with different bindings?
Marc: does that mean that you want to highlight the use Addressing for our SOAP binding regardless of the underlying protocol?
Jonathan: yes
Marc: I think that we have some mentions of SOAPAction that may be HTTP specific
Jonathan: I'm assuming that it's
only applying to cases when SOAPAction makes sense
... if we leave it the way it is, it's not clear with WS-A
binding is in use
Mark: is that a lie down on the road issue for you?
Jonathan: no, it's a spec consistency issue
<uyalcina> it is implicit in the context
Hugo: have you considered using having a marker for specifying what exact binding is in use?
Jonathan: no, I think that you can do that in WSDL in already, so we don't need to architect an extensibility point here
<marc> the location of UsingAddressing extension in the WSDL gives the necessary context to determine th ebinding in use
Mark: anyone seconding this issue?
[ silence ]
RESOLUTION: proposed issue not accepted in the issues list
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Oct/0027.html
<mnot> http://www.w3.org/mid/OF6F7462C5.C2E3A435-ON80257090.006FAE6C-80257090.00715FDC@uk.ibm.com
Marc: I'd like to think about it
more
... it looks like a backwards compatibility feature
... but it may complicate the defaulting rules
<uyalcina> I prefer getting this into the issues list
Anish: I think we can put it on the issues list
<uyalcina> lets discuss next week
Anish: I am seconding it
RESOLUTION: Issue added to the issues list
<scribe> New proposal: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Oct/0028.html
Mark: are people comfortable with this new text or do they want more time?
Anish, Hugo: we're OK
Marc: what's the point of the last paragraph?
Jonathan: letting people know that they may want to go and fix their action values
Marc: I'm OK to aprove it now
Mark: any objection to this proposal?
[ silence ]
RESOLUTION: i064 closed and resolved as proposed in http://lists.w3.org/Archives/Public/public-ws-addressing/2005Oct/0028.html
http://lists.w3.org/Archives/Public/public-ws-addressing-comments/2005Sep/0004
[ Hugo summarizes where we're at ]
<Marsh> +1 if it'sn not substantial
Mark: we wanted to make sure the proposal wasn't a substantial change
Tony: I agree it isn't
RESOLUTION: cr6 closed and resolved with http://lists.w3.org/Archives/Public/public-ws-addressing-comments/2005Sep/0004
[ nobody objected to this resolution ]
http://lists.w3.org/Archives/Public/public-ws-addressing-comments/2005Oct/0000
Anish: if we have quotes in an HTTP header, are the quotes significant?
Mark: it's specified per header
Marc: I'd like to go and check the media type definition
<scribe> ACTION: Marc to come up with a proposal for cr8 [recorded in http://www.w3.org/2005/10/10-ws-addr-minutes.html#action05]
<mnot> http://www.w3.org/mid/434703A4.6070401@sun.com
CR test cases: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Oct/att-0018/CR_TestCases.html
[ Arun introduces the document ]
<inserted> -- Core 1. "none" URI (2.1) - REQUIRED
DaveH: I don't think that test 1 is a valid test as it's not tied to a requirement
Paul: I think that a "none" URI identifies a one-way message
DaveH: the "none" sort of turns a req-resp into a one-way
<mnot> "Messages sent to EPRs whose [address] is this value MUST be discarded (i.e. not sent). This URI is typically used in EPRs that designate a reply or fault endpoint (see section 3.1 Abstract Property Definitions) to indicate that no reply or fault message should be sent."
Marc: could we have an endpoint which always generates faults, except when the recipient is the "none" URI?
DaveH: that's a way indeed
Mark: we could have an HTTP
transport response, without a SOAP response
... we need to work with keeping in mind that we need to
demonstrate features using these tests
Marc: the way I saw this is that you'd better use "none" in a one-way message becouse of the defaulting rule
Arun: so we're not going to do the the 1&2 sub-bullets as specified; we're going to use a request-response with a "none" URI which will degenerate into a one-way
-- Core 2. Endpoint Reference Infoset Representation (2.2) - REQUIRED
Mark: this seems to be a behovioral text of a reply
Arun: we can add more tests about how a FaultTo gets represented
Katy: is this text just to test the serialization of an EPR?
Mark: yes
DaveH: how do you get out the abstract properties from these?
Mark: it's implementation specific
Arun: I'll add some information about success criteria
Mark: we talked about using XPath for this
-- Core 3. Endpoint Reference Extensibility (2.5) - REQUIRED
<pauld> i can build test cases from these, and build XPath expressions to compare, however some complete example messages would be useful
Anish: if the test doesn't define
what these extensions mean, how do we know if the receiving end
saw them?
... for SOAP 1.2, we had defined a header whose function was to
be echo'ed back
Mark: could you make some proposals around this?
<scribe> ACTION: Anish to propose meaningful EPR extensions for test 3. Endpoint Reference Extensibility (2.5) [recorded in http://www.w3.org/2005/10/10-ws-addr-minutes.html#action06]
Katy: it's not clear what we're testing here: the sending agent or the receiving one?
DaveH: I don't think that we could test the client side
Mark: I think that these differences will become more clear when we put those tests into Paul's framework
-- Core 4. XML Infoset Representation of Message Addressing Properties (3.2)
Arun: 2.1. may apply here
-- Core 5. wsa:To defaulting (3.2)
[ no comments ]
-- Core 6. wsa:ReplyTo defaulting (3.2)
DaveH: in that case, you don't need to talk about the client at all, it's a server test
-- Core 9. Formulating a normal Reply (3.3)
Arun: More tests can be added here
-- Core 5. wsa:To defaulting (3.2)
[ Going back as requested by Umit ]
Umit: you're talking about the reply message here, right?
Arun: that's correct
-- Core 10. Formulating a Fault Reply (3.3)
Katy: do we need the
isRefParam="true" in the EPR?
... there's a typo in sub-bullet 1
Arun: thank you
-- SOAP 1. SOAP 1.2 Feature interaction with Action (2.4)
[ No comments ]
-- SOAP 3. SOAP 1.2 Anonymous Address (3.5)
[ No comments ]
-- SOAP 5. SOAP 1.1 interaction with Action (4.2)
[ No comments ]
-- SOAP 6. SOAP 1.1 Anonymous Address (3.5)
[ No comments ]
-- SOAP 8. InvalidAddressingFailure Fault (5, 3.2)
[ No comments ]
Mark: I think that the next step is for Arun and Paul to integrate those in Paul's framework
Paul: we will need messages for inclusion in the framework
Mark: I'd like us to identify which features are not tested by those tests
<scribe> ACTION: Paul to take Arun's work and integrate it in his framework with Arun's help by 2005-10-17 [recorded in http://www.w3.org/2005/10/10-ws-addr-minutes.html#action07]
Paul: do you think that we have good coverage with those base on the list we discussed in Palo Alto 2 weeks ago?
Mark: have you guys changed the spec so that we have a section called creating a message from an EPR?
Tony: not yet, but soon
Mark: we will be considering
Paul's document in the coming weeks to make user we understand
it and we have enough tests to test implementation in CR
... we have 3 concalls between now and Tokyo
... we're going to continue revising the test doc
... does that seem reasonable?
[ silence ]
ADJOURNED