See also: IRC log
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
http://www.w3.org/2002/ws/addr/wd-issues/#i023
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
http://www.w3.org/2002/ws/addr/wd-issues/#i024
<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
<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
<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
<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
http://www.w3.org/2002/ws/addr/wd-issues/#i008
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
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