See also: IRC log
<GlenD> Meeting: WS-Addressing F2F, Vancouver BC
<GlenD> Chair: Mark Nottingham
<GlenD> Scribe: GlenD
Discussion of rescheduling lunch
Lunch moves from 12:30 to 1PM to ease WSRX participation
PaulD makes a good point about the fact that admin stuff (dinner plans, logistics, etc) should be on the admin list, not the public list
Philippe: Rechartering won't
change scope for us, just duration. That's easy. If we want to
change the charter, it needs to go back to the AC.
... So, how long?
... would be good if this group would make rapid progress, and
then get out of the way. :)
... How long do you feel you need to finish the
recommendations?
PaulD: This was a time-driven schedule, and now we're rechartering. So have we failed?
Philippe: To some extent, yes.
Mark: We didn't expect to have to take as long on some of the chartered deliverables (i.e. WSDL binding wasn't in the submission).
Paul: The SOAP level message patterns, headers, etc. seem very ripe for standardization. However, it seems to me that the WSDL stuff is clearly not yet ready for standardization. Maybe we can ship the one and not the other....
(scribe misses some conversation due to network droppage)
(discussion of schedule coupling between WSDL 2.0 and WS-Addresing)
Jonathan: Don't see how we can get out of CR with the WSDL doc with the dependency there.
Philippe: Should we lower the bar for implementations in CR for the WSDL binding?
Paul: Yes, we're surely not going to get four WSDL 2.0 implementations!
(further discussion - some folks are more optimistic, some less so with respect to how much consensus we've actually achieved with the WSDL doc)
Umit: Worst case scenario
shouldn't be throwing out all the work that we've done for
WSDL. Not even talking about WSDL 2.0...
... Can we find a workable compromise which lets us meet a
reasonable schedule and get some of the good work we've done
out to the world?
Philippe: How long?
Anish: To PR, or Rec?
Philippe: PR, Rec isn't in your control.
Mark: Perhaps we could evaluate that question at the end of this F2F, when we see how far we've gotten.
DaveO: Because we can leave all the URIs the same between PR and Rec, it's possible that we "win" once we get to PR, i.e. the world wouldn't need to change implementations, etc, if we get held up at PR for a while (by WSDL 2.0)
Philippe: So what next? Any new work for this group after these recs?
Paul: We should combine the maintenance work of Addr and XMLP into one group...
DaveO: WS-Core? :)
<pauld> http://www.w3.org/2002/ws/addr/testsuite/report/
<pauld> http://www.w3.org/2002/ws/addr/testsuite/report/
<dorchard> We can leave the URI for the Rec version the same as the PR version if there isn't an incompatible change, therefore we could go to PR with WSDL 2.0 at CR on our schedule AND when when WSDL 2.0 goes to PR (and we go to Rec) then there shouldn't be any change to our doc and implementations.
<pauld> http://www.w3.org/2002/ws/addr/testsuite/
PaulD explains the test suite
<dorchard> hmmm. I wonder about splitting wsdl into 2/3 documents for wsdl 1.1 and wsdl 2.0. I imagine wsdl 1.1 couldn't be on the Rec track, so we could have the "wsdl core" which is then used by wsdl 1.1 and wsdl 2.0 docs.
Anish: wsa:To is anonymous, what does that mean?
Glen, Paul, others: That very question is in the feedback from the testing group.
Anish: did you use WSDL?
<TRutt> why are there two wsa:to in message
Paul: Normative part is the
messages, and also the assertions. (explanation of XPath
assertions in the suite)
... There are WSDLs, but they aren't normative.
Anish: how many impls cared about the WSDL?
Paul: Don't care, do we?
Anish: We're eventually going to do interop on the WSDL stuff too, so curious...
(seems 2 or 3 impls might have used WSDL)
(paul goes over WSDL doc)
(discussion of using a single "echo" element which was both the req and the resp of a single operation, and changing that to "echoIn", "echoOut")
Anish: Any discussion around using our WSDL markers? UsingAddressing, etc
Mark: No, very little discussion about WSDL at all.
(explanation of log files and test assertion checking)
Glen: We should change the assertions that require particular CustomerKey values, for instance, to take advantage of the log file format and instead refer to "the CustomerKey value in the request message"
(discussion of output)
Glen: So what happens next? Does this test suite have any relevance after PR/Rec?
Paul: I go talk about it at XML
2006... that's about it
... Nothing prevents people from reusing this stuff on their
own
Umit: How can my company reproduce these results?
Paul: Join the calls and participate
Umit: Are people going to keep up public endpoints?
(discussion of Paul's canned client, and the possibility of automatically running messages against a publically available endpoint)
(discussion of how some failures in the matrix were more related to incorrect assertions in the tests, etc...)
Umit: What issues/problems in the spec did you guys find?
Paul: optionality of To seems an
issue... should we define anonymous To?
... My assumption is if I POST a message to your HTTP URI, then
that URI is the assumed "To" when To is missing/anonymous.
(discussion of various opinions on the topic)
<scribe> ACTION: PaulD to submit a CR issue about the optionality of wsa:To and the meaning of Anonymous To [recorded in http://www.w3.org/2006/01/19-ws-addr-minutes.html#action01]
Paul: Dispatch issues (unique GEDs vs Action vs To, etc) are somewhat in need of discussion...
Mark: Next steps for this work?
Marsh: Work on better display
technology for the grid, debug failures, confirm results.
... Make it easy for implementors to check these results and
raise issues / fix impls themselves.
Mark: Special thanks to Paul, Jonathan, and everyone involved in the test work, plus BEA for hosting. Very successful event!
(discussion of next steps, how to optimize future testing and calls)
Jonathan: Would be great to have a four hour timeslot where everyone's available, on IRC, endpoints up.... then we could manage 1-1 conversations as needed via phone, etc.
BREAK - back at 10:50 (14 min break)
37D0366A39A9044286B2783EB4C3C4E8012AABB9@RED-
MSG-10.redmond.corp.microsoft.com
Proposal 1 is to make the general definition of the QName much more flexible. Proposal 2 says specifically we can use it in WSDL, and also in policy frameworks (of any kind).
Anish: Between the two I like
proposal 1. But I dislike both (doesn't belong here)...
... Two different WSDL extensions.. UsingAddressing and
Anonymous. Why not say this kind of thing for Anonymous as
well?
Marsh: By using UsingAddressing, you imply that the other info (action, anonymous) is available in particular places as well.
Mark: any others who prefer #1?
Tom: Yes
Jonathan: We need this and yes both will do the job, but we (MS) think #2 is much better and clearer.
Anish: I don't know exactly what "policy assertion" means (in #2)... first one seems to enable usage in other places without trying to say exactly what a policy assertion means.
(wordsmithing ensues)
<mnot> new proposal:
<mnot> 3.3 Other Uses of the UsingAddressing Element
<mnot> The wsaw:UsingAddressing element may also be used in other contexts (e.g., as a policy assertion in a policy framework) that use QNames. B The use of the element in such contexts is semantically equivalent to the use of wsaw:UsingAddressing as a WSDL extension.
<mnot> When such uses associate the wsaw:UsingAddressing element with WSDL constructs, the meaning of such association is semantically equivalent to the use of wsaw:UsingAddressing as a WSDL extension. Note that the association of wsaw:UsingAddressing to WSDL constructs where the wsaw:UsingAddressing WSDL extension element is not allowed is not meaningful.
<mnot> Revised proposal:
<mnot> 3.3 Other Uses of the UsingAddressing Element
<mnot> The wsaw:UsingAddressing element may also be used in other contexts (e.g., as a policy assertion in a policy framework). B Its use (including the use of related elements and attributes) in such contexts is semantically equivalent to the use of wsaw:UsingAddressing as a WSDL extension.
<mnot> When such uses associate the wsaw:UsingAddressing element with WSDL constructs, the meaning of such association is semantically equivalent to the use of wsaw:UsingAddressing as a WSDL extension. Note that the association of wsaw:UsingAddressing to WSDL constructs where the wsaw:UsingAddressing WSDL extension element is not allowed is not meaningful.
Anish: should we enable using Anonymous in the policy assertion context as well?
<pauld> chad, hi
<mnot> final proposal 3:
<mnot> 3.3 Other Uses of the UsingAddressing Element
<mnot> The wsaw:UsingAddressing element may also be used in other contexts (e.g., as a policy assertion in a policy framework). Its use (including the use of related elements and attributes, such as wsaw:Anonymous and wsaw:Action) in such contexts is semantically equivalent to the use of wsaw:UsingAddressing as a WSDL extension.
<mnot> When such uses associate the wsaw:UsingAddressing element with WSDL constructs, the meaning of such association is semantically equivalent to the use of wsaw:UsingAddressing as a WSDL extension. Note that the association of wsaw:UsingAddressing to WSDL constructs where the wsaw:UsingAddressing WSDL extension element is not allowed is not meaningful.
<mnot> i066 Proposal 3
<mnot> 3.3 Other Uses of the UsingAddressing Element
<mnot> The wsaw:UsingAddressing element may also be used in other contexts (e.g., as a policy assertion in a policy framework). Its use (including the use of related elements and attributes, such as wsaw:Anonymous and wsaw:Action) in such contexts is semantically equivalent to the use of wsaw:UsingAddressing as a WSDL extension.
<mnot> Note that the association of wsaw:UsingAddressing to WSDL constructs where the wsaw:UsingAddressing WSDL extension element is not allowed is not meaningful.
Mark: Should this be the proposal we vote on?
(group - yes)
Mark: Anyone object to closing this issue with this proposal?
(objections)
Mark: Time for a VOTE
BEA: YES
BT: YES
CA: YES
Ericcson: YES
Fujitsu: NO
Hitachi: YES
HP: ABSTAIN
IBM: YES
IONA:
JBoss:
Microsoft: YES
Nortel: YES
Oracle: NO
SAP: YES
Sonic: ABSTAIN
Sonoa:
Sun: ABSTAIN
TIBCO: YES
W3C: ABSTAIN
WebMethods:
10 YES, 2 NO, 4 ABSTAIN
The yesses have it.
RESOLUTION: i066 closed by accepting proposal 3 (see minutes)
Mark: Back to AI review!
(no objection)
Minutes are approved.
Proposal 1: <http://www.w3.org/mid/438CA309.9070406@tibco.com>
Mark: We need a one-way SOAP 1.1
binding for testing at least... where should it go?
... Decision comes down to whether we put it in one of our
existing docs, or a note.
<mnot> http://www.w3.org/mid/E16EB59B8AEDF445B644617E3C1B3C9C5375E6@repbex01.amer.bea.com
(DaveO walks us through his email)
Anish: does this apply to req/resp MEP? Or all MEPs?
DaveO: Any MEP where the condition (non anon replyTo) is possible.
Anish: one-way?
DaveO: Sure
Anish: What does it mean?
(discussion of meaning of outbound message)
(DaveO goes over the soap1.2 portion)
Glen: What about new URIs that do "the same thing" as the anonymous URI, but aren't spelled the same way? Don't want to restrict these in the future.
DaveO: Could say "which uses the backchannel" or something instead...
Glen: +1, wordsmithing TBD
... Also, prefer removing the last sentence of soap 1.1 portion
- it doesn't add anything, and in fact probably confuses
people. All you need to say is "use a different
connection".
DaveO: ok
<dorchard> Glen, maybe "than the anonymous URI" -> "than any anonymous URIs"
<dorchard> ?
Umit: This changes the WSDL 2.0 => SOAP 1.2 MEP binding, and we should be careful to note that.
<dorchard> To umit: 'Something like adding: for example, the WSDL 2.0 binding of WSDL in-out to soap-request-response is changed"
<umit> There is an explicit reference to a single SOAP req-resp MEP which is being broken with this extension.
DaveH: I had a hand in the "not
using anonymous means separate MEPs" wording, and I'm now
unclear on that. WS-Polling might define a special URI which
means poll for the answer...
... We want to be as unrestrictive as possible about the
non-anonymous case
... Drop last sentence of 3.4.2?
DaveO: *goggle* but that's the whole thing!
DaveH: We need to say that when it IS anonymous, it's one MEP, but we can't say the converse... don't exactly know
DaveO: But why say anything then? If we don't have anonymous and don't say anything, how do you know what to do?
Gil: Trying to describe async... how can we not do that?
<dorchard> daveH proposes removing the setnence that talksa bout not containing the anonymous address.
DaveH: XMPP binding (SOAP over Jabber)
(DaveH summarizes binding)
DaveH: Could use XMPP req/resp binding with anonymous and it should work... but it's not clear that anonymous will work with their second binding...
<pauld> TCP connection broken is based on timeouts
DaveO: What should we be doing differently here?
DaveH: Option B = binding over Message is not legit. We need to answer what anonymous means over essentially "dual one way" protocols like XMPP or email...
DaveO: They could do whatever
they want in their binding...
... SOAP MEPs insulate us from binding details
DaveH: Want to make sure anonymous can use "reply addresses" built into protocols, even ones without explicit SOAP req-resp bindings
Anish: What happens if I define a
UDP binding which supports SOAP req/resp and requires
particular usages of WS-Addressing?
... Let's not get into multi-binding issues, and make 3.4.2.
HTTP specific
Mark: How to track this?
DaveO: I could rework over lunch....
Anish: This is independent of the URI of this document, whether it's the SOAP binding, a note, etc...
(agreement)
Umit: 3.4.1 is SOAP 1.1/HTTP 3.4.2 is SOAP1.2/HTTP... agree with Anish re specificity
Paco: Meaning of outbound message == out in WSDL MEP. If so, would be good to make that more explicit.
<gdaniels> Scribe: gdaniels
DaveH: Not good to say anonymous means "we are using SOAP req-resp MEP"
Glen: Change this to positive...
"when using anonymous do this, when using another URI do the
appropriate thing"...
... Think that might solve both my and DaveH's problems.
DaveH: We don't define what sending to an address URI in an EPR MEANS... except for anonymous/none in the context of HTTP
<uyalcina> i am concerned that we are not discussing the issue at hand.
DaveH: We can do this in pieces, making sure that we're as minimally restrictive as possible.
(discussion ensues, scribe was involved...)
DaveH: 3.4.2 might be redundant with what we already say in the SOAP 1.2 binding
<DaveO> DaveO and Umit have a lot of concern about removing the sentence about non anon address meaning 2 meps.
Mark: Can we let DaveO (and others) go off and edit this over lunch?
(Anish summarizes)
Glen: Prefer wording along the lines of "if using a URI that does not have a special meaning (such as anon, none), use normal SOAP mechanism to send outgoing message in a separate MEP"
<DaveO> Glen, maybe I'll show both?
Umit: This is a practical problem, we should just define anonymous (don't overgeneralize)
<DaveO> "When the value of the response endpoint EPR does not contain a URI that has a specialized meaning (such as anonymous), then any outbound message is not part of the mep that the inbound message is in.
Paco: limit this to HTTP, make it clear other specs can define new things...
gdaniels: +1 DaveO
Anish: This was good discussion, I feel more comfortable now.
<Zakim> dhull, you wanted to make a short comment
DaveH: don't want to preclude case I was talking about earlier with one-way protocols using "return to sender"
<dhull> can declare victory in bite-sized pieces
<dhull> s/rules/roolz/
Glen: We discussed this kind of thing in WSDL... make sure that the contracts expressed at the "higher level" (binding) are not broken by the lower level (endpoint). So should be ok to turn ON more things, but not to turn things that were marked as required OFF.
Umit: Remove endpoint expression of UsingAddressing. Just on binding is much better....
<uyalcina> I am in favor of Proposal 1 and simplifying this.
Anish: Specifying this on port
and not binding is nice...
... that way I can use "canned" bindings (as from consortia)
and then expand them with addressing for my endpoints
<DaveO> Glen, wrt 67/68, another slightly different phrasing is "using a URI that does not have a special meaning - WS-A defines the Anonymous URI - then use normal SOAP ..."
Paco: IBM is also of course behind this proposal
<uyalcina> I noticed this anomaly when I was updating the WSDL document examples, the combinatorics make it harder.
<DaveO> maybe we can short cut this?
Anish: why is expressing anonymous at the port bad?
Umit: you can only express at the binding operation...
Anish: Should allow anonymous to
be specified at the binding level so it can apply to all
operations...
... same for endpoint (applies to all)
(discussion of rollup and defaulting)
<DaveO> issue 69: Proposal #2. "Yes, and don't allow contradiction"
(issue 69, question #1)
<DaveO> Proposal #3: "Allow anon at binding level and IF so, then no Anon at the binding operation level"
Paco: this is a nightmare of
combinatorics...
... don't need control at the port level
DaveO: It's sort of like whether anony is "final" at the binding level...
<DaveO> Proposal #4: XOR Proposal. Can have anon at binding XOR at endpoint
(discussion of proposal wrangling during lunch)
LUNCH
<Paco> then it is 2 hours for lunch
<prasad> Paco it is 1pm in pacific now
<hugo> Scribe: Hugo
This is scribe.perl Revision: 1.127 of Date: 2005/08/16 15:12:03 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/006/066/ FAILED: s/rules/roolz/ Found Scribe: GlenD Inferring ScribeNick: GlenD Found Scribe: gdaniels Inferring ScribeNick: gdaniels Found Scribe: Hugo Inferring ScribeNick: hugo Scribes: GlenD, gdaniels, Hugo ScribeNicks: GlenD, gdaniels, hugo Default Present: +1.604.642.aaaa, TonyR, prasad, Paco:Francisco_Curbera Present: +1.604.642.aaaa TonyR prasad Paco:Francisco_Curbera Got date from IRC log name: 19 Jan 2006 Guessing minutes URL: http://www.w3.org/2006/01/19-ws-addr-minutes.html People with action items: pauld WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]