Web Services Addressing Working Group Teleconference

discussion concerning final arrangements for Yokohama F2F

<TomRutt> Narita express runs every 1/2 hour or so

Agenda item 3, last meeting minutes

Oct 17 minutes approved without objection

Action item review

i059

<mnot> i059 proposal: http://www.w3.org/mid/[email protected]

Umit: Important requirements:
... requirements of wsdl / addressing bindings
... outlined areas not covered
... discussed addressing faults
... major issue is to get SOAP response over HTTP response
... Requiment is to get actual response over a new connection
... responses sent over the same connection if replyto: is anonymous
... response is sent over a new connection if replyto: is not anonymous
... points 5 and 6 in the proposal are not necessarily agreed to be requirements and are open to discussion
... continues to go over the requirements contained in the proposal as written
... proposal introduces a new element the "async element"

details of this new element are outlined in the proposal

Umit: New fault is introduced if an endpoint is unable to support async operation
... open issues, 5 and 6

<Zakim> hugo, you wanted to ask about extensibility

Hugo: Asked if async is tied to use of the SOAP binding, is it that specific and was that intended?

Umit: problem was kicked around for some tme, and there was no intent to "re-write wsdl". Her observation is that the proposal discussed the specific need to address SOAP over http

Paco: Yes, it may be appropriate to come to a specific solution, but there is need to separate issues for clarity of discussion

Jonathan: question concerning requirement 7 and how it mapps to the proposal

Umit: that requirement (number 7) is not fulfilled by the proposal
... other requirements not met are the "always async" requirement (5) and the rpc style of use (6)

Glen: There may be more agreement than disagrrment on some of these unmet requirements, but the group has not reached a final decision

<GlenD> er, that's not really what I said...

<GlenD> Glen: We did have substantial agreement on requirement 7, being able to express the available "response bindings". That would be easy to add to this.

thanks glen

<GlenD> np

Umit: This proposal may be simplified further should the requirements be pared down

i065

Katy: Sent out two proposals, feels that proposal 2 might impact CR status of our spec

Jonathan: Proposal 0 (status quo) would have no impact on CR

Katy: that does not provide a solution if the SOAP action does not match the wsa:Action

Jonathan: Feels that this can be closed with no action by just not dealing with the migration issue

Mnot: let it sit until the f2f or discuss on email

cr9

<mnot> http://www.w3.org/2002/ws/addr/cr-issues/#cr9

WSA Action for undefined faults

Jonathan: Original submission had a single fault mechanism, but didn't say what to do about SOAP faults
... Leaning toward proposal 3 to define a new URI for dealing with SOAP faults

Jonathan/Mnot: feels that change would not be substantive especially with the use of MAY

Jonathan: goal is to define one action for SOAP faults so that developer has a clear answer

Anish: What would happen if we defined a default action value?

Jonathan: This was done just for SOAP, not clear what to do about other bindings

<dhull> +1 to reserving but not mandating

<scribe> ACTION: Jonathan to develop a more detailed proposal [recorded in http://www.w3.org/2005/10/24-ws-addr-minutes.html#action01]

<PaulKnight> +1 to Paco

Hugo: voices weak lack of support for proposal 1, but would not hold his breath and turn blue if it were adopted

CR testing report

Paul: not a lot of new status, some work on the quality of the test cases we have
... There is not complete test coverage now, but there is significant coverage and feels that they are doing quite well

<scribe> ACTION: Paul and Glen send times to mnot for times for a test team call [recorded in http://www.w3.org/2005/10/24-ws-addr-minutes.html#action02]

David: Is looking for more detail that would describe what was looking for what when
... would be nice to have more explanatory material describing the test senarios

Paul: clarifies that all tests are observed on the wire

David: I am concerned that we have missed something
... A standard test harness would be useful, and expands on his extended thoughts of testing

MNot: We can get through CR with manual test cases although automation would be good for the community, just don't focus on infrastructure at the expense of tests

David: No, I am not talking about tool creation, I am talking about defining the tests and success/failure criteria

Paul: Defends tests by stating that each test is linked to a specific request and response

David: Clarifies by asking for as much specificity as possible

MNot: will try to schedule a meeting for more detailed and in-depth discussion on testing perhaps this Wednesday
... New W3C process requires a heartbeat publication each three months, that will be discussed at futre time

Meeting ajourns at 17:11 EDT