Web Services Addressing Working Group Teleconference

14 Mar 2005


See also: IRC log


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


<hugo> Scribe: Hugo

Roll call, select scribe

Scribe is Hugo

Agenda review, AOB

Call for corrections to the minutes

F2F minutes are approved with Hugo's corrections

2005-03-07 telcon minutes are approved too

Review action items

Chair is going through open actions

Core and SOAP Binding Issues

Proposed - Metadata as top-level schema definition


<scribe> Chair: this is potentially reopening i053

<Marsh> +1

<anish> +1

<vinoski> +1

UNKNOWN_SPEAKER: any objection to making the change?

<dhull> +1

RESOLUTION: Umit's resolution is accepted

Anish: I wanted to propose to split the schema for Core and the SOAP binding

Marc: things like @isReferenceParameter, @retryAfter, etc. would go into the SOAP binding schema

Gudge: I actually started with several schemas

[ discussion about whether to have 1 or 2 target namespaces ]

Anish: I prefer to have them split and with different namespaces
... I see Core and the SOAP binding as independent

Dave: I'd like to keep it simple

Anish: the tools can deal with it without any problem

Dave: but humans don't; this is small enough to keep it all in the same namespace

Anish: what if we want to rev one the SOAP binding?

Dave: you can do it

Anish: but we would need to rev a schema which holds both definitions

Dave: do you really think that we would rev only one of them?

Anish: why split the documents then, and not the schemas?

Dave: I don't like this idea that every document has its own namespace and its schema

Chair: this seems mostly editorial
... is anybody feeling strongly about that?

[ silence ]

<inserted> Chair: we will stop discussion here for now then

Proposed - Handling arbitrary sets of associated endpoints


[ Dave describes issue ]

Jonathan: if I had a pattern with reply, fault, alt-reply, what would people do?
... people could add another element for alt-reply

Dave: let's remove ReplyTo and FaultTo then

Gudge: those 2 hit the 80-20 point

Dave: I think that we're tilting very heavily towards request-reply, and not really enabling all patterns

Paco: you're proposing that people can extend without putting a 'wsa:' in front of it

Dave: I don't understand the status of MAPs
... they don't seem to be reified anywhere
... I don't see what section 3 is adding

Paco: I don't agree that section 3 is limited to request reply
... also, I think that this sentence from the charter just means that these headers could be used in different contexts

DaveO: is your concern that our MAPs are not reusable except for req-resp?

DaveH: yes

<anish> searching the current core ed draft and it does not talk about MAP extensibility

DaveO: suppose I have my 3-message interaction pattern; couldn't the properties be reused and then add a 3rd property for my 3rd message?

<marc> see last sentence of section 3.1

DaveO: if the 3rd header wasn't understood, FaultTo would be used to send back a fault

<marc> "Note that each of the element information items described above allows attribute wildcards for future extensibility."

<anish> but that is only about attribute wildcards

<anish> i cannot define another element which is a 1st class property

<uyalcina> I agree with Anish, perhaps we have an editorial problem

<marc> Well, you can you just need to write a spec for it

DaveH: this all came up when thinking about setting default values to the reply property
... I think that this is very specific to a particular interaction, and shouldn't be part of the core

<uyalcina> the question is whether you are allowed to write a spec for them or not.

<anish> even if i write a spec, it is not part of the MAP. For example, WSDL component model is extensiblity, if i write a spec, i can make a new component and make it part of the WSDL component model

<marc> what's to stop you creating a new one ?

DaveO: it all depends on the importance you give req-resp

<uyalcina> the wording does not necessarily appear to allow it

<Marsh> You mean, it's not part of the Core WS-A MAPs as defined in the Core WS-A spec.

<anish> the words seem to say that MAP wrt to element extensibility is closed

<uyalcina> I agree with Anish there

DaveH: accomodating req-resp is fine, but why aren't other patterns treated equally?

<anish> jonathan -- i don't mean that i should be allowed to define "core

<marc> we don't define a container for MAPs so how can we define element extensibility for them

<anish> " properties but that MAP should be extensible for elements

DaveO: we are basically saying that req-resp is part of the core

DaveH: I think that this is closer to the WSDL binding

<anish> marc -- that may be a problem and perhaps we should leave it alone. All I wanted to point out was that I can't define an 'alternate reply' property which is part of MAP.

<anish> MAP does not allow that

Glen: [ missed by scribe; sorry ]

<mnot> Glen asked whether this could be addressed by some text around the properties, rather than changing them.

DaveO: if there was some text that showed how to use our spec with another pattern, would that satisfy you?

DaveH: possibly

Jonathan: I don't understand what we could do that could be automatically handled by processors that would be any different that you would get with our status quo

DaveH: section 3 is: "now that you've got EPRs, here's what you can do with it"

DaveO: I see this as WS-Addressing basic functionality

DaveH: to me, either we need to show how to support complex patterns, or we should change the spec

<marc> to echo DaveO, effectively the SOAP Header is the container for MAPs and that allow all sorts of element extensibility

DaveO: maybe the notification pattern example we received would be a good example

DaveH: when should you reuse?

DaveO: if you do things that look like faults, FaultTo should probably be reused
... I would like to have these things as reusable as possible
... we should make sure we don't preclude extension

DaveH: one clear way to get this is to give ReplyTo and FaultTo hardly any particular semantics

Chair: so you'd like to have some text pointing that there is some extensibility possible, possibly with an example

<marc> "Note, however, that reply messages may be sent as part of other message exchanges as well, and are not restricted to the usual single Request, single Reply pattern, or to a particular WSDL MEP. The contract between the interacting parties may specify that multiple or even a variable number or replies be delivered."

DaveH: the above text is fine, but is lacking an example

Marc: what kind of thing are you looking for? we are going through all the WSDL MEPs and showing this
... are you suggesting that we should give these tables as an example of extensibility?

DaveH: with rep-resp, the semantics are defined both in Core and in the bindings

<plh> scribe: plh

Gudge: you can define any element to be of type EPR, why is it not enough?

DaveH: with the extensible story, we're defining exactly request/reply MEP.

Gudge: because of the charter...

DaveH: yes, and they build on facilities from the Core. If I define my own MEP, I don't have those facilities
... I'd like to show how to extend addressing

Anish: if we do go along the lines of DaveH, we don't loose anything.

MarcH: but what would it look like?

<uyalcina> that would be a very good addition Marc.

DaveH: I still would like to see more of a good description of how to use the properties besides the resp-req MEP case

<mnot> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/0019.html

Chair: we already covered some of this discussion here. we could improve the text in the specification, with an example.

<dorchard> +1 to say that an example is "editorial"

Anish: in the resolution of 42, it's extensibility of EPR, not MAP

Chair: no, it's not

Anish: that's not how I interpret the resolution

<mnot> s/MarcN/Chair/g

DaveO: we could prove it's extensible

Chair: could we do during LC or CR phases?
... we could put this on hold until we discuss how to move to LC

<scribe> ACTION: DaveH to work with the editorials to clarify issue 42 with regards to extensibility [recorded in http://www.w3.org/2005/03/14-ws-addr-minutes.html#action01]

issue 50

<mnot> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/att-0066/Issue_50_minimal_change_proposal.htm

Tom Rutt's proposal: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0066.html

[Tom summarizes his proposal]

MarcH: it implies that replyTo and faultTo are always there, i.e you always need a messageId

DaveH: not completely sold that a missing fault should default to the reply. If I have a replyTo and a From, one can argue that faults should go back to the From.

Gudge: concerned about all messages having a reply endpoint. there must be some messages where there is no reply endpoint. Are we going to add something to express this?

Tom: this could be an editorial issue.
... messageId being required is not in my proposal.
... we're talking about properties and default.
... the abstract definition of reply endpoint doesn't have to be changed. still need to discuss fault endpoint

Hugo: agree with DaveH re reply/from. if we default to anonymous for replyTo, the replyTo propoerty is always set, thus requiring messageId. not sure if the anonymous property brings anything. also could define an "unreachable" property in case you don't have a reply endpoint

Tom: I'd like to withdraw proposal 3. proposal 1 and 2 matter.

Paco: my concern with proposal 1, it eliminates the possibility of having no reply endpoint. I think it is a lost of flexibility.

<Marsh> +1 to Paco

Paco: you do have a no replyto case.

Tom: confused. if there is no response, there is no reply, where is the problem?

<TomRutt> The messageID is the signal that a reply is expected

<swinkler> Tom, does that mean I can't include a message id in a message that I don't expect a response...

DaveH: I don't think the messageId could be the signal that a reply is expected.

<swinkler> +1 to DaveH.

<uyalcina> I would agree with DavidH that presence of messageID should not be overloaded

<pauld> could use messageId as sequence number on a one-way messsage ..

<uyalcina> why not? That will allow composition in some other layer...

DaveH: if I'm advertising a req/resp, others can always do what they want regarding the response, I could also ignore it if I wish.

Tom: still like proposal 1 and 2. not sure I understand Paco's point.

Hugo: re no reply point from Paco. If you're expecting a reply, you need to provide a reply endpoint. If you don't expect, there is no way to say that you don't want one.

<hugo> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0074.html

Hugo: DaveH made a proposal to strip the semantic of reply to not a lot of things. "a reply endpoint is where you put the address for reply". even if you're expecting a reply, replyTo is not mandatory. If you don't want to have one, we could define a proposal for that.

Paco: I'd rahter close the issue with the clarification a the defaulting of replyTo when absent, otherwise I would close the issue with no changes. If we don't go that way, we'll need to define a uri for no-replyto.

DaveH: we could add " If this element is NOT present and a reply is expected ..."

<hugo> +1

Tom: the receiver would have to know if a reply is expected. Paco would like to have a way to express no reply at all.

Paco: I want a "no value" instead.
... but I'd rather with the current status quo

Gudge: it seems the proposed optimization is different from what we choose for wsa:To

DaveH: could we move this into the WSDL binding and leave behind a minimal statement?

Paco: I don't think so. the req/resp pattern is not limited to WSDL req/resp MEP.

DaveH: so any conceivable req/resp MEP will have this semantic
... we're trying to anticipate any possible situation in the Core, but we do only know WSDL for the moment.

<Zakim> hugo, you wanted to clarify as the person who raised the issue

Hugo: originally, I wanted to sync reply and fault handling originally.

<hugo> s/originally\./the same way/

Tom: I want the optimization available for HTTP

DaveH: I do have a proposal on what the core would look like without the WSDL binding specific stuff

<hugo> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0074.html

Chair: who is in favor of the statu quo?

<Marsh> Status Quo please

<pauld> +1 to status quo

<TomRutt> in favor of dave Hull direction

Paco, Gudge, Umit, Steve Winkler, Bob, MarcH

<swinkler> +1 to status quo

<MSEder> status quo

<dhull> +1

<hugo> +1

<mlpeel> +1

<TonyR> +1

<swinkler> plh, that was steve winkler, not steveV.

<TomRutt> Tom in favor of d hull approach

<vinoski> abstain

<Pete> abstain

<anish> abstain

<bjarlestam> abstain

<yinleng> abstain

<prasad> abstain

status quo: 7, 5 for moving from Core to WSDL, 6 abstention

<TonyR> I can see 7 abstentionss in IRC

<vinoski> i also don't know yet

status quo: 8, 5 for moving from Core to WSDL, 6 abstention

<Zakim> hugo, you wanted to propose to just close the issue

Hugo: how about closing the issue with status quo and moving on?

Tom: we could close it with proposal 2

"If this element is NOT present then the value of the [fault endpoint] property is the same as the value of the [reply endpoint] property."

<dhull> +1

Jonathan: don't like the exact mechanism. proposal: "if no fault, send fault to the reply"
... so we don't have a faultto property
... if you interpret the precense of the faulto property, we keep that open

<scribe> ACTION: Jonathan to write a proposal for faultTo defaulting [recorded in http://www.w3.org/2005/03/14-ws-addr-minutes.html#action02]

Chair: we'll vote on this next week

Summary of Action Items

[NEW] ACTION: DaveH to work with the editorials to clarify issue 42 with regards to extensibility [recorded in http://www.w3.org/2005/03/14-ws-addr-minutes.html#action01]
[NEW] ACTION: Jonathan to write a proposal for faultTo defaulting [recorded in http://www.w3.org/2005/03/14-ws-addr-minutes.html#action02]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.115 (CVS log)
$Date: 2005/03/16 01:40:54 $