Web Services Addressing WG F2F (Melbourne, Australia)

19 Jan 2005

See also: IRC log


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.)
Yin-Leng Husband (HP)
Anish Karmarkar (Oracle Corporation)
Jonathan Marsh (Microsoft Corporation)
Jeff Mischkinsky (Oracle Corporation)
David Orchard (BEA Systems, Inc.)
Mark Peel (Novell, Inc.)
Tom Rutt (Fujitsu Limited)
Davanum Srinivas (Computer Associates) (substitute: Tony Rogers)
Greg Truty (IBM Corporation)
Pete Wenzel (SeeBeyond Technology Corporation)
Steve Winkler (SAP AG)
Ümit Yalçınalp (SAP AG)
Rebecca Bergersen (IONA Technologies, Inc.)
Ugo Corda (SeeBeyond Technology Corporation)
Jacques Durand (Fujitsu Limited)
Arun Gupta (Sun Microsystems, Inc.)
Philippe Le Hégaret (W3C)
Mark Little (Arjuna Technologies Ltd.)
Eisaku Nishiyama (Hitachi, Ltd.)
Ales Novy (Systinet Inc.)
Harris Reynolds (webMethods, Inc.)
Rich Salz (DataPower Technology, Inc.)
Jiri Tejkl (Systinet Inc.)
Steve Vinoski (IONA Technologies, Inc.)
Michael Liddy (education.au)
Arthur Ryman (IBM)
Mark Nottingham
Glen Daniels, Jeff Mischinsky

Issue 006


Make <To> optional, default value of Destination property to anonymous URI

Jonathan: Cases where you don't want to omit (signing, etc), but that should be OK

Paul: When does this get used? How often?

Marc: Every time we send an HTTP sync response, for instance

straw poll : Who'd like to see this in the spec?

8 for

Jonathan: It's natural to look at the <to> header to indicate the presence of WSA... can still look at <action>, but...

Paco: Seems simpler to have less optionality

(discussion of cellphone use-cases)

Tom: We really care about optimizations, so I feel strongly that we should accept this. Seems simple.

Tony: Do we want to explicitly say the empty address is not the same thing?

Marc: Should talk about XML base

Jeff: We need to do that in general

<scribe> ACTION: Marc to characterize the issues regarding XML base and the addressing headers - start discussion

Greg: Is this primarily for replies?

Marc: Reply is the obvious common usage, but not necessarily limited to that

Jonathan: Would slightly prefer an empty <to> to an omission

(discussion of whether "" could be a schema-valid encoding of a URI - conclusion == yes, although it's not a valid absolute URI at the application level)

Glen: Seems like we could profitably state that "" is equivalent to omission, and that the URI is absolute not relative to make things more complete.

Jonathan: URIs should be absolute in general for us - action, MessageID, relationship.... this connects to the issue of how you compare/absolutize URIs

Mark: Any objections to accepting this proposal?

No objections.

RESOLUTION: We will accept Marc's proposal (http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jan/0084.html)

NOTE: Microsoft indicates some discomfort with this resolution

i013 - Serialising metadata into messages


Anish explains the issue

(Discussion of a standard way to echo back the service QName in the EPR to the EPR's destination)

Greg: Isn't this just an implementation detail? If you want it back, use a RefP...

Paco: WSDL doesn't specify that this stuff appear in the message, so why should Addressing need it?

Anish: Hokay, RefPs seem to do the trick

RESOLUTION: Close issue 13 with no action, since ReferencePs allow the service to request arbitrary echoed data including things like service/port QNames

Issue 15


Marc describes the issue

No standard way to update EPRs

Marc: This is already "almost there" in that we say it's optional to put a <ReplyTo> in a reply - we just don't say what to do with it

Paco: There seem to be a lot of potential little issues around this and if we don't solve them all it might not be good enough

Jeff: Would this be a hint (you may use this new one) or a requirement (you must use this new one)?

Chair: This seems like something extra that we could do, but isn't strongly in scope either

Chair: Do people think this should be explored/fleshed out?

(some interest from 3-4 folks)

Jonathan: This sounds interesting, but feels like feature creep (should be in other spec(s))

Marc: Are people really against this? If not, I may pull it together as a real proposal...

Gudge: Layered spec seems right - do it after we've checkpointed/resolved our big stuff

Issue 18


(pause for test of the emergency intercom system)

Anish: This means an instance of an EPR is not really abstract, it's tied to a particular protocol, etc

Glen: right, I think that's the intent (although I might prefer otherwise)

Anish: Abstract properties (which exist outside particular bindings) have to contain non-abstract markup

Paco: Refp's don't have to contain those attributes, they just might

Anish: Impression you get from reading core is that a single abstract EPR can be used with multiple bindings - if you need proto-specific markup, this isnt really true...

BREAK - return at 10:24:35

(discussion of potential editorial change to indicate that an EPR isn't really "abstract", since RefP infosets might need to know about the binding)

If this is multi-protocol (per Steve Vinoski's issue), then this might matter

<scribe> ACTION: Anish to identify which parts of the specifications give an impression that EPRs are more abstract than they actually are

Back to issue 15 briefly

<scribe> ACTION: Marc to make a concrete proposal for issue 15 (redirection/EPR updating) due 2005-01-26

<Gudge> ACTION 3 = Marc to make a concrete proposal for issue 15 (redirection/EPR updating). Due 2005-01-26

Issue 40


Proposal is to strike all but first sentence in section 3 (Faults)

(with the idea of not repeating ourselves)

RESOLUTION: Delete all but first sentence of section 3, paragraph 1, in the SOAP binding doc.

Issue 22

Marc: Do we have a dependency on the new HTTP binding/SOAP MEP that David is working on for the SOAP binding doc?

(mumblings "yes")

Issue 17

Anish: Didn't we say that we're waiting for the WSDL group?

Chair: Yes, we'll discuss this afternoon

Jonathan's comparing URIs issue (issue XX)

proposal is to use WSDL language as boilerplate, and allow editor's discretion as to how exactly to do so

Web arch is more informative than something we can refer directly to

Relevant WSDL is section 6.2.1

Sorry, relevant URI spec text is 6.2.1

discussion of URIs as absolute, and whether we should allow relatives at all

suggestion is that all comparison of URIs is char-by-char

Discussion of whether URIs with escaped chars are the "same" as unescaped ones

Jonathan: Destination is special, because it's not exclusively an identifier - we shouldn't force this to char-by-char. Other ones seem OK though.

Paul: This doesn't seem a universally solvable problem, so we should just do our best

<umit> +1 to Paul

Jonathan: We could suggest that URIs like action should use a limited subset of chars to reduce escaping, etc... but doesn't seem worth it

<umit> nope

Jonathan: Introduce this text, calling out Action and MessageID

Marc: What does considering these as just Strings do to the schema types? Had this discussion in Atom - if a framework uses URIs, it might not do char-by-char comparison....

Jonathan: Seems simpler to just say how we're doing it (char-by-char) even if some people might want to put these values in URI classes with more complex comparison options

Paco: Why not destination?

Jonathan: Not often compared

<scribe> ACTION: Jonathan to flesh out proposal for comparison of URIs, and ask whether destination should be included in the list

<Zakim> hugo, you wanted to ask about referencing IRI draft and use the comparison rule in there

Hugo: IRI draft is proposed standard, and it includes detailed comparison rules - should we consider reusing those?

Chair: we were looking at the rules in the new URI spec

Jonathan: Does IRI provide choices or a single way to do it?

<hugo> http://www.ietf.org/internet-drafts/draft-duerst-iri-11.txt

<hugo> section 5. Normalization and Comparison

<hugo> re status, see: http://lists.w3.org/Archives/Member/chairs/2004OctDec/0079.html

(discussion - leave the details to the editors)

continue discussion on mailing list

scribe: about which properties we should include in this set of rules

Chair: Any other discussion before break?

Jonathan: We need to get our schema together

<scribe> ACTION:Chair to work with team to get a working draft of the schema published


Chair: On the order of 12-15 open issues left

<pauld> in section 5 "Comparison Ladder", Martin seems to offer a smorgasbord of comparison methods ..

Chair: Can we get new drafts out within a week or so?

Gudge: Yes

Chair: Please review drafts carefully - if there's anything major which needs tweaking now is really the time to bring it up
... Ready to close Addr and prep for joint meeting?



Joint Meeting with WS Description WG

<scribe> Scribe: jeffm

markn calls joint ws-addr/wsd joint meeting to order


Chair: shows state of issues list

linked from addresing home page

<Chair> http://www.w3.org/2002/ws/addr/wd-issues/

there are a small number of new issues that will be added

12 open, closed 23, dropped 6

<scribe> closed issue 1 and 8 -- web arch and refps -- probably 2 most contentious issues

goal -- go over wsdl related issues which addr has discussed and to have joint discussion

only have afternoon - so probably wont solve issues, but identify contact pts, assign AI's etc.

<Chair> http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-wsdl.html

MarkN reviews wsdl related issues

look at issues page and links from there

issue 3

issue 33

<asir> http://www.w3.org/2002/ws/addr/wd-issues/#i033



chose proposal 2 -- forwarded ported wsdl 1.1

<Zakim> hugo, you wanted to explain discomfort

http://www.w3.org/2002/ws/addr/wd-issues/#i035 action uri for defaults

extended resolution for 34 to 35


how does implicit mep set up by replyto: relate to wsdl/soap. more discussion later


addr is waiting for outcome of discussion from WSD


what is granularity and use case - could be switch indicating that addr is in use, could be fine grained for each message

no decisions yet, paco has AI to look at what coarse grained might looked like

there is an outstanding issue/discussion of whether to use f&p a/o wsdl extensibiliity mechanism

addr did not want to take on that issue --

there is contention :-)

end of brief review

jmarsh points out: http://www.w3.org/2002/ws/addr/wd-issues/#i017 might be worth discussing the potential solutions addr is considering

maybe after paul's presentation

break at 3:00 pm MEL time

<asir> what about issue 20? is that related to WSDL?

DavidO: WS-A and WSDL: MEPs, Bindings and dynamic addressing

pause for magicical incantations to distribute davido's presentation

davido talks

will describe about 10 diff patterns that could be used for req/resp and oneways

candidate wsdl mep, soap mep, and binding look like

on various slides

glen: pls crisply define "async"

all the diff mep in/out combos i'm going to talk about

davido: at some point in the invocation stack there is not a coupling in time
... typically people think of 2 diff http connections

tony: do u mean u can send of 3 reqs and get back 3 resps in diff order?

davido: y
... actually y, that is covered

kevin: async/req resp v1 -- uses 2 wsdl ops -- yes
... sounds like we are getting into the process def space

davido: yes -- some other spec needs to specify

anish: is there assump that the 2 http msgs are "special" in some way, e.g. null bodies

davido: yes, could be

anish: i can have anything in the "out" -- doesn't have to be a simple ack -- the wsdl would say --

currently on asyn req/rsp v4

discussion on desireablity of having 1 wsdl in/out mapping to 2 soap req/resp meps

davido: observes that wsd wg didn't take on defining this, so someone (ws-addr wg or an individ) could undertake the work or propose it to wsd wg again

paco: so this means 4 soap envelopes?

anish: yes
... seems a weird way to do things -- wsdl in maps to 2 sep soap envelopes as does the out

<umit> wsdl in mep does not map to anything at this point

<anish> daveo is on the slide that says v4

now slide v5

<umit> what is the url for slides?

<Marsh> http://lists.w3.org/Archives/Member/w3c-archive/2005Jan/0104.html

for v5, davido need to "define" new binding

<anish> another option is to have 1 wsdl in-out, 1 soap req-res mep and 2 one-way http binding

slide v6

<Chair> DaveO's presentation: http://lists.w3.org/Archives/Member/w3c-archive/2005Jan/att-0104/MEPsBindingsAddresses.ppt

marc: do u use a soap resp mep

davido: you could use add feature

umit: r u mapping indvid message to a soap mep (at least underthe covers)?

davido: i think so, trying to explore what one could do staring from a wsdl in/out and whether it is worth introducing new meps/bindings

paco: others can define their own bindings for meps

anish: on whehter u can use the soap resp mep -- allows sending say 10 requests and then picking up responses later

slide: 2 protocol asynch req response

<hugo> Presentation saved publicly at: http://www.w3.org/2002/ws/addr/5/MEPsBindingsAddresses.ppt

davido: shows case where the wsdl in-out uses an http binding and an smtp binding (e.g.0
... question for group -- do we new mep(s)/binding(s)

kevin: notes that wsdl 2.0 component model would need to be extended

umit: kevin is trying to point out that we have the abstraction at the wrong level --
... cant achieve the granularity davido is describing currently

glen: pulling back -- layered stack of stuff -- at each layer i have expectations about layer below
... so immmediately below the wsdl level, that layer needs to provide a certain functionality -- e.g. drop in message, and get out message in the right "place" -- that fact that other layers below will do something else to help implement that is a "detail"

<umit> i personally believe that where the binding and the soap mep is defined is at the wrong level.

<umit> It should be at the individual message

discussion about how to layer these abstractions

<umit> glen it is possible to solve this by defaulting

<umit> we have defaults for binding already

anish: there are more combos once u look at cross product of meps and protocols
... if u look at all these combos, and remove "weird" ones we need at a minimum a new soap/http binding

a soap oneway mep

<umit> we need a one way MEP period

kevin: agree we need new mep and change in wsdl constructs

<Zakim> Marsh, you wanted to mention LC101.

jeffm: we should adopt a simple model a la ws-i callback scenarios -- a)linked oneway and b)linked req/resp

jmarsh: observes that xmlp hasn't defined the fundamental mep that we need

jeffm: could we use the framework defined by xmlp?

jmarsh: yes

umit: we are already defining extendsions in part 2, why couldnt we do it there

anish: this seems to be so fundamental that it would be better if xmlp had or will do it

discussion about which is the right group to take on the work

<asir> +1 to moving this work to xmlp; suggestion, to request xmlp wg to work on this new SOAP mep and its binding

paul: what is important is interop and making sure vendors implement the same thing -- so that choices are not necessarily the best solution

<umit> the whole wsdl is full of extensibility points = choices

<umit> it depends on what we define and standardise

davido: which scenarios to support, which meps/bindings we need to use/invent, and then figure out which groups should do the work
... i.e. we need to do more work to define the reqs

marc: pushback on jeffm assertion that async/sync at mep level needs to be exposed to the user
... dont think there's a big diff between sync http resp/req or asynch smtp call

<marc> to be clear, i think there is a difference but that its not necessary to expose the difference in all cases. e.g. a sync layer on top of an async exchange is entirely possible and vice versa

<Zakim> Marsh, you wanted to try to summarize concrete actions we could pursue?

<dbooth> rssagent, where am i?

davido: wsdl group should think about relationshipt between wsdl meps and soap meps

jmarsh: ;right now wsdl spec says this binding can be used with these wsdl meps

davido: we need to scope out the work

jmarsh: 2 design cneters: figure out how to do the one or two scnarios a la jeff; figure out the right set of knobs at the various layers
... we should consider and balance importance of these 2 design centers

we are breaking for 20 minutes until 3:20 pm oz time

<asir> yes, he woke up

Chair: discussion on what activities we should undertake to move forward

jmarsh: 2 design centers:
... 1. provide 1 or 2 ways people can use asynch and provide support for wsdl one way mep
... 2. provide lots of knobs -- sounds appealing but worries from a schedule perspective
... logistic issues -- who does it, possibly diff ipr policies

jeffm: pushback on providing lots of knobs -- hurts interop -- is it really necessary

paco: who is the target user of the "knobs"

anish: current wsdl binding framework doesnt give u enough granularity -- this is issue 101

jmarsh: how many points of composition are there between layers

davido: we dont yet have a good enough feel for what all the options are
... eg. provide flexibility at bindings but not at meps

anish: compare all the diff scenarios david laid out and decide if which ones are the most important

glen: form a TF to do this sort of work

davidO: asks who would participate -- 4 or 5 hands go up

jmarsh: how do we make this TF successful

<dorchard> Option #1: wsdl in-out cannot be done using asynch.

davido: how to specifcy asynchronya)do correlated wsdl inout (a CB wsdl pattern) rather than "swizzling" b) allow a wsdl in/out to be done asynch "underneath the covers" b1-allow flex of meps in/out can go to multiple soap meps

<dorchard> Option #2: wsd in-out can be done asynch

<dorchard> Option #2a: flexible allocation of wsdl meps to soap meps

<dorchard> Option #2b: mandatory allocation of wsdl meps to soap meps.

<anish> what i was trying to say was that the difference between #2a and #2b is not very relevant from a practicle point of view as long as we have the "right" bindings

<dorchard> anish, you may see different options....

jmarsh: maybe this is an outline of decision tree for a TF

<anish> daveo -- perhaps. I think we need the right soap meps available to us, but the 1st thing we need to do is figure out what we want out of wsdl meps and bindings and then look at the soap meps

kevin: wants to describe some simple use cases

jmarsh: TF would define the diff options for supporting asynchrony
... e.g. fleshing out decision tree, bring back a few options to the WGs
... timeline -- techplenary might be a place to hold a joint meeting
... possibility of carving out time on tues afternoon for a joint meeting

<dorchard> charter: Determine interaction patterns of interest (ie one-way, asynch). Recommend design(s) for patterns of interest.

<scribe> ACTION: Chair jmarsh pick a time

discussion on logistics of forming a TF

picking times

looks like 4 pm eastern friday beginning 28 january EST

<pauld> presentation: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jan/att-0113/wsdl-extesnibility.pdf

consensus is noon Pacific on Weds starting 26 Jan 2005

<scribe> ACTION: hugo to start an email list and schedule zakim

name of TF is Asynch TF

WSDL Extensibility

next agenda item: WSDL Extensibility -- pauld presentation url above

on slide labelled "Choice"

kevin: asks if referring to wsi bp version of wsdl 1.1?

paul: can't really reference that

glen: notes that f&p has been back ported into an approved OASIS standard - WS-R

<pauld> hugo described this issue here: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jan/0058.html

end of ws-addr meeting

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.107 (CVS log)
$Date: 2005/01/21 05:30:52 $