Date: 21 Mar 2005
<scribe> Scribe: Prasad Yendluri (webMethods)
Mnot: Reviews Agenda..
Additions: Before agenda item 5, I like to talk about (a) Advisory language regarding use of SOAP 1.1
(b) Language regarding opacity. Both are mainly editorial items.
- 2005-03-14: http://www.w3.org/2002/ws/addr/5/03/14-ws-addr-minutes.html
Minutes of 2005-03-14 telcon approved.
2005-01-17: issue 021 - Francisco Curbera to create a concrete proposal for a wsa:engaged marker. PENDING
2005-01-31: issue 041 - Paul Downey to try out the test case submission form and give feedback. PENDING
2005-03-14: issue 042 - David Hull to work with editors to clarify implementation of resolution WRT property extensibility. PENDING
Mnot: DHull can we call this action item Done?
DHull: Yes. Do have an editorial change if we decide to go with status quo semantics.
2005-03-14: issue 050 - Jonathan Marsh to make a proposal for faultTo defaulting. DONE
Mnot: Action item 5. Couple of things in the last call check list:
1. We do not have a clear language to reflect charter requirements that WSDL and SOAP extensions to be marked as for backward compatibility only
Hugo suggested we put a text in intro that WS-Addr is designed to work with WSDL 2.0 and for backward compatibility with WSDL 1.1. And similar text in WS-Addr SOAP document
intro of section 4 SOAP 1.1 Addresing 1.0 extension, where it says SOAP 1.1 extension is provided for backwards compatibility only.
See Hugo's suggestion: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0155.html
Mnot: Any comments or Any objections to instructing editors to incorporate the suggestion by Hgo?
None.
Resolved to instruct the editors to resolve the action as described in Hugo's email.
2. Opacity of URI ACTION: http://www.w3.org/mid/7DA77BF2392448449D094BCEF67569A506E40195@RED-MSG-30.redmond.corp.microsoft.com
Mnot: Proposal was made to remove "(and opaquely)" from definition of Action. A number of people on the list supported it.
Anish: Action is an IRI. I thought opacity meant the receiver of the message to decide
what do with it? Are we trying to say that is not true?
Mnot: The argument is that opacity by itself does not convey much. What is opaque to you might not be opaque to me. Unless we go into
details of architecturally where opacity does r does not apply to Action, it is better not to say anything. That is what I got from the thread on the list.
Anish: I was just looking for the motivation for the proposal.
Hugo: The way Action is defined, it is not liked to sender or receiver but it identifies the
meaning of the message. Then the question is who is this opaque to? It is as opaque as URI.
So word opacity does not add much to description of Action.
Anish: So what we are saying is it is just a URI?
Hogo: Yes.
Mnot: Can we go ahead and remove this? Any objections?
None.
Resolved to instruct editors to remove "(and opaquely)" from definition of Action in core document.
Proposal 1: <http://www.w3.org/mid/20050215151434.GD13607@w3.org>
Proposal 2: <http://www.w3.org/mid/20050215151434.GD13607@w3.org>
Proposal 3: <http://www.w3.org/mid/20050215151434.GD13607@w3.org>
Proposal 4: <http://www.w3.org/mid/20050215151434.GD13607@w3.org>
Proposal 5: <http://www.w3.org/mid/422CDD31.4050605@coastin.com>
Proposal 6: < http://www.w3.org/mid/7DA77BF2392448449D094BCEF67569A506D5FC27@RED- MSG-30.redmond.corp.microsoft.com>
Mnot: Last week we went a lot in circles on this. Jonathan took an action to make one more try (proposal 6). Jonathan: Tom had a proposal to set the fault endpoint property to be replyTo endpoint property if there was no faultTo element. Instead of defaulting these
properties, I wanted to describe these as rules for formulating the reply messages.
This makes a smaller change to the model than Tom's as this is applicable when
formulating the reply message according to the rules of the spec. If you are
formulating reply according rules of another spec, this is not applicable.
Mnot: Is this the complete proposal for resolution to issue 50.
Jonathan: Yes. If people are happy with the proposal we can close issue 50.
Mnot: Time limit of 20 mins for discussion of this issue.
Tom: I like Jonathan's proposal. I gave up on defaulting replyTo.
Happy to close the issue.
Glen: At the tech plenary there was interest in defaulting to replyTo. What changed last week? Summary of conversation?
Tom: ReplyTo is always available to intermediaries.
ReplyTo means Reply is always expected however you send it. Glen: In WS in general everything you need to know isn't always in the message.
You can't guarantee it.
MarcH: Don't understand the difference between this proposal and the defaulting one.
Jonathan: You mean Tom's proposal? The end result is same in this case.
MarcH: In what case would it be different?
Jonthan: If I have an extended MEP with ReplyTo, FaultTo and another ReplyTo. When you
introduce that MEP you may need to introduce different rules for formulating the replyTo.
You may not want faultTo prop to default to replyTo in that case.
DHull: The rules really depend on the scenario. From intermediaries to Profiles.
I am in favor anything that limits the scope.
Hugo: Like to seek clarification from Jonathan reg. his proposal more flexible than Tom's. Section 3.2 is about formulating reply message. It is not tied to any particular MEP.
Any time we want to formulate a fault this rule is going to apply. So it is not different from Tom's. Jonathan: I think it works better when we keep abstract props close to syntax.
Hugo: ..(sorry missed it)
Jonthan: So in WSDL say, when formulating a reply message use the core WS-Addr spec..
Hugo: I like it that it is not tied to the syntax. I prefer status quo.
Tom: Jonathan's proposal talks about what goes on the wire. It is more robust.
DHull: Not sure where this is applicable and where not. Unsure also on where is the WSDL binding applicability. So, what is in scope?
Umit: I like Jonathan's formulation
MarcH: What is status Quo?
Jonthan: If there is not faultTo we don;t send a fault.
DHull: Send back to sender is logical default for FaultTo
Glen: It is not always obvious .. (?)
DHull: That is why mentioned having From as the default for Fault as opposed to, replyTo
Glen: What does anonymous mean? In case of HTTP we know what it means..
Mnot: Paul set up the poll in irc:
<pauld> chad, option 1: status quo
<pauld> chad, option 2: jonathan's proposal
<pauld> chad, option 3: stuff happens
<pauld> chad, option 3: none of the above
Monot: Option 3 means you are not satisfied with 1 or 2.
<RebeccaB> chad: 2,1,3
<pauld> vote: 2, 1
<Gudge> chad: 2, 1, 3
<bob> vote:2,1
<hugo> chad: 3, 1, 2
<gdaniels> vote: 3, 1, 2
<TonyR> chad: 2, 3
<Marsh> vote: 2,1,3
<TomRutt> 2, 1
<uyalcina> chad: 2, 1
<MSEder> vote:2,1
<marc> chad 2, 3, 1
<pauld> vote: pete: 1
<dhull> vote: 3
<mlpeel> vote: 2, 1
<Marsh> chad: 2,1
<dorchard> vote 2,1
<stevewinkler> vote: 2,1
<GregT> vote: 3, 1, 2
<anish> chad: 3, 2, 1
<Nilo> vote: 2, 1, 3
<vinoski> chad: 2, 1, 3
<dorchard> vote: 2,1
<abbie> abbie vote 2, 1, 3
<marc> vote: 2, 3, 1
<Arun> chad: 2,3,1
<prasad> chad: 3, 2, 1
<TomRutt> vote 2, 1
<abbie> vote: 2 1 3
<pauld> chad, count
<chad> Question: unknown
<chad> Option 1: status quo (1)
<chad> Option 2: jonathan's proposal (17)
<chad> Option 3: none of the above (7)
<chad> 25 voters: abbie (2, 1, 3) , anish (3, 2, 1) , Arun (2, 3, 1) , bob (2, 1) , dhull (3) , dorchard (2, 1) , gdaniels (3, 1, 2) , GregT (3, 1, 2) , Gudge (2, 1, 3) , hugo (3, 1, 2) , marc (2, 3, 1) , Marsh (2, 1) , mlpeel (2, 1) , MSEder (2, 1) , Nilo (2, 1, 3) , pauld (2, 1) , pete (1) , plh (3, 1, 2) , prasad (3, 2, 1) , RebeccaB (2, 1, 3) , stevewinkler (2, 1) , TomRutt (2, 1) , TonyR (2, 3) , uyalcina (2, 1) , vinoski (2, 1, 3) <chad> Round 1: Count of first place rankings.
<chad> Candidate 2 is elected.
<chad> Winner is option 2 - jonathan's proposal
<GregT> vote: 2,1,3
Mnot: Why did 7 people vote for something else?
Greg: I thought jonthan's was ok but I like to go little further. Did not realize for Anonymous we left it unknown.
At least for HTTP we should have clearly specified.
Gudge: That is a separate issue.
Greg: Yes that is why I changed vote.
Glen: I can relate to some of the concerns raised. Issues might come up during usecases for test
collection. Mnot: It might come up during LC
DHull: I agree with that also.
Prasad: I like jonthan's proposal but but I was not sure what we really meant by unconstrained.
So voted for three. If we had some specific laguage that clarified that, it would have been better.
But 2 is ok.
Anish: I am in similar boat as Glen. I would be happy to go with 2 or 1. Prefer 1.
DHull: I am not against 2 either..
Hugo: I voted for 3 as I thought there are better solutions. But I strongly feel we should close this issue. Mnot: Many people are willing to go with 2 for time being, realizing we may need to revisit.
Mnot: Any objection to closing issue 50 with proposal 2?
None.
RESOLUTION: issue 50 closed with Jonathan's proposal.
Proposal 1: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0167
Proposal 2: http://www.w3.org/mid/423EF1B7.6060400@tibco.com
Proposal 3: http://www.w3.org/mid/7DA77BF2392448449D094BCEF67569A506E40442@RED-MSG-30.redmond.corp.microsoft.com>
Glen: Is this the issue reg. ReplyTo and FaultTo endpoints being replaced with a Bag of
relationship pair of endpoints?
DHull: It is endpoint-name and
endpoint value pairs. You would have replyTo and replyTo value,
faultTo and faultTo value etc. If I wanted to add my own, it would
go in the bag under that.
... The proposal 1, is to support fully general interactions, at
the abstract level instead of having two special endpoints called,
have a bag of endpoints that can be extended to whatever you
want.
Anything you add to the bag will have an attribute like reference parameters.
Paul: I am missing what the problem really is? Why is the spec not extensible the way it is now.
DHull: If want to define an alternate-replyTo property, I need to define an entirely new SOAP module.
We should be able to extend the benefit of defining replyTo and FaultTo endpoints, we ought to be
able to extend that benefit to other endpoints.
Anish: MAP's are not extensible
DHull: Proposal 2: We put in a disclimer near top of section 3, that says Messages addressing properties
provide references to endpoints involved in request/reply interactions and for other interactions
where a reply and fault endpoint suffice. Endpoint refs for more complex interactions must be handled
outside this fwk, by defining separate abstract properties ...
Anish: So this proposal says, we will kep status quo. MAPs would not be extensible.
WS-Addr would not provide necessary extensible props for enabling additional MEPs. But we will provide a clear guidance in the spec. Is that correct?
DHull: Yes, we will not change the actual semantics.
Jonthan: We have not talked about any mechanism for adding additional msg addressing properties
beyond additional endpoints. That is where this needs to go.
Anish: You want to separte the addintional MEPs issue from this one?
Jonathan: No. We already have a bag in the spec. You don't need to name the bag to add additional properties.
Anish: In the abstract model. There is no bag. It is a list properties but this is a closed list
Jonathan: But you can add additional properties. They won't be in WS-Addr namespace
DHull: So you are saying you can cover additional endpoint because XML itself is extensible?
Gudge: Exactly what we are saying
DHull: We need a way to tag endpoints of interest. We specifically called out
faultTo and ReplyTo. I want to generalize that distinction.
Jonathan: Today simple things are simple. ReplyTo is a direct property. With this proposal we make complex case easier, while making simple case complex. Less direct mapping from syntax to property. It adds some complexity which is not worth it at this point.
DHull: I don't understand. It is exactly same on the wire.
Jonathan: Your are suggesting to add a new attribute. Then we have to define the semantics of
that attribute. What headers can that be aplied to etc. Less direct mapping from syntax into property. More transformation going on. It helps complex case but I don;t think it
is not worth it at this point.
DHull: Everybody wants simplicity but we disagree on what is simple.
Umit: Other from Jonathan, it seems is more clear not too restrictive, if you want add on top of what WS-Addressing provides.
<mnot> Jonathan's version of proposal 2: [[[
<mnot> Delete the "any" from the 3rd p of Section 3 as follows:
<mnot> "Message addressing properties collectively augment a message with the
<mnot> following abstract properties to support one way, request reply, and
<mnot> other interaction patterns:"
<mnot> Add a paragraph immediately preceding the 3rd p of Section 3 as follows:
<mnot> "The set of message addressing properties defined in this specification
<mnot> is sufficient for many simple variations of one-way and request-reply
<mnot> MEPs. More advanced MEPs may require additional message addressing
<mnot> properties to augment the facilities provided here. "
<mnot> ]]]
Dhull: To me it is not clear how you add message addressing properties.
Umit: Addressing properties are
indeed extensible. But we are not defining them. DHull: There has
to be a specific mechanism
... That is what I am trying to distinguish. Is it possible or do
we actually define the mechanism
DHull: If we can define how one can add additional properties after the fact fine. But we don't.
<Marsh> You just write a spec :-)
<Marsh> Do we need to tell people how to do that?
<gdaniels> +1
<anish> the point is that MAP are not extensible. Yes, one can write a spec to do anything. But ws-addr does help you in any way and the argument is that ws-addr should
<anish> s/ws-addr does help you/ws-addr does not help you/
Mnot: We have 3 proposal:
1. To change the property Model
2. Jonathan's text says you can add message addressing properties but does not tell you how.
3. DHull text that says, you cannot add addressing properties. You have to do it outside the framework just related to fwk. <uyalcina> the question is whether we prevent people doing it or not
<Nilo> can we make [reply endpoint]: EPR (0..max) where max>1
Gudge: I don't see how our spec is not extensible. Anobody can write a spec that says this spec adds these addtional props to those defined by WS-Addr. You can nnot prohibit that.
W.r.t. having a Bag with QName with a URI attribute to denote new properties tied to endpoint refs,
I don't see why that is a superior solution to defning a new QName tied to an endpoint refs. They would
be as understandable as a new URI is.
<plh> I wonder how this issue is different from extending the Infoset itself
<uyalcina> +1 to Glen
<Marsh> Not at all, I think
<plh> the XML Schema WG didn't wait for approval to create the PSVI
<Marsh> We're just arguing about whether extensions can be called "WS-Addressing 1.0 MAP".
<Marsh> In the end it doesn't matter what they're called, just how they behave.
<dhull> "Understanding" is not binary. Three levels (at least): 1) I just know it's a SOAP header. 2) I know it's an EPR that's active in an MEP (but I don't know or care which) 3) I know it's the alternate-replly EPR. We don't have (2) right now. Do we want it?
Mnot: I have updated the proposal list 1, 2), 3)..
Anish: There is a 4th proposal from MarcH
Mnot: It is not complete at this point
<TonyR> If we define how to extend MAPs, then an intermediary written to this spec can say "oh, that is an MAP" without understanding it. I don't know if that is useful
<dhull> Can we categorically say it would never be useful?
<Gudge> If it turns out to be useful, then some other spec can define it
<dhull> As I said, that's not enoiugh info ...
<Gudge> Not enough info for what?
<dhull> ... you could have EPRs there for other resons. It's like saying "if it's an int, it must be a buffer size"
<Gudge> The same could be said of your proposal
<TonyR> If we define how to extend MAPs, then an intermediary written to this spec can say "oh, that is an MAP" without understanding it. I don't know if that is useful
<dhull> Can we categorically say it would never be useful?
<Gudge> If it turns out to be useful, then some other spec can define it
<dhull> As I said, that's not enoiugh info ...
<Gudge> Not enough info for what?
<dhull> ... you could have EPRs there for other resons. It's like saying "if it's an int, it must be a buffer size"
<Gudge> The same could be said of your proposal
MarcH: There was a question on my proposal is that requires a schema validation. I want to point out that is not the case.
Anish: David Hull withdrew his proposal in favor of MarcH's. So we need to get into detail of..
TomR: Lets worry about extensibility of abstract properties as a separate exercise during LC. Marc's proposal is somethingwe can do quickly. I like Marc's proposal..
Mnot: We do need to discuss the implications on last call
Jeff: Everythibg is extensible. So you can do anything you want. <Marsh> But your intermediary case looks for destinations that "might" participate in the exchange.
<marc> having a wsa:address child element does not an EPR make
<Marsh> If you have some extras in there that are never used, so what?
<dhull> No, because the EPR world is then divded into those that are live in MEPs and those that aren't
<marc> it might be an epr, it might not
<Gudge> marc, I actually think that having wsa:Address child DOES an EPR make 'cause wsa:Address is a local element
<marc> without additional info you can;t say
<marc> ah, missed that subtelty
<Gudge> I guess someone *could* define a new spec, with an Address element in our namespace, but that would be *very* weird
DHull: Why don;t we take out everything other than replyTo..
<marc> taking them out wold run counter to the 80/20 rule
<Marsh> Bummer if the core couldn't be used at all without extension...
<Gudge> +1 to marc
<dhull> Marsh: Why would that be bad?
<TomRutt> yes
<dhull> Marsh: It would considerably improve the extensibility story.
DHull: Asynchronony.
Mnot: At this point we have 3 proposals on the table
1. Proposal 1, David's proposal to rework the model so that there is an endpoints bucket
2. Proposal 2, to modify current spec to make explicit that properties are extensible bag
3. Proposal 3, David's proposal to clarify current text that bag of props is a closed set
and if you want add more propos do it outside the scope of this spec.
They are on the issues
4. MarcH 's proposal which I think needs more work.
Mnot: Does anyone see working on MarcH's proposal as first choice in different options?
Anish: I do.
Glen: Me too.
DHull: I would have it as a second choice
JeffM: What is difference bet 2 & 3? It is a matter of what you call your extension.
Gudge: Don't see diff bet 2 and 3
DHull: Couple of differences. Needing
to define properties in separate soap modules.
... It details when you have do this as this extension.
<anish> jonathan: didn't you withdraw your proposal in favor of david's proposal # 2 on the ML. did i get that wrong?
<pauld> chad question: proposals for i054
<pauld> chad, question: proposals for i054
Mnot: Marc Can you summarize your proposal
MarcH: Summarizes...
Mnot: 1&4 are similar, 2&3 are similar
<pauld> chad, count
<chad> Question: proposals for i054
<chad> Option 1: [endpoints] MAP with (qname, EPR) tuples (dhull) (2)
<chad> Option 2: Clarify existing MAP extensibility model. (Marsh) (14)
<chad> Option 3: Clarify that MAPs aren't extensible. (dhull) (0)
<chad> Option 4: work on marc's proposal (9)
<chad> 27 voters: andreas (4) , anish (4, 1) , Arun (4, 2, 1, 3) , bob (2) , dhull (1, 4, 3) , dims (4, 1) , dorchard (2) , gdaniels () , GregT (2) , Gudge (2) , hugo (2, 3, 4, 1) , jeffm (1, 4) , marc (4, 2, 1, 3) , Marsh (2) , mlpeel (4, 1) , MSEder (2, 3) , Nilo (4, 2) , pauld (2, 3) , plh (2, 3, 4, 1) , prasad (2, 3, 4, 1) , RebeccaB (2, 3, 1, 4) , stevewinkler (2) , TomRutt (4, 2) , TonyR (4, 2, 1, 3) , uyalcina (2) , vinoski (2, 4) , vote () <chad> Round 1: Count of first place rankings.
<chad> Candidate 2 is elected.
<chad> Winner is option 2 - Clarify existing MAP extensibility model. (Marsh)
Mnot: 14 for 2. 9 for 4.
... If we can go to last call today we can schedule the lC to end
right before the next F2F.
... This can be adjusted in last call. This does not affect
implementations. So, People with MarcH's proposal as 1st choice, do
you object to closing w/ option 2 ?
... Doing that is going to push us by at least one week.
MarcH: My proposal was an attempt to make all happy. I am happy with option 2..
DHull: Everyone agrees that extensibility is good. But the poll seems to imply status quo is sufficiently extensible. So, I won't object now but I need to understand the process better.
<TomRutt> I can live with 2 for now
Anish: I can't live with option 2. We need to explore option 4.
Gudge: Should we take a formal vote?
Mnot: We should probably vote. Charter says once we had discussion and considered all input we should vote. I am not sure if we have further input at this point.
DHull: Overall question is, is the current extensibility considered adequate?
Jeff: MarcH has 9 votes. Wondering if we should try and produce a fully fleshed proposal?
Gudge: It would not work for me. Proposal 4 is same as proposal 1.
Mnot: We should go ahead and
vote.
... Vote close issue 54 with proposal #2.
Proposal 2 is at the bottom of <mnot> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0199
<gdaniels> argh - I agree with proposal 2, but also feel further discussion of the relationship between MEPs and MAPs is warranted. Sigh.
<anish> glen - then vote no :-)
<gdaniels> Yeah, but I *don't* agree with prop 1/4 either...
MNot: Formal vote by company
name
... Vote: Yes (11) No (4) Abstain (2)
Yes: BEA, BT, CA, Ericson, Hitachi, IBM, IONA, Microsoft, Nokia, SAP, W3C
No: Fujitsu, Novell, Oracle, TIBCO Abs: Sun, Nortel Not called: Sonic, webMethods
Mnot: Of the No's Anyone wants to raise formal objections
DHull: It is possible
TomR: If it is editorial, I might assert my right to do so during LC
RESOLUTION: issue 54 is resolved with proposal 2
Jeff: Did we have to formally object now, or could we reserve the right?
Mnot: Formal objection happens during the last call process
DHull: If we go into LC is there a possibility that we can still make changes if come to consensus:
MNot: As long as it does not impact implementations. Like if we change something in abstract model.
If it is substantial change we have to go for a second LC.
DHull: Do you consider proposals that leave ReplyTo and FaultTo on the wire as they are, impacting implementations?
MNot: We need to discuss it but, if it does not impact the wire signature it is in the ballpark.
Plh: It is not regarding implementation, it is about comments. If we make a change that impacts a comment from a group or individual the we can not go to CR. Making a change to implementation
does not mean we cannot move to CR. It is about comments not implementation.
Mnot: I see. So there is wiggle room there.
< http://www.w3.org/mid/a176d7de7bb8ef6bbed25c5b7e929cd8@bea.com> MNot: Wanted to discuss the process to go to last call.
MNot: At this point we closed all
issues related to Core and SOAP document. Editors will make changes
resolved today
... Do we feel we are ready to go to LC?
TomR: Do we have a doc that is stable?
Mnot: It has been stable for a while but for the changes we approved today
Anish: I like to see the last call doc with changes in
Glen: Me too. We can put this as the first item on the agenda next week
MNot: If we can today, we can request a LC comments period that ends prior to our next F2F
Jonathan: We can make any comments on this draft LC comments..
MNot: Next Mondays is after easter. Anyone one have a holiday
Several TC members have holiday.
Jonthan: If we go LC today, we can take next week off
Jeff: You are rushing this
Gudge: Call to vote on going to LC
Anish: Going to vote on going to LC on doc we have not seen?
Jonathan: If you have seen the doc for couple weeks, you have seen the specific changes we adopted today.
MarcH: Suggestion. Vote on to go to LC unless we hear comments before Wed?
Gudge: I would be happy with that
Mnot: Can we have all changes checked in by EOD today?
Gudge: I would do it.
MNot: Formal vote to approve to go to last call of Core and SOAP binding docs unless we hear an objection from a member in good standing by EOD Wed (3/23/05) by boston time?
Any objections?
None.
RESOLUTION: Take Core and SOAP Binding docs to Last Call, unless there is an objection by EOB Wednesday.
Jonthan: Can I move that we hold next week's call only if we do have an objection to the LC?
MNot: Yes. I will go ahead and cancel the call if I have not seen any objections by the deadline.
End of call.