See also: IRC log
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jan/0084.html
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
http://www.w3.org/2002/ws/addr/wd-issues/#i013
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
http://www.w3.org/2002/ws/addr/wd-issues/#i015
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
http://www.w3.org/2002/ws/addr/wd-issues/#i018
(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
http://www.w3.org/2002/ws/addr/wd-issues/#i040
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.
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")
Anish: Didn't we say that we're waiting for the WSDL group?
Chair: Yes, we'll discuss this afternoon
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?
(assent)
ADJOURNED - LUNCH
<scribe> Scribe: jeffm
markn calls joint ws-addr/wsd joint meeting to order
intros
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
http://www.w3.org/2002/ws/addr/wd-issues/#i019
http://www.w3.org/2002/ws/addr/wd-issues/#i034
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
http://www.w3.org/2002/ws/addr/wd-issues/#i038
how does implicit mep set up by replyto: relate to wsdl/soap. more discussion later
http://www.w3.org/2002/ws/addr/wd-issues/#i017
addr is waiting for outcome of discussion from WSD
http://www.w3.org/2002/ws/addr/wd-issues/#i021
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
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