Web Services Addressing WG call

3 Nov 2004


See also: IRC log


Mark Little
David Orchard
Paul Downey
Robert Freund
Yin-Leng Husband
Francisco Curbera
Greg Truty
Rebecca Bergersen
Steve Vinoski
Jonathan Marsh
Martin Gudgin
Michael Eder
Mark Peel
Anish Karmarkar
Jeff Mischinsky
Marc Goodner
Steve Winkler
Glen Daniels
Marc Hadley
Hugo Haas
Tom Rutt, Fujitsu (observing)
Davanum Srinivas
Rich Salz
Ales Novy
Jiri Tejkl
Philippe Le Hégaret



Mark: next F2F hosted by Microsoft in Redmond 7-9th December
... Editors get to stay after class

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

MarcH: overview of our new documents
... introduction unchanged in all three parts, needs more work
... send in your comments on the abstracts
... security probably doesn't belong in core, so it's in the SOAP binding sections, e.g. wss doesn't belong in abstract
... wsdl document needs most work
... core stuff fair stable, i guess
... message information headers isn't the best term to use - how about message information property

harris: message information items?

MarcH: might be a bit xml infoset specific, but that's ok
... i've reviewed the documents myself - this is very much a first attempt, i've more fine grained stuff to do

<yinleng> message information property is the other suggestion?

Mark: happy to give the editors a free reign to meet the schedule
... please read and get to know the drafts, suggests discussing editorial issues directly with the editors

Jonathan: when will we get the first publication of a working draft?

Gudge: will use our time together here in Miami to work with MarcH

<Gudge> ACTION: Editor's to come back with a go/no go by 2004-11-8

<Gudge> ACTION 1 = Editor's to come back with a go/no go for first public WD by 2004-11-8

Issue 23


Rebecca: has 2 use-cases driving addressing 1) dynamic invocations 2) transport independence both are critical

Michael_Eder: asked for More details on issues and Minutes from New York

Jonathan: why should every use of ws-addressing should be open to dynamic discovery?

<Gudge> +1 to jonathan's comment (natch!)

<dorchard> +1

Tom: reference should be able to be just a URI, no extra metadata

DaveO: wants more discussion on this issue, e.g. wants to understand option 5
... there is a co-contstraint, e.g. on the optionality of the elements

Anish: wants to understand why some of these elements are being called "metadata"

Mark: useful term, but has no dangerous meaning in this context

DaveO: various things explicitly mentioned in addressing, which do you think aren't metadata?

Anish: reference properties seems to be on a par with address

DaveO: what is the purpose of distinguishing what is metadata and what is not?

Mark: this is more about which properties are optional. can we discuss this with issue 1?

<dorchard> FWIW, I'm worried about getting into the data vs metadata discussion.

Rebecca: our use-case #2 .. anything apart from an address is metadata

Paco: a WSDL document is different to a runtime artifact, doesn't think metadata fits here
... endpoint reference and description of endpoint are distinct

<Gudge> I see [address], [reference properties] and [reference parameters] as making up the overall address of the service

Rebecca: wanted to bring discussion back to my use-cases. don't care about terminology

Mark: suggests recasting the proposal using different terms

<Gudge> other pieces of information in an EPR might also be useful to the recipient of the *EPR*, but generally are not useful to recipients of messages *addressed* to that endpoint

Tom: issue needs clarification

Greg: The point Rebecca was trying to make, she wants the ability to specify within the EPR multiple ways to get back to the endpoint (analagous to the way that CORBA had the ability to specify multiple ways to address a given IOR)

Rebecca: wants to talk about being able to reference a WSDL file
... i raised that as a part of issue 23

<anish> rebecca -- is this issue 24?

Mark: this issue is abut optionality, that's another issue

Rebecca: wants these issues to be described as "critical"

Jonathan: a clear proposal will help your case

Anish: reads issue 24


<HarrisR> Should EPRs be capable of carrying metadata both by value and by reference? Should there be a generic inclusion mechanism for metadata in EPRs? Best practices defined?

Anish: Rebecca - does this capture your issue?

Rebecca: no, not at all.

Mark: would like to separate the optionality from any other bundled issues in #23

Rebecca: can we have this on the agenda for next week?

Mark: send something to the list

MarcH: when did we agree to prioratise the issues?

Mark: at the F2F after you left.. dependencies upon WSDL take priority from a schedule POV

MarcH: ok so long as other issues don't get closed without discussion

MarkN: wants optionality proposals on the list within the next two weeks

<hugo> See http://www.w3.org/2002/ws/addr/4/10/27-minutes.html

<hugo> http://www.w3.org/2002/ws/addr/4/10/27-minutes.html#item02

<anish> gudge -- why do u think that other than wsa:Address and refps everything else is not useful for the recipient of the msg?

Rebecca: issue 20, 21, 23 were the highest priority due to WSDL dependency, but issue 23 has been characterised not to depend upon WSDL. it's still important

<anish> i see that it could potentially be useful

Issue 9

<anish> one could imagine multiple services fronted by a single URL

pauld: worries about the impact of allowing more than one EPR in the addressing structure, you need a processing model to acompany more than one EPR

<anish> +1 to marc's suggestion

<Gudge> i could probably live with that

<Gudge> ACTION: PaulD to propose a resolution for i009. Due 2004-11-12.

<marc> suggestion was to allow cardinality greater than 1 in the core spec but to then add constraints in the SOAP and WSDL bindings

pauld: should allow multiple EPRs in a structure, maybe with an acompanying processing style URI, but we as a WG should not go down the route of discssing such processing models - sending to a list, high availablity, etc

MarcH: suggest core allows multiple EPRs and the SOAP bindings restrict to a single EPR

Issue 6

<anish> marc -- r u suggesting that we should make 'To' optional in core and again restrict it in the wsdl bindings?

MarcH: outlines issue

Gudge: addressing in the message is independent on how it will be sent
... largely, but anonymous URI is a wrinke in that picture

MarcH: will send mail to the list to identify concrete suggestions

Issue 1

<Paco> +q

DaveO: the web architecture talks about primacy of using URIs to identify primary and secondary resources for properties that come with other URIs .. the question is what we can do here to describe the properties we have in EPRs
... i've started work on this, have a scenario an EPR with a reference is given to a client and that is used by a service, what are the advantages of using an XML structure rather than just a URI.

Mark: noone suggested at the F2F that we should replace reference properties with URIs. sounds like david's scenario will be a good path to work on

DaveO: didn't hear anyone suggest a URI to EPR mapping either.

Paco: it's assumed that we all understand the web architecture document, is this a language issue? we should state what are the conflicts for SOAP. should we say an EPR should identify a resouce.
... i think not

DaveO: webarch says a resource is a think and should have an identifier and that identifier should be a URI.

<anish> WSRF is certainly using refp to 'identify' the resource behind the URL

<anish> when using ws-addressing

Mark: we've been talking about what a resource is in terms of REST, this may not be exactly what the webarch is talking about

Paco: EPR is more than just an identifier, e.g. has cookies

<MSEder> What charter say http://www.w3.org/2004/09/wsa-charter.html#Scope

DaveO: notion of taking a URI and then adding information to identify secondary URIs is common

Hugo: looking forward to Dave's email with use-cases. from my POV, one outcome is to just use URIs

Tom: wants a URI only scenario

Glen: what we've got in an EPR is an identifier, like WSDL there are slots for metadata. reference properties and parametes sound like they could be separated or folded into a URI. looking forward to Dave's mail!

<Gudge> ACTION: David to kick off discussion of i001. Due 2004-11-05

<Gudge> ACTION 3 = David to enumerate scenarios constrasting URIs to EPRS WRT i001. Due 2004-11-05

Issue 8


Glen: explains issue. could end up with a very large EPR, main problem is making each reference property a 1st class header may impact intermediaries, has security issues, may be solved by a simpler approach of having BLAH as an EPR

<HarrisR> the To header

Mark: we should have a discussion on the security issues, this issue is stong in many people's mind. we should work on this to achieve consensus

Glen: wants specific example (from Gudge?) where SOAP processing model is useful when processing these headers

<vinoski> +1 to Glen's points

<Gudge> -1 to Glen's points

Glen: you probably need to understand which headers are reference properties and which are just headers

<anish> +1 to glen's points :-)

Gudge: concrete scenario is "i just program at the SOAP level"

<vinoski> In his defense, Gudge did send a WS-Eventing scenario to the mailing list

<Gudge> ACTION: GlenD to develop the issues that he raised in discussion of i0011

Glen: addressing isn't a part of SOAP

<anish> but the ws-eventing subscription info which is sent as a separate soap header block can be part of wsa:To and it will still work fine

Tom: when dispatching you have to be aware of what properties mean

<Zakim> Gudge, you wanted to ask Glen a clarifying question

<anish> another alternative (and i'm not suggesting this is the right way) is to create separate well defined header blocks for ref prop ref props

Glen: ... should be able to use poilcy where there is an agreement.

Harris: for an application programmer this should be seamless - we're all programming at the same level here
... infrastucture level

<HarrisR> +1 to dorchard's comments

DaveO: i haven't heard yet why having a dispatch mechanism based upon addressing is agregous as opposed to basing it on something else

<HarrisR> why is it an egregious problem to stuff the ref props into the To element instead of arbitrary soap header elements

<dorchard> Given that it is infrastructure dependency as opposed to application developers.

Glen: still wants a specific use-case for making ref-props a first class SOAP header
... reference properties seem like an "echoing technology" but instead we're breaking the layering

Mark: we really need to see if there is there an issue with the current design


issue i021

Hugo: not too long from now any WSDL document will be able to support addressing. there is a need to either describe that a WSDL document uses addressing or maybe we can just assume that every WSDL 2.0 document should be able to support addressing.
... however WSDL 1.1 will require an explicit declaration since there is already a lot of WSDL 1.1 'out there'
... if we want the WSDL 2.0 soap binding to implicitly support addressing we need to contact them soon

Glen: may need some switches in the SOAP binding. don't think we can realistically do this in the WSDL 2.0 timeframe.

DaveO: we don't have a WSDL 2.0 implementation, but we do have one for WS-Addressing. timing sounds feasible to me.

Gudge: we're going to be rec way before WSDL 2.0

<dorchard> DaveO says this from an impl perspective, not necessarily from a stds timeline.

DaveO: works from an implementation perspective, from a standards timeline, it might not work

???: do we have to go to the WSDL group with a complete proposal?

Mark: we need to give them a heads-up on this

MarcH: how much overhead is it on us to ask for two URIs from WSDL? all we would need to do is create a feature and a module (use WSDL extensibility)

<mnot> one second

<mnot> our phone here cut us off, and zakim won't let us back in

<mnot> I'll find a victim for the AI

<marc> my point was that its not much overhead to require specification of a feature and module in WSDL for services that support addressing

<mnot> conference call adjourned

<mnot> if people have comments about the issues raised by dough and rich on the list

<marc> no real runtime overhead, only a small design/description time one. not a big deal

<HarrisR> can we get some logistics info on the Redmond F2F as soon as possible

<mnot> i.e., whether they're issues, please say so in response; otherwise, I'll add them to the list this week

<mnot> Harris: yes

<HarrisR> thx

<RebeccaB> Besides dropping the network connection, what's the proper way to logout of the IRC?

<mnot> type a forward slash, then 'quit'

<RebeccaB> Thanks!

<hugo> Hugo: I agree with Mark and it's one of the option I proposed; the other one is to basically state that addressing is as central as SOAP 1.2 in the WS architecture

<mnot> thanks Hugo

<hugo> ... the recent WS-* proposals certainly go in this direction

Summary of Action Items

[NEW] ACTION: David to enumerate scenarios constrasting URIs to EPRS WRT i001. Due 2004-11-05 [recorded in http://www.w3.org/2004/11/03-ws-addr-irc#T21-26-13]
[NEW] ACTION: Editor's to come back with a go/no go for first public WD by 2004-11-8 [recorded in http://www.w3.org/2004/11/03-ws-addr-irc#T20-20-07]
[NEW] ACTION: GlenD to develop the issues that he raised in discussion of i0011 [recorded in http://www.w3.org/2004/11/03-ws-addr-irc#T21-35-01]
[NEW] ACTION: PaulD to propose a resolution for i009. Due 2004-11-12. [recorded in http://www.w3.org/2004/11/03-ws-addr-irc#T21-02-17]

Minutes formatted by David Booth's scribe.perl 1.95 (CVS log)
$Date: 2004/11/08 23:37:20 $