WS Addressing Working Group

31 Jul 2006

See also: IRC log


Arun Gupta (Sun Microsystems, Inc.)
David Illsley (IBM Corporation)
Anish Karmarkar (Oracle Corporation)
Paul Knight (Nortel Networks)
Amelia Lewis (TIBCO Software, Inc.)
Mark Little (JBoss Inc.)
Gilbert Pilz (BEA Systems, Inc.)
Tony Rogers (Computer Associates)
Katy Warr (IBM Corporation)
Pete Wenzel (Sun Microsystems, Inc.)
Prasad Yendluri (webMethods, Inc.)
Abbie Barbir (Nortel Networks)
Andreas Bjarlestam (ERICSSON)
Dave Chappell (Sonic Software)
Francisco Curbera (IBM Corporation)
Glen Daniels (Sonic Software)
Vikas Deolaliker (Sonoa Systems, Inc.)
Paul Downey (BT)
Jacques Durand (Fujitsu Limited)
Marc Goodner (Microsoft Corporation)
Hugo Haas (W3C)
Marc Hadley (Sun Microsystems, Inc.)
David Hull (TIBCO Software, Inc.)
Yin-Leng Husband (HP)
Philippe Le Hegaret (W3C)
Bozhong Lin (IONA Technologies, Inc.)
Jeganathan Markandu (Nortel Networks)
Jonathan Marsh (Microsoft Corporation)
Jeff Mischkinsky (Oracle Corporation)
Nilo Mitra (ERICSSON)
Eisaku Nishiyama (Hitachi, Ltd.)
David Orchard (BEA Systems, Inc.)
Alain Regnier (Ricoh Company Ltd.)
Tom Rutt (Fujitsu Limited)
Davanum Srinivas (WSO2)
Bob Freund
Amelia Lewis




<scribe> Scribe: alewis

<scribe> agenda: meeting minutes for 5 June 2006. minutes accepted without objection.

open action items include call for additional participants in testing effort.

call for additional participants; no response.

primary purpose of meeting: discuss WSDL tests so far, work done by Arun and David.

Arun: review of WSDL test work so far.

<agupta> http://www.w3.org/2002/ws/addr/testsuitewsdl/report/

URL posted just above summarizes and describes work to date, including the test design, tests themselves, and results so far, including the face to face

<agupta> http://www.w3.org/2002/ws/addr/testsuitewsdl/testcases/

Arun: expected to have fifteen to twenty test cases, but in fact have more. IBM and Sun have implementations of all test cases.
... each test case has a number, which includes target WSDL version, target SOAP version, and a sequence number. tests try to cover a variety of cases; there are short descriptions of each.
... each test should be associated with an assertion; each test is either required or optional (right now, only one is optional).
... report page includes a todo list at the top.
... describes format of table in list, results for IBM-IBM, IBM-SUN, SUN-SUN.
... discussion of action-based dispatch, tests related to that, questions arising around it.
... trouble correlating messages in some cases.
... where four white boxes appear, there are questions about the spec.
... testing raises some questions about the interactions of various properties; the behavior of the processor is not always well-defined for all cases of all combinations of properties.

David: concurs with summary.

Bob: call for questions on summary.
... issue from testing. related to SOAP Action.
... issue raised on mailing list, Jonathan may have raised about a week earlier.
... issue #26: unclear soap action.

<anish> http://www.w3.org/2002/ws/addr/cr-issues/Overview.html#cr26

Arun: concurs, this summarizes issue very well.

David: have some other stuff that need to discuss; this is not what David has had problems with.

Arun: David's issue with action-related dispatch and [scribe lost remainder]
... proposed resolution of unspecified soap action header, something on empty string.

Anish: soap action "" actually is specified. wsa:action is required to be an absolute URI; soap action is not.
... consequently, at least in the case when soap:action is specified as "", it can't be used for wsa:action.
... Arun's suggestion would solve both problems.

Arun: if wsa:action is specified, use that. If soap:action is present and is not an empty string, use that. if that doesn't exist, construct the default.

Bob: is this a new issue?

Anish: specification doesn't handle the case in which a soap:action is specified, but is not a URI.
... spec says that wsa:action and soap:action must match, but also say that wsa:action must be an absolute URI (which is not required for soap:action, even excluding the empty string case).

<agupta> http://lists.w3.org/Archives/Public/public-ws-addressing/2006Jul/0000.html

Arun: three issues: existing cr26, the case Anish seems to be raising, and [??]
... what is meant by specified soap:action? empty string could be considered to be "specified", but should not be included.

David: if soap:action is empty string, then use the default pattern. need to clarify text to match this expectation.

Bob: opening new issue, cr28, to deal with Arun's issue and the proposed resolution from the email referenced above.

Paul: support resolution.

Bob: call for specific text. Arun: will post. Bob: fine, let's get exact proposed replacement text.

<agupta> From section: http://www.w3.org/TR/2006/CR-ws-addr-wsdl-20060529/#explicitaction

Arun: will post existing text and proposed revised text.

<agupta> Current text: In the absence of a wsaw:Action attribute on a WSDL input element where a SOAPAction value is specified,

<agupta> Proposed text: In the absence of a wsaw:Action attribute on a WSDL input element where a *non empty* SOAPAction value is specified,

Bob: call for objections to accepting the proposal as resolution of cr28.

RESOLUTION: text proposed by Arun closes CR28.

addition of "non-empty" before "SOAPAction value" in 4.4.1.

Bob: David's issue. Arun: need to open Anish's issue. Bob: Anish said he will raise that issue. back to David.

<David_Illsley> http://lists.w3.org/Archives/Public/public-ws-addressing/2006Jul/0016.html

David: this is clarification of the general understanding.
... there are tests which expect that if a WSDL does not describe a wsaw:action, then an ActionNotSupportedFault is returned.
... however, the specification does not support ActionNotSupportedFault as a requirement, in David's reading.
... Arun read this differently, that the fault is required.
... spec language is pretty clear in SOAP binding; action not supported is optional. therefore it seems that it should be optional in the tests as well; Arun felt that it ought to be required.

Bob: call for objections to making tests optional. none heard.

RESOLUTION: tests in which ActionNotSupportedFault is returned are to be made optional, per David's recommendation.

<bob> Section 4.4.1 defines a mechanism to explicitly set the action value

<bob> (wsaw:Action). It says "In the absence of a wsaw:Action attribute" use

<bob> the specified SOAP action.

<bob> Section 4.4.2 defines a defaulting mechanism. It says "In the absence

<bob> of a wsaw:Action attribute" calculate the action using the algorithm

<bob> which follows.

<bob> The use of the same text ("In the absence...") for each of these

<bob> mechanisms renders it unclear whether the default action pattern or the

<bob> specified SOAP action is to take precedence. I think the intention is

<bob> clear - use wsaw:Action if present, else use specified SOAP action if

<bob> present, otherwise use the default pattern.

<bob> There appear to be a number of straightforward editorial remedies.

Bob: paste from Jonathan's email.
... call for agreement to proposal.

Tony: agreed.

Bob: mark as editorial?

paul knight: non-empty is covered?

Tony: covered in closure of earlier cr.

Bob: call for objections.

RESOLUTION: close cr26, adopting the proposal of Jonathan Marsh as offered, subject to editorial interpretation and inclusion of "non-empty".

Arun: need to deal with question of action-based dispatch, as raised by David.

Bob: if hasn't been raised in email, then hasn't got visibility.

Arun: okay, will raise the issue.

question asked: is the problem with addressing or with the WS-I BP?

Arun: yes, this is a potential interaction between WS Addressing and WS-I; wants to get a sense of how to resolve.
... but the critical part of the question is: for this test case, what is the requirement/assertion that is being tested, using action-based dispatch?

Bob: interpreted this as an understanding that there are some otherwise valid WSDL that are not accepted by the WS-I BP.

Arun: will raise to list and record as issue.

Bob: propose next meeting in two weeks.

14 August. Arun, however, proposes earlier meeting. Bob: if raised to list, will be in one week, 7 August. call for objections.

Next meeting: 7 August 2006, same bat time, same bat channel.

meeting adjourned.

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/08/04 18:16:57 $