See also: IRC log
<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? :)
<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.
<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.
<pauld> http://www.w3.org/2002/ws/addr/testsuite/report/
<pauld> http://www.w3.org/2002/ws/addr/testsuite/
PaulD explains the test suite
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)
(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
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
<hugo> Scribe: Hugo
http://www.w3.org/2002/ws/addr/wd-issues/#i070
Umit: the original intent was not to make it so restrictive
MarkN: we just need to look at i056 and soften the wording
Looking at Katy's proposal: http://lists.w3.org/Archives/Public/public-ws-addressing/2006Jan/0047.html
<dorchard> Glen, what do you think of: ]. When the value of the response endpoint EPR contains a value that is intended to be used as an address by a binding (for example, a value other than the WS-Addressing anonymous URI) then
MarkN: do we have a formal concept of "runtime"?
Paco: can we say "in the course of the interaction"?
MarkN: "in the absence of additional information" seems to have been lost when we resolved i056
Proposed resolution: point the editors to the resolution of i056 and especially at "in the absence of additional information", and add an example for it (runtime override)
RESOLUTION: i070 closed with proposal spelled out above
Considering proposal http://lists.w3.org/Archives/Public/public-ws-addressing/2006Jan/0048.html
Umit: thought that you were going to add something about WSDL 2.0 too
<GlenD> note - this would all be much cleaner, I think, if we just allowed the <Address> element to be optional, and stopped using random "special" URIs as markers....
<GlenD> no <Address> == anonymous
<GlenD> another element like <NoReply> == none
<GlenD> easy peasy
<GlenD> pthtbtht
<GlenD> (just sayin')
DaveH: I'm still concerned about the last sentence
... I think it's the wrong way around
... it says everytime you use anonymous, you use req-resp
<GlenD> consider programming analogies like println("don't-print-this-special-string-but-instead-beep")
DaveO: when would you not be doing that?
<GlenD> overriding value spaces is yukky
DaveH: when you use 2 one-way's
DaveO: then you wouldn't be using the SOAP req-resp MEP
Glen: the same way we clarified anonymous by linking it to req-resp, you could introduce a return-to-sender URI
<dorchard> When the value of the response endpoint EPR contains the anonymous address and the request is part of a SOAP request-response MEP [soap 1.2 adjuncts ref], then the response must be part the same SOAP request-response MEP [soap 1.2 adjuncts ref].
DaveH: I could live with DaveO's latest proposal
Anish: what happened to the mention of outbound and inbound?
DaveO: they were replaced by req and resp
Umit: you could say WSDL input and WSDL output messages
Anish: we're all talking about inbound and outbound from a WSDL perspective
... why don't we talk about it refering to those concepts as defined in the WSDL spec in the section about MEPs
... I actually wanted to move this text in this section
DaveO: we already talk about response message in section 5
... I liked the idea that this req-resp terminology was applying to both WSDL 1.1 and WSDL 2.0
MarkN: are we doing wordsmithing?
Anish: all I'm saying is that moving this section to section 5 is going to define clearly, because of the context, the meaning of inbound and outbound
Umit: we have some inconsistencies here
DaveO: what do I need to do for WSDL 2.0 in the text?
[ working on a new revision ]
http://lists.w3.org/Archives/Public/public-ws-addressing/2006Jan/0049.html
DaveO: I'd like to accept this; other decisions we have to make (on the SOAP 1.1 & 1.2 bindings) will not impact this text
MarkN: we could accept this text, and then maybe change the request vs. inbound if needed
Paco: I have an issue with this text
... most bindings don't define what an address is
... this statement is almost impossible to interpret
DaveO: I know where you're going, but we're never going to get anywhere with this
Paco: we could make this specific to HTTP
DaveO: I am uncomfortable with that
<dhull> +2
<GlenD> +3
DaveO: I'm against having 3.4.2 HTTP specific
<GlenD> fo shizzle
DaveO: MEPs are an abstraction layer which is intended to keep us away from this
Paco: yes, but we're talking about protocol-specific artifacts here
DaveH: how is it not a problem with WS-Addressing as a whole?
Paco: this kind of vague general statement is not helping
Glen: we are using address for real addresses, and special behaviors
... as long as we have this, it *is* useful
... what about: "when using a URI which doesn't have the special meaning of anonymous, …"
Paco: yes
DaveO: so you are comfortable with the term "special URI"
... this is at least as vague as "intended to be used as an address"
Hugo: a long time ago, we agreed not to talk about logical vs. physical addresses, and this is exactly what we're doing here
Anish: we need to specify what address we're talking about: To, ReplyTo, FaultTo, ...
<anish> in section 3.2)
Paco: we have 2 options: be very vague, or very crisp
<GlenD> I actually think the "crisp" part is exactly opposite.
<GlenD> I think it's much more crisp to say that there are some special URIs, of which anonymous is one, that cause special behaviour.
<uyalcina> are you suggesting the original version of our joint proposal as the text?
<GlenD> i.e. make the extensibility point explicit
DaveO: I think that Paco wants to say that "non-anonymous URI means using another connection for the reply"
<dorchard> If the value of the response endpoint EPR contains an address that is not anonymous then response message MUST be sent using a separate connection and using the address value specified by response endpoint.
<dorchard> Option #1: make HTTP specific
<GlenD> ...UNLESS something else tells you otherwise. :)
<dorchard> Option #2: If the value of the response endpoint EPR contains an address that is not anonymous then response message MUST be sent using a separate connection and using the address value specified by response endpoint.
<dorchard> Option #3: If the value of the response endpoint EPR contains an address that is intended to be used as an address by a binding (for example, a value other than the WS-Addressing anonymous URI), then response message MUST be sent using a separate connection and using the address value specified by response endpoint.
<GlenD> I think Paco intends that #2 be suffixed with "other specifications may change this"
<GlenD> (in which case it's a little weird for it to be a MUST, eh?)
MarkN: let's talk about the disposition of the SOAP 1.1 document
... the candidates or in this doc or in the WG Note
Jonathan: if in another doc, will there be a ref to it?
DaveO: yes, in this doc
... I was somewhat vague about "when WS-Addressing is indicated"
... you need to have some kind of description language
Anish: it should really be in the SOAP doc
DaveO: yes, you can't have a ref from the SOAP doc to this new SOAP 1.1 binding doc
Jonathan: that makes me not really love this
Anish: if we added a ref in the SOAP doc, would we need to go back with it?
MarkN: what kind of ref?
... is it just informational?
<dorchard> DaveO: Jonathan, if you want to get from soap binding to soap 1.1 one-way binding, then you won't like by value in the wsdl doc because you can't do that reference either.
MarkN: if we add a normative ref to this for the SOAP 1.1 binding, would we have to go back to WD?
Anish: keep in mind that implementations already do that
<uyalcina> It is in the test suite as implemented
Hugo: then I think that it would not be substantive, if it already is what everybody's doing
DaveO: the proposed text could go in the SOAP binding doc
MarkN: so we would transfer this issue to the SOAP binding as a CR issue
Paco: why are we leaning towards a separate WG Note?
<dorchard> Here's what a Note might look like: http://lists.w3.org/Archives/Public/public-ws-addressing/2006Jan/0027.html
MarkN: people feel more comfortable with a separate document, and we heard from the team that a Rec is a problem
<dorchard> Here's what an addition to SOAP Binding document might look like, which I'll update based upon today's discussion. http://lists.w3.org/Archives/Public/public-ws-addressing/2006Jan/0029.html
<dorchard> The SOAP 1.2 Addressing 1.0 Feature changes the SOAP 1.1/HTTP binding
<dorchard> when "http://www.w3.org/@@@@/@@/addressing/anonymous" is not specified
<dorchard> for the response endpoint. In this case, the SOAP 1.1 one-way HTTP
<dorchard> Binding [@@] is in effect
<dorchard> The SOAP 1.2 Addressing 1.0 Feature changes the SOAP 1.1/HTTP binding
Hugo: thinking about whether the change would be substantive or not again, our spec is based on SOAP 1.1, not the WS-I BP
<dorchard> The SOAP 1.2 Addressing 1.0 Feature changes the SOAP 1.1/HTTP binding when "http://www.w3.org/@@@@/@@/addressing/anonymous" is not specified
<dorchard> for the response endpoint. In this case, the receiver of a message MUST use a binding that supports not returning a SOAP envelope in the HTTP response, such as [URI for binding doc].
Hugo: so it may be a substantive change for somebody who doesn't follow the WS-I BP
[ Considering Dave's text ]
Gil: actually, Anonymous *can* appear on the endpoint
... so #1 is incorrect
... for #2, we have a proposal
[ Gil struggling to show the text ]
Umit: I actually changed my mind; I think that there's no problem, and that we should close with no action
Jonathan: I think that the text is not that clear
MarkN: does IBM have any comment about that?
Paco: our proposal is proposal #1
Jonathan: this issue arose because it's not crystal-clear if we can put it in 2 places
Umit: it is very clear in the spec
... for Anonymous
MarkN: what about UsingAddressing?
Paco: so you're saying that UsingAddressing can appear in either place, but Anonymous can appear in both places
Umit: yes, it's very much like Action
Paco: isn't there a default value for Anonymous?
Marc: yes, optional
Paco: I think that this is really confusing
Jonathan: so it would be nice to prohibit UsingAddressing at the endpoint level
Paco: I agree
Jonathan: there's a set of applications where you want to allow things externally
Gil: who really cares about enabling things post-facto?
... I don't understand how it really simplifies the spec
Glen: there could be an industry standard binding
Paco: I think people defend the status quo without really thinking about the consequences
... if you want to enable it at the endpoint level, then you should allow it completely
Option 0: do nothing
Option 1: remove the capability at the endpoint level
Option 2: allow full specification at the endpoint level
Paco: I prefer option 1
Glen: I don't like restricting things unnecessarily
Jonathan: we're not restricting, we're not supporting
... you can always do a version 2
Glen: I'd be happy with the current situation, as it allows you to do async or not
... WS-Policy has this concept of stacked scope, so it's essentially the same thing
MarkN: i021 was resolved by this text
... so IBM is asking us to revisit a discussion
Paco: but there's new information: the Anonymous marker appeared in the meantime
MarkN: do other people see this as new info?
Jonathan: yes
Hugo: to me, it speaks in favor of 2, i.e. not revisit our decision but harmonize
MarkN: who thinks that this means that we need to reconsider i021
5 hands up
MarkN: ok, let's look at the options then
<Jonathan> 0a: no substantive change, but some editorial tweaking to clarify whether appearance at both endpoint and binding is an error or not.
MarkN: can somebody give us a detailed option 2?
Glen: I'm actually not sure it's necessary
Gil: so I'm not backing 2 up
Straw poll: option 0: 5; option 1: 6; abstentions: 4
BEA: 0
BT: 1
CA: 0
Eric: abs
Fuj: abs
Hit: 0
HP: abs
IBM: 1
MSFT: 1
Nortel: abs
SAP: 1
Sonic: 0
Sun: 1
TIBCO: abs
W3C: 0
webMethods: abs
Oracle: 0
6 votes for keeping the sentence, 5 for removing it
6 abstentions
RESOLUTION: i069 is closed with no change
looking at http://lists.w3.org/Archives/Public/public-ws-addressing/2006Jan/0053.html
<mnot_cube> http://lists.w3.org/Archives/Public/public-ws-addressing/2006Jan/0053.html
DaveO: whatever decision we make, we'll have to make changes in the SOAP and WSDL documents
Glen: I think that it might change the reviewer's experience
Jonathan: I'm worried about the MUSTs
Marc: I'm for it in the SOAP document, but I don't want it to knock us back
Hugo: I'm with Marc, but I'm worried it's substantive
Anish: we're doing the same thing in SOAP 1.2
Proposal: include this text in the SOAP binding, not the WSDL binding; if we have an issue when we try to go to PR, move it in the WSDL document
Philippe: will that impact other WG's review? e.g. XMLP?
DaveO: we have most of the XMLP around the table
Philippe: I suggest you ask the XMLP WG
DaveO: I'd rather ask for forgiveness
DavidH: I wanted to point out that this also address CR15
Hugo: there are undefined references in this text; this will affect our going to PR and then Rec
MarkN: can we have a ref to a Note which is still moving?
... actually, we could make some optimistic decisions here
... let's pretend that we have a CR issue against the SOAP document on the use of async
[ Discussing is not(anonymous) is a set that can be treated as a single type of stuff, or if there are other special URIs like anonymous ]
Glen: what about "Please note that other specifications may define other URIs that change this behavior"
[ Wordsmithing on the screen ]
DaveH: this text is still saying that anonymous is the only way to use the response channel
DaveO: no, you can define your special URI
DaveH: but it contradicts this
resulting text sent to the list
Anish: can we ask the Team to investigate?
Philippe: I'd ask all the WS WGs
DaveO: maybe you don't want to encourage that
<dorchard> Summary: accept resolution on screen as resolution of WSDL doc issue 67/68, SOAP CR issue 15, and produce NOTE.
Paco: I need to check how IBM is going to be impacted by this
MarkN: if it's a significant problem, you can raise a CR issue
... any objection?
RESOLUTION: i67, i68 and cr15 closed with proposal
<scribe> ACTION: DaveO to draft SOAP 1.1 WG Note [recorded in http://www.w3.org/2006/01/19-ws-addr-minutes.html#action02]