Web Services Addressing WG Teleconference

19 Sep 2005


See also: IRC log


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.)
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)
Mark Peel (Novell, Inc.)
Gilbert Pilz (BEA Systems, Inc.)
Tony Rogers (Computer Associates)
Tom Rutt (Fujitsu Limited)
Mike Vernal (Microsoft Corporation)
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.)
Abbie Barbir (Nortel Networks)
Ugo Corda (SeeBeyond Technology Corporation)
Dave Chappell (Sonic Software)
Jacques Durand (Fujitsu Limited)
Marc Goodner (Microsoft Corporation)
Arun Gupta (Sun Microsystems, Inc.)
Amelia Lewis (TIBCO Software, Inc.)
Philippe Le Hégaret (W3C)
Eisaku Nishiyama (Hitachi, Ltd.)
Ales Novy (Systinet Inc.)
David Orchard (BEA Systems, Inc.)
Rich Salz (DataPower Technology, Inc.)
Jiri Tejkl (Systinet Inc.)
Mark Nottingham
Tom Rutt



Anish stated that xmlp requested requirements from this WG

Agree to put on agenda after wsdl coordination

Also add discussion of f2f

Next Week F2F

Dial in should be available

Hugo will send in details on Dial in for F2F

<bob> +1 for dinner

<swinkler> Nola is fine.

<GlenD> Nola's great

<uyalcina> tamarind is better

<swinkler> Tamarine is better, that's true.

<GlenD> The place with the sake bombs is fun too :)

Take Dinner arrangment to list

<swinkler> that's =myake's

Call for corrections to sep 12 minutes

No objection to posting to web site

Resolution: minutes sep 12 approved

action Items (agenda item 4)

Topic Agenda item 5 coordination

Mark N: Last week we came to conclusion about some of the comments members put together on WSDL document review.

Sent Tony comments on core

Concluded that there was not much to add to Marc G comments.

<Marsh> The comment Dave filed: http://lists.w3.org/Archives/Public/public-ws-desc-comments/2005Sep/0014.html

Dhull: Wording seemed to suggest annotations for IRIs, since it did not mention something else. I wanted the text to be clarified.

<dhull> http://www.w3.org/2002/ws/desc/5/lc-issues/issues.html#LC336

Dhull: I already submitted the comment as a last call issue

Mark N; I thought we were going to review it further, lets see if the WG agrees

Nobody objected to LC336 as comment to wsdl group

<uyalcina> I can live with it

Mark N : move on to Katy comments

Katy: First comment regarded a comma.
... on second comment about 5.10.3 -

Jonathan: this "element" should be this "global element declaration".

<uyalcina> I don't like the second sentence

Katy comments at: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0023.html

Mark N: we do not heed to produce fix, we just need to identify problem

Katy: third comment para under 5.10.3 The following sentence switches between a SOAP Header Block representing 1

header and representing multiple headers?

"A SOAP Header Block component describes an abstract piece of header data

(message headers) that is associated with the exchange of messages between

the communicating parties. The presence of a SOAP Header Block component

in a WSDL description indicates that the service supports headers and MAY

require a Web service consumer/client that interacts with the service to

use the described header. Zero or more such headers may be used."

Jonathan: this comment should be sent in.

Katy: comment 4 o Comment: How does wsoap:header indicate required = true/false?

Johathan: how does client know by reading wsdl whether it must send the header?

Katy comment 5 on section 5.10 Comment : Use of wsoap:header Element Information Items

WSDL Adjuncts Section 5.10

What is the intent of the (non-'document') element information items in the wsoap:header?

Mark N: agreed to drop this comment

Katy comment 6 o WS-Addressing WSDL spec ?

wsaw: UsingAddressing appears to be simply a shorthand for wsoap:headers.

Would it be worth us adding the semantic equivalent to

wsaw: UsingAddressing in terms of WSDL 2.0 SOAP header blocks as part of the WS-A WSDL specification?

Mark N: Katy should keep this for discussion at the Face to Face meeting.

<anish> a related question: what happens if both wsaw:Action and wsoap:header (for wsa:Action) is present and is different?

Katy: I will think about this further, and maybe will add an issue later if required, perhaps asking for a clarificaiton

Jonathan: it depends on the MEP which headers are required or optional

Mark N: we do not need to resolve this now.

Mark N: for wswd doc review we have the tony comments, all but the last two of Katy, and DHulls single comment

Mark N: any objection to sending in comments as discussed.

No objection

<scribe> ACTION: katy to send all but her last two comments [recorded in http://www.w3.org/2005/09/19-ws-addr-minutes.html#action01]

<scribe> ACTION: Tony to send his comments [recorded in http://www.w3.org/2005/09/19-ws-addr-minutes.html#action02]

Jonathan: Marc G had an editorial comment,

Marc N: those comments are not relevant to addressing

<mnot> http://www.w3.org/mid/A5F46F7A688C084782E8C52B76368613014CC5F2@sdebe101.NOE.Nokia.com

Jonathan: I will have him send these in on his own behalf

XMLP requirements from WS-addressing

Mark N: xmlp is asking us for our requirements, we discovered in the past that we could not articulate requriements unto the asynch task force was completed. After discussion next week we may be able to get back to them.

Mark N: is it reasonable to wait until after next week f2f before sending this response.

GlenD: that is what we discussed on the last asynch TF call. We are currently figuring out how to spec this.

Mark N: we need to have the WG review this document first. We have pressure to agree to something by end of next week. I will devote much of the agenda next week to this issue.

<anish> +1 to devoting significant time at the f2f for this

<anish> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0020.html

working draft issue i056

Anish: reviewed his email at http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0020.html
... after I sent this email, I am less convinced that we need to say anything.. If we understand what port and endpoing mean, wrt address of port or endpoint, then I do not think we need to say anything, We cannot change wsdl 1.1. Including epr within port is no different than soap:address within a port.

Mark N: does everone agree with anish sentement.

Mark N: hopefully we can close I056 next week.


Mark N: Last time we agreed to wait for resolution of i056 before doing this.

Agreed to discuss at meeting next week.


GlenD: The Asynch task force agreed on a few things: 1) wire level representation of use cases (one way over one way protocol, and over two way protocol ; and 2) in/out over one way and two way protocol.

Glen D: having agreement on wire level, we discussed how to do this in soap 1.2 framework for bindigns as well as wsdl 1.1 and 2.0. This is where is gets tricky. Do we build on top of those specs, or issue errata.

GlenD: agreed that when using addressing and want an asynch reply for wsdl in/out, you should be allowed to specify in wsdl the allowed bindings for the return, but the detailed changes to the specs (soap in particular) is still under discussion
... We need to go thru some questions to evaluate the various proposals.

<uyalcina> +1 to anish

Anish: we need to make paths along the decision tree that GlenD sent out.

Mark N: everone should look at the decisions and GlenD's summary of the discussions. Ask questions on the email before the meeting.


Mark N: we should wait for the outcome of Paco action item on this issue.

Candidate Recommendation Issue cr2

<mnot> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Aug/0088

Jonathan: my email http://lists.w3.org/Archives/Public/public-ws-addressing/2005Aug/0088 shows a reasonable approach to take.

Jonathan problem action overlaps with problem header

Jonathan: instead of having a problemAction, I propose we keep problemHeader, and problemHeaderQname, and use this to indicate problem in action header.
... you could also use problemSoapAction

dhull: in Boston we moved in a general dirction to trim codes, and as long as this is in the same direction I am comfortable.

Mark N: would this cause us to go back from CR and go to draft. Since we flagged this, we should not have to go back from CR

Mark N: would it cause our namespace to change?

Marc H: It would have to.

Jonathan: the scema should change.

Marc H: then we have to change the namspace.

Mark N: was that element requried before?

Marc H: is changing namespace a big issue at this CR phase?

Jonathan: if we agreed on this fix soon enough, we could have it in the spec going forwared for interop. We could process this as errata soon.

JeffM: do we need to change the namespace.

Mark N: we agreed to a namspace evolution policy last week, and after CR if at all posible we would try not to change namespace.

Anish: what is the problem with changing namespace?

Umit: if there are no implementations, why not just change it.

Anish: CR documents are not final. Things may change.

Dhull: people are referring to the CR docs.

JeffM: any reference to a spec under development is subject to changes occuring.

Jonathan: if there is no reason to change the namespace we should not. The question is whether this is a breaking change.

Marc H: removing element and adding new one is a breaking change.

Jonathan: from our point of view, we could accomodate this change at this time. However later in the CR process we would not be so flexible.

Hugo: an open source developer might implement the CR spec, and if so that would not interoperate with the final spec.

Anish: is this change important enough for a breaking change. If yes, we should change the namespace, otherwise we should look for a backward compatible change.

<pauld> wonders what the impact on publication if we do change the namespace, do we have to go back to LC?

Mark N: if this was the only breaking change, how important would it be it to do this?

Hugo: we already made a change from CR1.

Marc H: that just changed the prose, not the schema itself.

Jonathan: I agee with Marc that dropping somenting from schema requres a new namespace.. I would prefer not to include this change if the namespace had to change.

Katy: would id affect interop if the namespace does not change, but the schema does?

Marc H: taking something out and putiting something back in without changing namespace is dangerous, because it will cause problems in an implementation stating what schema it has implemented.

Umit: I agree with Marc H.

<Zakim> anish, you wanted to ask as to what we put on the backburner -- this issue resolution or whether we change the NS or not?

Jonathan: The decision on this issue depends on how many other changes we get. If there are other big changes, we could include this resolution. If there are no other big changes, we might decide to not include this resolution.

Anish: should we put this issue on the back burner.

Mark N: yes.

<Zakim> hugo, you wanted to talk about wsa:InvalidAddress

Jonathan: if there are several changes required, we would have to bite the bullet, and include them, thus changing the namespace.

Hugo: I found some other related issue with invalidAddress. Should I open a new issue about this? I put it on the email list already.
... there is a problem with "probliemIRI" datatype. I will take with people next week to determine if it is necessary to raise a new comment.

Mark N: can we defer the resolution of this issue?

No objection to defer resolution.

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

CR3 ID typed attribute on ws addressing eprs

Mark N: this seems out scope for us, and is for those using addressing

Gil: As a courtesy we should say in the spec that when signing addressing headers we should pick one ID.

Jonathan: I do not see why we should say anything. The security layer should make that decision.

Anish: Ws addressing is no different than any other spec defining soap headers. I am not sure we have to say anything in our spec.

Jonathan: I propose we decline to do any change to the spec.

<MSEder> let jon do it

<scribe> ACTION: Jonathan to write rationale for declining and send it out for review by WG [recorded in http://www.w3.org/2005/09/19-ws-addr-minutes.html#action03]

Mark N: any objectons to close with no change.

<bob> more that the issue is out of scope

Resolution: close CR3 with no action

<scribe> ACTION: jonathan to informally respond to John Kemp with rationale for closing cr3 without change. [recorded in http://www.w3.org/2005/09/19-ws-addr-minutes.html#action04]

Summary of Action Items

[NEW] ACTION: jonathan to informally respond to John Kemp with rationale for closing cr3 without change. [recorded in http://www.w3.org/2005/09/19-ws-addr-minutes.html#action04]
[NEW] ACTION: Jonathan to write rationale for declining and send it out for review by WG [recorded in http://www.w3.org/2005/09/19-ws-addr-minutes.html#action03]
[NEW] ACTION: katy to send all but her last two comments [recorded in http://www.w3.org/2005/09/19-ws-addr-minutes.html#action01]
[NEW] ACTION: Tony to send his comments [recorded in http://www.w3.org/2005/09/19-ws-addr-minutes.html#action02]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2005/09/20 00:17:52 $