Web Services Addressing Working Group Teleconference

12 Sep 2005


See also: IRC log


Abbie Barbir (Nortel Networks)
Rebecca Bergersen (IONA Technologies, Inc.)
Andreas Bjärlestam (ERICSSON)
Francisco Curbera (IBM Corporation)
Glen Daniels (Sonic Software)
Vikas Deolaliker (Sonoa Systems, Inc.)
Paul Downey (BT)
Michael Eder (Nokia)
Robert Freund (Hitachi, Ltd.)
Arun Gupta (Sun Microsystems, Inc.)
Hugo Haas (W3C)
Marc Hadley (Sun Microsystems, Inc.)
David Hull (TIBCO Software, Inc.)
Yin-Leng Husband (HP)
Anish Karmarkar (Oracle Corporation)
Paul Knight (Nortel Networks)
Mark Little (Arjuna Technologies Ltd.)
Jonathan Marsh (Microsoft Corporation)
Jeff Mischkinsky (Oracle Corporation)
Nilo Mitra (ERICSSON)
David Orchard (BEA Systems, Inc.)
Mark Peel (Novell, Inc.)
Gilbert Pilz (BEA Systems, Inc.)
Tony Rogers (Computer Associates)
Steve Vinoski (IONA Technologies, Inc.)
Katy Warr (IBM Corporation)
Pete Wenzel (SeeBeyond Technology Corporation)
Steve Winkler (SAP AG)
Ümit Yalçınalp (SAP AG)
Prasad Yendluri (webMethods, Inc.)
Ugo Corda (SeeBeyond Technology Corporation)
Dave Chappell (Sonic Software)
Jacques Durand (Fujitsu Limited)
Marc Goodner (Microsoft Corporation)
Amelia Lewis (TIBCO Software, Inc.)
Philippe Le Hégaret (W3C)
Eisaku Nishiyama (Hitachi, Ltd.)
Ales Novy (Systinet Inc.)
Tom Rutt (Fujitsu Limited)
Rich Salz (DataPower Technology, Inc.)
Jiri Tejkl (Systinet Inc.)
Mike Vernal (Microsoft Corporation)
Mark Nottingham
Jonathan Marsh


Agenda review

<scribe> Agenda: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0009.html

no changes or other business

Minutes approval 29 August.

RESOLUTION: Minutes approved as sent

AI review

2005-07-25: Paul Downey to generate list of features, their

requirement level and applicability for discussion

<scribe> : DROPPED

Arun's material appears sufficient.

DHull review: DONE

MarcG review: DONE


Marsh AI: DONE


All done but Katy's...

Namespace change policy

Mark: Hugo suggested it would be good to write down a policy

Hugo: I wrote a doc.

<hugo> Draft I did: http://www.w3.org/2002/ws/addr/5/08/29-ns-policy.html

Hugo: For each draft we have set a new namespace, with the form w3.org/year/month/identifier
... we have been updating the namespace each publication.
... We haven't agreed on how to change this from now on.
... Before we reach CR, we replace the namespace each time. When we reach CR, we only update if there is a significant change is made.
... WHat is a significant change?
... Up to the WG in each case.

Chorus: Seems sensible.

Mark: Philippe said it might be good to document this at the end of the NS URI.

Hugo: Only problem is that the policy is only visible when dereferencing the namespace URI.
... We should also put it in the status section of the doc.
... I'm very flexible.
... Good to see when people read the draft.

Mark: Can we get a paragraph to paste into the spec and the RDDL?

Hugo: Do you want to include the appropriate section from my doc?

Mark: Yes, not too heavyweight.

Nilo: CR says the URI only changes with significant changes. Hugo's proposal says the opposite.
... Seems we need to remove the "NOT"s

<mnot> From Section 2.2: After a document has been published as a Candidate Recommendation, the namespace IRIs will be updated only if changes are made to the document are not significant and do not impact the implementation of the specification.

<uyalcina> +1 to Nilo

Hugo: Ah, I see! To many negatives...
... needs to be fixed. "are significant and impact ..."

Mark: After we get to CR, we will attempt to keep the URI the same.
... OK?

<scribe> ACTION: Editors to incorporate this into the document and the RDDL. [recorded in http://www.w3.org/2005/09/12-ws-addr-minutes.html#action01]

<Nilo> After a document has been published as a Candidate Recommendation, the namespace IRIs will be updated only if changes made to the document are significant and impact the implementation of the specification.

Mark: Only 2.2 applies to the CR docs, section 2.1 applies to the WSDL doc.

[general agreement]

WSDL 2.0 review

Mark: We have 3 of 4 AIs done. Let's walk through them.

<gpilz> anyone know what the address of this server is?

<mnot> http://www.w3.org/mid/7997F38251504E43B38435DAF917887F40C6B7@ausyms23.ca.com

Mark: Tony's review on the Primer

<gpilz> I meant the direct IRC address

Tony: saw a number of typos.

<marc> ACTION 1=Editors to incorporate ns update policy into drafts

Tony: We aren't included in the references.
... Section 5.3 discusses endpoint references to describe the URL where the service lives.
... Could be "endpoint URL" or an "endpointer"
... A different term than "endpoint reference" would reduce confusion.

Umit: THere is a definition of endpoint reference in 5.3.

DaveH: Confusing.

<anish> WSDL has an endpoint and ws-addr has an endpoint and they are quite different

Umit: If there is a different term, would that solve the problem?

Glen: Just the term, I believe.

DaveH: Partly the term, partly two parallel universes.
... One where you refer with a URI, one with an EPR. Took a couple of readings to figure out what was going on.

Glen: the third universe is the syntactical constructs, they may contain policy etc.
... the "endpoint" construct in WSDL.

Tony: 5.3 comes right after 5.2 which makes reference to WS-A, already given people a defn of endpoint reference there (implicitly).
... Different term would avoid confusion.

Umit: Definitions in Core and 5.3, and 5.2 introducing concepts in wrong order (possibly).

Mark: Happy to send Tony's comments to WSDL?

[apparently so]

Mark: Dave's comments

<mnot> David Hull's comments on the Core: http://www.w3.org/mid/4323BB97.3030801@tibco.com

<scribe> [postponed temporarily]

Mark: Marc Goodner's comments:
... typos


scribe: points out some relevant sections of the spec, but don't appear to be issues.

<mnot> WSDL Adjuncts Section 2.2:

<mnot> WSDL patterns specify propagation of faults, not their generation. Nodes which generate a fault MUST attempt to propagate the faults in accordance with the governing ruleset, but it is understood that any delivery of a network message is best effort, not guaranteed. The rulesets establish the direction of the fault message and the fault recipient, they do not provide reliability or other delivery guarantees. When a fault is generated, the generating node MUST atte

<mnot> the fault, and MUST do so in the direction and to the recipient specified by the ruleset. However, extensions or binding extensions MAY modify these rulesets. For example, WS-Addressing [WSA 1.0 Core] defines a "FaultTo" address for messages, which is used in lieu of the recipient nominated by the ruleset.

Mark: That seems fine.

<mnot> http://www.w3.org/TR/2005/WD-wsdl20-adjuncts-20050803/#soap-operation-decl

Mark: SOAP Action Feature doesn't mention WSA Action - oversight?
... thoughts?

Marsh: What would WSDL say?

Mark: Might say "there are other specs out there..."
... Let's defer these till next week.
... when Katy's got her review done.
... And forward the typos.

DaveH: Except for 3.3, most of the COre is too generic to be of concern to us.
... In 3.3, wsdlx:interface and wsdlx:binding are defined.
... Need to clarify endpoint references as applied to URIs.
... By tagging it the semantics of "this is a reference to an endpoint" are applied.
... It's nice, e.g. WSN, to say that an EPR is a particular type.

Marsh: Interesting it wasn't clear to you that you can use these for wsa:EPRs.

DaveH: Wasn't clear - should make it more explicit.
... Nice to hang it off an element declaration instead of just a type.
... Seems lighter weight than deriving a new type.
... Don't think anything would preclude that design. The examples in the primer tend towards extending a type nor an element.
... A use case was what is in the data vs. a schema.
... Could include wsdlx:interface in an EPR.
... Is that what WSDL wanted?

Umit: Is there a problem in the Core (3.3), it says that that are AIIs in wsdlx, and a comment about how these can be used together, and how they are applied to xs:anyURI.
... No restriction against using them with wsa:EPRs. Are you saying there should be used on wsa:EPRs? and an example?

DaveH: Says these annotate anyURIs or restrictions thereof, which sounds exclusive.

Umit: That wasn't the intent. Add more text making it clear it can be used on EPRs too?

Dave: "xs:anyURI" -> "xs:anyURI and wsa:EPR" or just drop xs:anyURI and talk about elements.
... even adding "such as" would have helped.

Marsh: Intention was to provide description level constructs to complement wsa:Metadata/wsaw:ServiceName, etc.

Dave: Was the intention to allow on element decls as well as types?

Marsh/Umit: Don't remember.

Dave: Other than this, core looks good.


1) Clarify wsdlx: can apply to EPRs, not just xs:anyURI.

2) Can wsdlx: be applied to element decls, not just types?

<scribe> ACTION: DaveH to revise his comments on WSDL 2.0 3.3, by 9/19 [recorded in http://www.w3.org/2005/09/12-ws-addr-minutes.html#action02]

i061 - Action without UsingAddressing

<mnot> http://www.w3.org/mid/7DA77BF2392448449D094BCEF67569A508D098E9@RED-MSG-30.redmond.corp.microsoft.com

<GlenD> +1

Marsh: Goes through his posting.

<Zakim> marc, you wanted to ask a question on wsdl:required=false case

Arun: We should add some of this to the spec.

Marc: wsdl:required="false" allows a service to send headers without receiving them from the client.
... That seems bad.
... You could send me a message with a messageID, expecting a relatesTo, but you won't get it, which is bad.

Marsh: We could define that behavior - separate issue.

Umit: Bottom line: wsas:Action can't force behavior without wsa:UsingAddressing.

Anish: you say a client MAY engage wsaw:Action when wsdl:required="false", but not pick and choose the rest of the WS-A features.
... WHen the client uses WS-A it must engage it fully as we spec.

Marsh: Useful to clarify that.

<Gil> get the video!


1) in case 2, if wsa headers are sent, they must be responded to by the service.

2) in case 2, client either chooses to honor Addressing, or not to include any wsa headers (whole enchilada)

3) in case 3, wsaw:Action is informational.

Clarify these three items.

<mnot> [numbered bullets are additions to 3' proposal in Jonathan's e-mail]


"informational/advisory" should say "no normative intent".

Marsh: you can't ignore it in all cases (out of band may make use of it).

Mark: Everyone comfortable with this?

[seem so]

scribe: Can we send this off to the editors?

Marc: Would like some text.

<scribe> ACTION: Paco to come up with wording to implement i061 based on the above discussion. [recorded in http://www.w3.org/2005/09/12-ws-addr-minutes.html#action03]

i056 Determining the value of destination from WSDL.

<anish> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Apr/0062

Mark: Marc's link is the proposal on the table.
... everyone comfortable at this point?

Umit: looks reasonable, except for one thing.
... "if there is no wsa:EndpointReference..." what does it mean that there is an anonymous URI for the destination?

Marc: IIRC, the anonymous means "do what the transport says".
... we define HTTP response.

Umit: For destination what does that mean?
... for SOAP/HTTP.

<vikas> Every binding has its own "understanding" of what is anonymous URI

Marc: Conclude it's bad WSDL at that point.

Umit: Maybe the fourth rule shouldn't apply then.

Mark: Are there other bindings where that would have utility?

Umit: Unless there were a catalog or config file to map anonymous.
... Not very interoperable.

Marsh: What's the alternative?

Anish: If you wanted to support a way to have this defined elsewhere, we should call it "undefined".
... IF a binding could define what anonymous means it would be useful, but I can't think of such a binding.
... Maybe a separate issue: we require a destination to be anonymous, which is delegated to the binding. In the SOAP binding we define what it means for replyTO and faultTo, but not destination.

Mark: We could change the fourth bullet to say "it's undefined", or define what anonymous means for destination.

Umit: We need to define anonymous for [destination] in any case.

Anish: If wsa:To is missing destination is anonymous already. Is #4 adding anything?

Marc: Mixing up the value of wsa:To and the value of the property.

Anish: Proposal is if no values are specified you use anonymous. Similar with wsa:To.

Marc: Doesn't interfere with it, just conveys it.

Umit: In the end, what is the address on the wire?

Marc: If you're sending a message to anonymous, you can omit the wsa:To header or put in the anonymous value.

Umit: The relation of the HTTP address and the anonymous URI needs to be clarified somewhere.

Marc: We only define one case where anonymous has a meaning - HTTP back-channel.

Mark: What are you recommending?
... that people avoid anonymous for destination?

Umit: Not sure what the solution is.
... Maybe clarify where anonymous doesn't make sense.

Mark: So should we change or remove the 4th bullet?

Marc: Don't think we fix anything by removing the default.

Paco: This is a hole in WSDL we're trying to fix.
... If you have a WSDL with no address, we're providing an interpretation for that case.
... Can we derive the value of [destination] from WSDL? When the WSDL author doesn't provide one, we'll provide one.
... Is that the wisest thing to do?

Anish: In the proposal, the EPR is included as a child of wsdl:endpoint or wsdl11:port. DOes that mean the EPR applies only to the in messages for that endpoint/port?
... What happens when it's specified for a port with only an out message?
... Need to be more specific on which messages the embedded EPR applies to.
... requires more thought.
... Specifically a problem with the first "in" message, but might be others.

Umit: The reason you don't have an address in teh port (WSDL perspective) is that the address is added at deployment.
... Might not be safe to assume there is an anonymous destination.
... Addresses might be provided at a later time.

Marc: Why would you have an EPR at a later time.
... OK, maybe so.

<scribe> ACTION: Anish to explore the issue of application to messages other than the first "in". [recorded in http://www.w3.org/2005/09/12-ws-addr-minutes.html#action04]

<scribe> ACTION: Umit explore the issues surrounding bullet 4 for next week. [recorded in http://www.w3.org/2005/09/12-ws-addr-minutes.html#action05]

Mark: i056 to email.

i059 support for async

Mark: Delegated to the Async TF.
... At this point it seems the TF is running out of steam a bit. Good time to bring it back into the WG.
... Need to wrap this up to get the doc into CR.
... Glen will write up a summary, esp. of the decisions to be made, different proposals for solving them.
... Please look for it.
... Will reserve a chunk of the FTF to talk about this issue. If you have a proposal get it in by then.
... Number of ways to address the issue, but we need to see which fit within our deliverables and our charter requirements.

i020 Addressing and WSDL.

Mark: Revised proposal from Anish.

<stevewinkler> glen, I'll send my regrets for wed now, I'm on the road...

<mnot> http://www.w3.org/mid/4325D89F.2070005@oracle.com

Anish: Logical/physical address
... There was the potential for a physical and logical address.
... The proposal had three parts, part 2 and 3 defined the relation of physical and logical.
... those have gone away. Part 1 uses updated terminology.
... Proposal:

When the EPR minter includes a [selected port type], and/or [service-port] then the EPR is considered to be specific to the [selected port type] and/or [service-port]

Marsh: The spec doesn't say this yet?

Anish: No, not that I could see.

Umit: No we don't say that anywhere. Although it seems obvious, it's not explicitly stated anywhere.

Paco: Makes sense.

<uyalcina> +1 for the proposal

Mark: Any objections to the proposal?

Vikas: Doesn't resolve the logical and physical.

Mark: We resolved a while ago we wouldn't talk about that.

<mnot> Subissue c: An EPR allows one to include (optionally) a service endpoint/port. If such an endpoint/port is included in an EPR, what is the relationship between the value of the [address] property and the URI value in the [service-port] property? We have said that the [address] property is a logical address and not necessarily the physical endpoint where messages can be sent and how the mapping between logical to physical takes place is an extensibility point. Is t

<mnot> vice QName is present in the EPR. I.e., should our spec say that if the service QName is present then the physical address is what is specified by the wsdl port.

Anish: WSDL never says the port address is any more physical than the WS-A address. THey are all IRIs and that's that.

Vikas: Maybe we should rewrite the issue to get rid of the logical/physical confusion.

Umit: Does Anish's proposal make sense on it's own right or not.

Vikas: If the issue is cloudiness about physical/logical, the proposal doesn't address it.

Mark: Should we delete everything but the second sentence of the issue?

Anish: We can point to i052, say the questions about logical/physical are addressed there.

Mark: Proposed resolution: Anish's proposal, plus a ref to the resolution of 052.
... Everyone comfortable?

Vikas: i052 resolution: remove "logical" when talking about addresses.

[silent assent]

RESOLUTION: i020 closed with Anish's proposal.

2:51PM PDT, let's talk logistics

Bob: Customers have co-opted our meeting room, we've moved to a nearby building.
... Logistics coming.
... Negotiated rates available through email reservation.
... Unless you are fluent in Japanese, have an international drivers license, etc., it's maddness in the metro area to try to drive.
... Will be escorting people from the hotel to the meeting room starting on the 7th
... Trying to gauge interest in some sightseeing or entertainment.
... Just after the peak of the autumn color season, we might be able to get some rooms there Nov 5,6.
... Other details like how to buy tickets, get from the airport, etc. coming.

DaveH: How long is the Narita express?

Bob: About an hour. 12 min from hotel to meeting room; fare: 210. Narita Express fare information forthcoming.
... $125 hotel + $10.70 internet access.
... I'm translating maps from Japanese, takes a while.

Mark: Talk next week, might be absent, in which case Hugo will chair.
... Do your AIs.
... Get your potential issues in.


Summary of Action Items

[NEW] ACTION: Anish to explore the issue of application to messages other than the first "in". [recorded in http://www.w3.org/2005/09/12-ws-addr-minutes.html#action04]
[NEW] ACTION: DaveH to revise his comments on WSDL 2.0 3.3, by 9/19 [recorded in http://www.w3.org/2005/09/12-ws-addr-minutes.html#action02]
[NEW] ACTION: Editors to incorporate this into the document and the RDDL. [recorded in http://www.w3.org/2005/09/12-ws-addr-minutes.html#action01]
[NEW] ACTION: Paco to come up with wording to implement i061 based on the above discussion. [recorded in http://www.w3.org/2005/09/12-ws-addr-minutes.html#action03]
[NEW] ACTION: Umit explore the issues surrounding bullet 4 for next week. [recorded in http://www.w3.org/2005/09/12-ws-addr-minutes.html#action05]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2005/09/12 23:43:32 $