Web Services Addressing WG Teleconference

13 Feb 2006


See also: IRC log


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


changes to agenda

review of minutes of 2006-02-06 distributed meeting http://www.w3.org/2002/ws/addr/6/02/06-ws-addr-minutes.html

Minutes accepted without objection.

Mark N's status

MarkN: planned to act as co-chair for a month
... changes due to new employment - will act as an observer for the next month
... reduced to bark, no bite

Last Call

Bob: assuming we can get document into shape, consider LC period on WSDL document ended at the end of March
... any objections?


TonyR: Instead of including the resolution of CR15 under 3.5, which would result discussing SOAP 1.1 under SOAP 1.2 heading, I put it into a new section 5

DaveO: the new text is missing the intended pointer to the one-way binding.

TonyR: had trouble constructing a pointer to a document that doesn't exist yet

DaveO: need a placeholder that we can update

<anish> we can make the Note/WD go through LC as well

<uyalcina> +1 to Anish

DaveO: very important to include this pointer when discussing non-anon with SOAP 1.1

<dorchard> davidhull, it's not that tricky because xmlp is talking about soap 1.2 and my comment is on soap 1.1

Hugo: could insert a link to the e-mail archive in an editorial note

<scribe> ACTION: Tony to insert an editorial note linking to the SOAP 1.1 proposal [recorded in http://www.w3.org/2006/02/13-ws-addr-minutes.html#action01]

Marc: re: my implementation of the resolution of issue 70 - softening language
... resolution ended with suggestion that editor should insert an example.
... instead I added a para saying

<marc> Example text : dditional runtime information could override the value of the [destination] message addressing property for messages sent to an endpoint, e.g. a runtime exchange might result in a redirection to a different EPR. Note that WS-Addressing does not define any normative mechanism for such redirection.

<uyalcina> Resolution2006-01-20

<uyalcina> point the editors to the resolution of i056 and especially at "in the absence of additional information", and add an example for it (runtime override)

Katy: like the text, but not sure about the text after eg:

Umit: do we need an example?

Bob: want to get this document into LC - feel free to raise LC issues against this

Action Items

Bob: Jonathan's Option 3 proposal - is this an obsolete consideration?

Jonathan: still not comfortable

Bob: let's close this item, can always raise a new item
... all other AIs are done


Bob: considering this now because Paco has limited time on call today

<anish> URL to my proposal: http://lists.w3.org/Archives/Public/public-ws-addressing/2006Feb/0094.html

Paco: extract option 3 from original e-mail as separate proposal
... meaning of Anon depends on the transport binding

<Zakim> marc, you wanted to mention issue 70 resolution

<Jonathan> Is this the latest proposal? http://lists.w3.org/Archives/Public/public-ws-addressing/2006Feb/0091.html

Paco: in HTTP this means using the reply channel, which means there are no accepted semantics for Anon in To of a request

DaveH: is this normative or not?

Paco: I have no problem if we think that using anon in a request should fault

<Zakim> dhull, you wanted to ask if this is normative

DaveH: either we make a normative change, or we are just making a note on the status quo

Anish: with this proposal, will we require a request to always carry a serialised wsa:To?

Paco: yes, to be consistent
... we can either be explicit about existing situation, or make up new semantics for anon for To on request

<bob> link to Anish's 4a version http://lists.w3.org/Archives/Public/public-ws-addressing/2006Feb/0094.html

Paco: let's not allow ambiguity, by stating explicitly situation regarding anon in To of request

Anish: not happy with keeping core unchanged and making meaning of anon depend on the binding

Paco: rather than include information about a transport in the core, keep core generic

DaveH: have an interop problem because we don't state what we mean
... status quo is already ambiguous, and any resolution will involve introducing new semantics
... willing to see any of several resolutions, but must not special-case HTTP in SOAP binding

Paco: fact that SOAP 1.2 defines abstract properties doesn't change situation
... status quo is broken
... the only accepted semantics is anon=HTTP response

DaveH: if we state general case: anon disallowed for request in SOAP 1.2 is OK

Umit: supporting what Paco is saying

<pauld> would say the status quo is "we say nothing" which was only broken for me because *I* made assumptions.

Umit: adding extra semantics is dangerous; leaving it dangling is dangerous; Paco's proposal is safe

Jonathan: is there a concrete scenario that relies on this being undefined?

DaveH: faulting if you get anon on request is OK, but what I find objectionable is referring to HTTP in the context of SOAP 1.2
... if we make a blanket statement about HTTP, then we make the SOAP 1.2 binding have to have special handling for HTTP - lose generality
... may be abstract, but it's an important issue
... holding onto the layering is important

Bob: now let's look at Anish's proposal

Anish: we did the defaulting (to anon) to simplify the common case of response over an HTTP link
... problem is that we have made the request more complicated (have to serialise wsa:To)
... perhaps the optimum is to specify defaults not in the core but in the bindings
... proposal removes default from the core; adds wording to binding to say anon refers to HTTP response channel
... this allows [destination] to be undefined
... different protocols may have reason to leave wsa:To undefined
... protocol specific header may provide the equivalent information in place of wsa:To
... suggest making wsa:To required, but not provide a default

Umit: not really making To unrequired, really making it defined by underlying protocol
... what is assumption if [destination] is undefined?

Anish: it's the other way around: the value of the [destination] property may come from somewhere other than wsa:To
... the [destination] property may be set from other information

Umit: trying to understand how you specify [destination] in a transport-independent way

Anish: the [destination] property means what it means today if present, but if it is not present, nothing is stated

Umit: if you don't have [destination], how do you know where to send the message?

<anish> wsa:To is already optional

Katy: uncomfortable that [destination] is not mandatory in this proposal
... are you suggesting that anonymous becomes HTTP anon?

Anish: fine with having [destination] mandatory, but must have mandatory wsa:To as well. Not happy with having default to anon, and not requiring binding to define anon

Paco: understand wanting to get rid of defaulting, but not happy with adding "magic" to handling message destination

Anish: maybe destination is not required with some protocols
... happy to split proposal
... started by assuming people did not wish to change the cardinality of [destination], but people seemed happy with it
... would you be happy with defining defaulting at the binding level?

Vikas: Anish raised the point during discussion

<Zakim> TonyR, you wanted to ask if Anish is making wsa:To optional, or [destination] optional

<uyalcina> great point Tony!

<vikas> Tony, what I was saying is wsa:To mandatory in Core but optional in soap binding

Marc: just checking: the proposal is to move defaulting from Core to binding

<TRutt> I like the flavor of Tony R proposal, at the soap binding level

Bob: are we looking at a third proposal?

Paco: Anish and my proposals seem to be coalescing

<uyalcina> i like the fact that we ack destination is mandatory

Anish: I tend to agree. Perhaps Paco and I can take a joint action to revise to produce a converged proposal?

<anish> i believe that the interop issue has kicked up a whole bunch of stuff

<anish> and we need to deal with it

<anish> i.e., the dragons in 'anon'

Jonathan: I think we're heading into the weeds here. A simple proposal (like PaulD's) could address this, without wide impact on spec text.

<TRutt> I sympathize with Jonathan, the we do a minimal fix, which has the affect of making to required for soap request

Jonathan: don't see value in big change

Anish: changes aren't so big

Jonathan: not sure you're addressing Marc's objections

Anish: not ignoring Marc's problem, if we focus on SOAP binding (instead of SOAP/HTTP)

Paco: see this as resolving the dragons that we roused in the interop

<TRutt> Could Tony restate his compromise on te IRC using the proper wording of soap binding?

DaveH: Marc's objections to defaulting in the binding are the same as mine

TonyR: my suggestion is that wsa:To is optional, but if it is not specified in the message, then the binding MUST provide the value of the [destination] property (which is mandatory)

<vikas> core shouldn

TonyR: in my head we don't have a default for wsa:To, we have a default for [destination], and it is provided by the binding.

<Zakim> Jonathan, you wanted to restate the interop problem

TonyR: in other words, we remove the defaulting from the Core, we leave wsa:To as optional, we leave [destination] as mandatory.

Jonathan: the interop problem was that two different implementations interpreted the meaning of wsa:To being anonymous in different ways

Anish: isn't that CR18?

<Zakim> pauld, you wanted to ask about expected impact on CR implementations

Jonathan: don't see an issue in CR20 at all

<Nilo> i keep getting dropped from the call...any thoughts why?

PaulD: interesting ideas, but we're in CR. We have demo'd interop already. Should not go changing things that will impact code

DaveH: is interop working because we removed the test cases that showed the problem?

Jonathan: no, there were test cases that relied on a non-existent feature (anon To on request)
... we just fixed the To in the test cases that depended on this undefined behaviour

Anish: what happened with implementation?

Jonathan: it faulted when given an anon To on request

<Nilo> zakim seems to be hanging up on me after one ring...with three beeps!!!

Hugo: like to support Jonathan and Paul - we don't have a clear solution for the problem. Seem to be revisiting past decisions.

<Zakim> anish, you wanted to say that this is an interop issue since we haven't defined what it means to have 'anon' uri for was:To

Anish: disagree - this raised dragons that were lurking


<bob> http://lists.w3.org/Archives/Public/public-ws-addressing/2006Feb/0056

DaveH: three way choice on topic of anon destination in a request
... 1. define it
... disallow it
... 3. define it and make it the backchannel

DaveH: prefer to keep status quo, add PaulD's warning note

<bob> In our Core specification for anonymous URI, we say:

<bob> """

<bob> The precise meaning of this URI is defined by the binding of

<bob> Addressing to a specific protocol..

<bob> """

<bob> Section 3.5 of the SOAP Binding "Use of Anonymous Address in SOAP"

Bob: Paul's proposal short - pasted into IRC

<bob> states the meaning of anonymous addresses in practical terms

<bob> when moving messages down a channel.

<bob> To explicitly state the Status Quo, I suggest adding the

<bob> following sentence:

<bob> """

<bob> A value of "http://www.w3.org/@@@@/@@/addressing/anonymous" for

<bob> the [destination] property implies no particular semantics.

<bob> """

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

<marc> ?

PaulD: this sentence gets added to the SOAP Binding in new section 5

Bob: does this mean that DaveH is now advocating Paul's proposal?

DaveH: yes

PaulD: providing clarification of meaning of anonymous To (we already say meaning of anon ReplyTo)

Anish: so you say we do not specify the meaning of anon To no matter which message it appears in?

<Zakim> dhull, you wanted to clarify

DaveH: rules in 3.4 say if ReplyTo was anon must put anon in To

<TRutt> what about optionality/defaulting of To Value on response

DaveH: the intent of this note is that one must not do this except when replying to an EPR that had anon in ReplyTo

<Zakim> marc, you wanted to discuss whether anon to means this was sent to anon or not

Marc: it's not accurate to say we don't assign any semantic to anon - we do in the case of reply
... we just don't have semantics for anon in To of request

DaveH: or in a one-way

<marc> we don't have semantics for any address in To really

<marc> [destination] is jets wehere the message was sent same for anon or any address

TonyR: anon has meaning only when used in response to an EPR with an anon ReplyTo

DaveH: anon To has meaning only when used in response to an EPR with an anon ReplyTo

<anish> [destination] prop with the value of 'anon'?

DaveH: [destination] value of anon URI has meaning only in a response to an EPR with ReplyTo having value of anon URI

<bob> [anon destination] has meaning only when used in response to an EPR with an anon ReplyToq?

Marc: response endpoint having value of anon URI

<anish> what don't we say that 'anon' means the "response channel" -- if you use it for response, it is defined. If you use it for 'request' u are on your own

<anish> that way we define what it means -- and it says the response. If your going to use it for request message -- we don't know what it means

Jonathan: why don't we just say Anon means the response?

DaveH: trying to say that we should say that we specify this in one case, but not say anything in other cases

<vikas> because not all transports have response; in which case anon means something specific to transport

TomR: I thought we were allowing someone in the future to come up with a binding that defines a different meaning for anon

Jonathan: I think the concern is that we won't know whether anon is valid until we reach the binding level - makes general coding impossible

Anish: instead of Paul's wording, why don't we say that it means the response channel?
... instead of saying "there are no semantics", say that we have semantics for response, but not for request

Bob: Martin G's words were "the binding knows what to do".
... perhaps Jonathan and Paul could join the Anish/Paco team to come up with a resolution
... let's talk about this on the list during the time between meetings

<bob> thanks tony for scribing

<anish> Bob: I would like to resolve these issues ASAP and would like to get some email discussion early, rather than a day before the call

<anish> anish: i'll send out a proposal to paco today. Don't know what Paco's schedule looks like, but if he can respond quickly, we'll send out a proposal today or tomorrow

<bob> Goal is to at the beginning of the next call to afree on a joint proposal.

<bob> thanks and good night

Summary of Action Items

[NEW] ACTION: Tony to insert an editorial note linking to the SOAP 1.1 proposal [recorded in http://www.w3.org/2006/02/13-ws-addr-minutes.html#action01]
[NEW] ACTION: Anish and Paco to develop a consolidated proposal to issue 20 http://www.w3.org/2006/02/13-ws-addr-minutes.html#action02]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/02/14 08:49:47 $