Web Services Addresing WG face to face meeting
3 Mar 2006


See also: IRC log


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




<scribe> scribe:TRutt

<scribe> scribe:TRutt


Jonathan stated that Microsoft has already implemented several of the FaultCodes that we agreed to eliminate on Thursday.

We agreed to put back DestUnreachable, ActionNotSupported, and EndpointNotAvailable

Katy asked if these had to be implemented to claim conformance

Bob F stated that they do not have a MUST constraint anywhere in the spec,

David: Implementation of these faults are optional (for the last three we are adding back in)

Agreed to add this note to the descriptions of each of these three faults

RESOLUTION: Insert after the description of "destination unreachable" action not supported" and endpoint not availalble, the following: "implementation of this fault is optional."

Interop Testing Report

<Jonathan> http://www.w3.org/2002/ws/addr/testsuite/report/

Paul: we lost the asynchronous tests from SUN. The test implementations need more work.

<pauld> as does the report

<pauld> and collection of logs which are dip feeding in from various sources asynchronously

Jonathan: microsoft/IBM and IBM/microsoft, IBM/IBM, and microsoft/Microsoft are all OK.

Marc H: there could be a problem with the logs, our developers state the implementation is correct.

Paul: we could have problems with collecting the logs, or with generation of the report. Some of the "green" boxes could be wrongly idenfitied as well.

Jonathan: I do not think we have fundamental issues.
... the biggest risk is that we do not have 4 complete implemenations.

Glen: once we fix some of the AXIS problems, that could be fixed.

Paul: we might have 5 implementations, but some of the features may have a different set of 4 implementations.

Bob F: are there any changes which need to be made to the spec.

Paul: I do believe we have found the problems in the text already, and we have already reported those to the group.

Bob F: what remains is documentation of 4 interoperating implemtations for all of the test cases.

Bob F: would be good to have the test documentation completed by March 13 WG teleconf.

Hugo: intention to go to PR from the WG on March 13.

Closure of remaining CR Issues

<Zakim> Jonathan, you wanted to close with no action

Bob F stated that the at risk feature for wsa:from has been stated by several groups as a feature that they have a use case for.

Paul D: none of the implementations have used this feature.

Paul D: My statement is incorrect. there are implementations which send wsa:From. We could add one test case to show that implemtatations can deal with it.

Marc G: since its optional we need two implementations to send it.

<pauld> notes that a test case could be 'don't bail on reception of a message with wsa:From' and then make sure three others interop with WSO2

Umit: I recommend that we close this issue with no change. Even though there is no explicit fallback to use of wsa:from in the behaviour text for replies, some users have found a reason to use this.

<bob> scribenick: TRutt

Jonathan: the spec has the field, but does not say what to do.

RESOLUTION: agreed to remove the "at risk" note from the CR text, and close the features at risk issue.

Glen stated that the axis implementation can generate the wsa:from element, and can do so for testing purposes.

Hugo: we should ensure that the complete implementations can all receive messages with all the optional features.

Paul D: we should add a test case which has wsa:from with mustUnderstand=true.

Hugo took the action to add the new test case for wsa:from generation with mustUnderstand=true


Bob F: this is a posponed issue on [Details] for wsa:ActionMismatch Subsubcode)

Dave H: add text to section 2.4 of soap binding- "This invalid addressing header fault MUST/SHOULD contain a problem action fault detail.

Jonathan: I do not think we need to do this, given the existing text.

RESOLUTION: agreed to close CR2 with no action.


<dhull> http://lists.w3.org/Archives/Public/public-ws-addressing-comments/2006Feb/0000.html

<bob> This will be cr25

tile of issue Use SOAP 1.2 properties where possible in describing SOAP 1.2 behavior.

There were no objections to accepting the proposal, as an editorial change

RESOLUTION: accept D Hull proposal for CR25 as editorial change

Resolution challenge for CR3

John Kemp sent concern in email http://lists.w3.org/Archives/Public/public-ws-addressing-comments/2005Sep/0002

Discussion led to conclusion that the original resolution was still acceptable to WG

Jonathan: we can point to the existence of xml:id.
... there is no local id attribute because xml:id exists.

RESOLUTION: Editor will provide additional text pointing to existence of xml:id

Bob F: we need to have someone give a response to John Kemp

Jonathan took action to prepare response to John Kemp on our reconsideration of CR3

Additional issues on Core

Bob F asked if there are any additional issues on the Core spec.

There were no further issues identified.

Bob F: since we have no further issues, we have to produce the final version of the docs to review, and recommend for progression to PR.

Glen: when will the formal objections be reviewed and resolved.

Mark N: the director has seen the formal objections, and has not sent feedback to the WG.

Glen: what message did he send.

Marc N: the messages was "yes you can go to CR"

Hugo: until we are in recommendation, the director can say we have to resolve a particular formal objection. Officially we have to wait to see if he will assert on these objections, which he has already seen.


Bob F asked if any companies change their allignment with either of the formal objections. No company wished to change their alignment.

Bob F asked the editors when they will have documents incorporating all resolutions.

Marc H stated the documents would be ready by the end of the day.

Bob F: I ask all members to review and send any coments before March 13. The intent is to vote to progress to PR at the March 13 meeting.

Hugo: we should publish the soap 1.1 note at the same time as the PR.

Bob F: Hugo will schedule a call with the Director after we vote to go to PR. The PR should be availalbe by the end of March, give a WG decision on March 13.

WSDL Doc Last Call issue LC109


D hull: you can leave the faultTo empty if you have a replyTo present.

Marc H: we need to clarify "either this or that"

Katy: the fault endpoint may be able to be derived by different means than presence in the request

discussion ensued on table 5-5

Marc H : suggest comgining reply endpoint and fault endpoint rows.

Dave H: for Table 5.5, and Table 5.7 , and Table 5.2, we can change entroy for fault endpoint to Y with asterisk, with asterisk pointing to reference to section 3 of core.

Anish: I prefer the merger of the two rows into "response endpoint".

Call attention to section 3.4 of core regarding the fault endpoint semantics.

Umit: I would rather not combine the two rows, I prefer Dave H proposal.

Jonathan: concensus that one of reply endpoint or reply endpoint properties should appear in table 5.5.

<TonyR> a/reply endpoint or fault/reply endpoint or fault/

<umit> i would really like an example just like Anish. Combination of the specs need to be illustrated.

Dave H: it should be clarified that for robust in only the fault endpoint defaults to the reply endpoint.

RESOLUTION: LC109 - at least one of reply endpoint or fault endpoint properties should appear in table 5.5, with some indication of the co-constraints in the core spec

LC110 Should [fault endpoint] be prohibited in Robust in-only fault messages?

Jonathan: this applies to table 5.6 and 5.8.

Marc: table 5.6 was the first place it applied.

Anish: what is good for reply is good for fault. We should not prohibit.

Marc H: you canot give a fault to a fault message in soap.

Tony R: all fault messages should have this note, not just the robust meps.

Dave H stated that we should not prohibit a fault to a fault.

<dhull> Just wondering whether it's our job to try to prohibit fault to a fault

Tony R: in 5.2.3 we do not distinguish fault.

Marc H: that is because it is an out.

RESOLUTION: LC110 agreed to be closed with no action.

LC111 Section 3.1.1 clarity

Bob F: this came from the WSDL 2 group.

Hugo: the proposal is " Section 3.1.1 says:

A property of the binding or endpoint named {addressing required}

of type xs:boolean

should be phrased:

A property {addressing required} of type xs:boolean, to the

Binding and Endpoint components

Marc H: typically you put it on one place or another, not both

RESOLUTION: LC111 resolved by accepting Hugo proposal

LC112 Three states in two

Hugo: we need to enable three cases. So, it should be made clear that {addressing required} is an optional property, whose value is "true" if wsaw:UsingAddressing is present and wsdl:required="true" is present, "false" if wsaw:UsingAddressing is present by wsdl:required is not equal to "true", and not present otherwise.

Marc H: you either do or do not support addressing

Tony R: addressing required is a mandatory boolean property.

Anish: supported but not required forces a false value for "addressing required".

Glen: we could have values "none" , required, and optional
... having two values "required" and "optional" for this attribute.

Jonathan summarized on the whiteboard what we have today.

Jonathan: if using is on binding ti goes to both binding and endpoint. If using is on endpoint, it does not go to binding.

Anish: I like having the values "required" and "optional" string enumerations.

Jonathan: we need to clarify 3.1.1 to say what we want. I do not like calling these "required" properties. if the existence of the property depends on the syntax of "using addressing"

Tony: could be change "required" propety to "mandatory" property.

Jonathan: exisence of using addressing on binding results in the required attribute to be true in binding.

Anish: I do not understand what required means in this context.

Katy: I challenge our earlier decision to put using addressing on endpoint

<uyalcina> +1 to Katy

<anish> i see the following columns for the table: 1) what's in the syntax, 2) does the processor recognize the extension, 3) wsdl:required value, 4) property present in the component model 5) value of the property in the component

Jonathan: we can restrict the rules for bindings to be separate as for endpoint.

Anish proposed a table with 5 columns to express the semantics of using addressing to components.

Jonathan: we need to remove the word required in the text, and to have a link from binding using addressing to binding component, and another link form endpoint using addressing to endpoint component.

Group broke for lunch, to think about proper resolution for this lc issue

<Jonathan> Scribe: Jonathan

Doc status update

Marc has checked in draft PR docs.

Hugo will send a link to the snapshot to the WG.

lc112 continued

Bob: before lunch, Anish was thinking of a table. Jonathan was talking about a list of actions to resolve this issue.

Jonathan: Proposal:
... Section 3.1.1: remove the word REQUIRED.
... Describe that UsingAddressing on Binding annotates Binding component,
... Describe that UsingAddressing on Endpoint annotates Endpoint component,
... Possibly note that both values must be considered to determine whether Addressing is required for a particular message.

Anish: wsdl:required should not be used directly as the value of the property.
... Might want a different value set for the property.

Glen: Would be nicer if the property existed or not, and then a separate property for the value.
... If wsdl:required=true the value should be "required", if wsdl:required=false or not there, the value should be "optional".

Tony: I like "addressing support" with the possible values of "required", "optional", "not known"/"not supported"

Anish: If the sytnax doesn't exist, you can still add the property.
... The processor doesn't understand addressing, it won't be a property in the component model.

Jonathan: Be clear on component model - it's subtle.

Anish: Just change the naming of the property.

Bob: Regardless of the name, we have relationships. We need first to get relationship.

Tony: Want to allow the property appear even when there is no UsingAddressing extension.

Marc: Strange since you're telling people about yourself.

Tony: Want the third property to encompass that there is no addressing support here.
... Not happy that absence implies it's supported.
... How can I describe the service as not supporting addressing?>

Anish: We don't have such a marker.

Katy: Send a mustUnderstand="1" and get an error back.

<marc> can't imagine a service ever saying wsa:addressing_support="unknown"

Tony: Thought that was what the tri-state is about.

Marc: It really only has two states. You either require it, or you don't.

Glen: It says, I support, or you have to use.

Marc: You don't have to tell I support. No new information provided.

Anish: We have three states in the value.
... and presence.

marc: But if it's not present, it's not telling you that the service requires addressing.

Anish: Maybe the service isn't telling you but it is still required.,

(don't go there)

Glen: Difference between supported and required, and no indication.
... If you understand addressing, you've gotta do it.

Marc: from the services perspective, you say UA=true when it's required.
... when it's not, you put it in or not.
... doesn't matter which.

Glen: How does that map to component model properties? Should be this addressing use property.

Anish: If you require addressing, you must put UsingAddressing in the WSDL?

Marc: Not that far, just if you require it and you want an interoperable mechanism, use this one.

Umit: Provision in WSDL for this marker. We went through this well in WSDL.

Marc: My proposal is equivalent to {prop}="true" or not there. "false" doesn't give you any other information.

Glen: "false" tells you that you understood the marker at least.
... If you don't support WS-A in the syntax, you shouldn't support it in the component model.

Jonathan: Thinks there is a difference. "False" means you can send the headers with mu and not expect a fault.

Glen: If you see this at the WSDL processing time, I will know whether I can send those headers or not. I might want to fault if the service doesn't delcare support for WS-A.
... Tricky case is the optional one. We're overloading the marker to mean "process the WSDL" and "allows WS-A".
... Once its in the component model, you're supposed to use WS-A at that point.

Tony: wsdl:required is different than addressing required.

Glen: Those concepts do get confused, both in SOAP and WSDL. We've been trying to overload that.

<Zakim> anish, you wanted to ask marc how his view would look like in terms of the component model

Jonathan: Believe they collapse in practice.

Anish: Spec says if you put an annotation in and say wsdl:required, it may change the meaning of the element to which it's attached.
... The qname we've defined means that you have to use addressing if required=true.
... We define the meaning of the QName.

Glen: It says the meaning of [parent] might change when you understand [extension].
... in practice it works out Ok. It's your choice to "understand" or not.

Anish: Can you translate how that translates to the component model.

Marc: Not up on cm speak.

Glen: If you don't understand the element you can't annotate the cm.

Umit: Provider puts the extension in. Client's perspective it contributes to the component model.

Glen: Choices are: understand the required extension or fault.

<anish> it turns out that it is not us who are getting confused about overloading wsdl:required. The wsdl spec says the following:

<anish> "A key purpose of an extension is to formally indicate (i.e., in a machine-processable way) that a particular feature or convention is supported or required."

<Zakim> marc, you wanted to talk about table 3.1

(scribe loses a bit)

Marc: I'm willing to change my position. Spec says there are different requirements on an endpoint depending on whether they've put this in the WSDL or not.
... Table 3-1. Key difference is MAPs in input message.
... If you put it in, you have to accept addressing headers.
... Component model does need to reflect tri-state.

Bob: Tri-state issue, seems discussion revolves around whether this.

Katy: Required/supported/not-known are the states in the table.

Glen: This is a problem with WSDL, I don't know what properties there are, what good does an abstract model do?

Jonathan: That's taken care of us by WSDL - read the Extensions part.

Bob: What's the proposal then?

Jonathan repeats. Essentially asking for a mapping of XML to component model.

Hugo: I proposed a mapping originally, Marc said it duplicated a lot of things.
... Group said we can keep what we have.

Jonathan: Asserts that failed to be clear enough.
... Would like to follow WSDL's style.

Bob: Fundamental objections?

Glen: Takes the WSDL required value rather than a different value.

Anish: Call it {addressing} = "required
... " / "optional"

Glen: call it {using addressing}

Jonathan: Proposal:

<Jonathan> ... Section 3.1.1: remove the word REQUIRED.

scribe: Add mapping of XML to component model
... Possibly note that both properties must be consulted.
... Change property name to {addressing}, values "required" / "optional"

Glen: Namespace properties?

Jonathan: Didn't namespace the core WSDL properties. No framework for doing that.

Bob: Accept the proposal?

Katy: Looking at 3.2.1, might be impacts there.

Marc: Needs more editorial direction.

Hugo: I'll draft some text.

<scribe> ACTION: Hugo to draft mapping to CM of UsingAddressing. [recorded in http://www.w3.org/2006/03/03-ws-addr-minutes.html#action01]

RESOLUTION: Proposal (see above) accepted as resolution of lc112.
... and equivalent editorial changes to 3.2.1.

ACTION 1=Hugo to draft mapping of CM to UsingAddressing and Anonymous

lc113 Section 3.3. clarity

ACTION 1=Hugo to draft mapping of CM to UsingAddressing and Anonymous, and Action


Hugo: This section should be translated into WSDL 2.0 lingo (CM instead of XML)
... Also not too clear on where it is allowed, have to chase references to intersect where UsingAddressing and soap:module are both allowed.
... We should do the math for our readers. The intersection is the Binding component.

Glen: Not on endpoint?
... Didn't we fix that at some point?

Hugo checks.

Glen: Need separate bindings for differnet module combinations? Too bad.

Bob: Objections?

Umit: UsingAddressing and soap:module have different expressive powers?

Glen: Researching a WSDL issue, we need soap:module at endpoint level.

Umit: Doesn't like this at the endpoint. Would rather we removed UsingAddressing at the endpoint.

Bob: Proposal acceptable as it stands?

Umit: Need to check editorially that we don't imply UA and module are equivalent.

Glen: Equivalent semantics, but not equivalent places you can put it.

RESOLUTION: lc113 closed by accepting Hugo's proposal
... plus editorial check that we don't imply UA and module are completely equivalent.

lc114 Typos

RESOLUTION: Fix typos.
... lc114 closed by fixing typos.


RESOLUTION: lc115 closed by accepting fix.

lc116 use of wsa:ReferenceParameters

Bob: Doesn't say how this extension affects the WSDL 2.0 CM.

Jonathan: Let's do it.
... property is a list of elements.

Anish: What about attributes on the wsa:ReferenceParameters element? Are they lost?
... Isn't there a type for reference parameters already?
... So use the same type as the [reference parameters] property in 2.1 of Core.

Umit: We discussed it, we just forgot?

Proposal: Add a {reference parameters} property to the WSDL 2.0 component model, with the same type as the [reference parameters] property in Core 2.1

RESOLUTION: lc116 closed with proposal above.

Future meetings.

Bob: Call on the 13th is the last opportunity to touch the document. Our fundamental reason for the call is to pass the document off. The meeting will last as long as it takes.

Jonathan: suggests we require any comments to be accompanied with a complete and detailed proposal.

<pauld> +1 to Jonathan

RESOLUTION: Comments must be accompanied with a detailed proposal.

Anish: Once it goes to PR it's out of our hands.

Hugo: It's in my hands, so small changes (e.g. editorial) can be made as a result of AC or other comments.

Bob: Would like to hear from the test group after the meeting on tuesday, if there are issues that mean we'll slip the date we'll have to reschedule.
... No reason to hold the 8th call - cancelled.
... FTF in Cambridge, MA for May 4-5(?) by IBM.
... Pencil in the FTF.

Jonathan: Thinks we'll need it.

Bob: Don't buy tickets quite yet though.
... This is your 8 week notice of the FTF. Possibility it might be cancelled though.


Summary of Action Items

[NEW] ACTION: Hugo to draft mapping to CM of UsingAddressing. [recorded in http://www.w3.org/2006/03/03-ws-addr-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/03/09 09:00:36 $