Web Services Addressing Working Group Teleconference

21 Mar 2005



Abbie Barbir (Nortel Networks)
Rebecca Bergersen (IONA Technologies, Inc.)
Andreas Bjärlestam (ERICSSON)
Francisco Curbera (IBM Corporation)
Glen Daniels (Sonic Software)
Paul Downey (BT)
Michael Eder (Nokia)
Robert Freund (Hitachi, Ltd.)
Martin Gudgin (Microsoft Corporation)
Arun Gupta (Sun Microsystems, Inc.)
Hugo Haas (W3C)
Marc Hadley (Sun Microsystems, Inc.)
David Hull (TIBCO Software, Inc.)
Yin-Leng Husband (HP)
Anish Karmarkar (Oracle Corporation)
Philippe Le Hégaret (W3C)
Mark Little (Arjuna Technologies Ltd.)
Jonathan Marsh (Microsoft Corporation)
Jeff Mischkinsky (Oracle Corporation)
Nilo Mitra (ERICSSON)
David Orchard (BEA Systems, Inc.)
Mark Peel (Novell, Inc.)
Tony Rogers (Computer Associates)
Tom Rutt (Fujitsu Limited)
Davanum Srinivas (Computer Associates)
Greg Truty (IBM Corporation)
Steve Vinoski (IONA Technologies, Inc.)
Pete Wenzel (SeeBeyond Technology Corporation)
Steve Winkler (SAP AG)
Ümit Yalçınalp (SAP AG)
Prasad Yendluri (webMethods, Inc.)
Ugo Corda (SeeBeyond Technology Corporation)
Jacques Durand (Fujitsu Limited)
Yaron Goland (BEA Systems, Inc.)
Paul Knight (Nortel Networks)
Eisaku Nishiyama (Hitachi, Ltd.)
Ales Novy (Systinet Inc.)
Rich Salz (DataPower Technology, Inc.)
Jiri Tejkl (Systinet Inc.)
Mark Nottingham
Prasad Yendluri (webMethods)



Date: 21 Mar 2005

Roll call, select scribe

<scribe> Scribe: Prasad Yendluri (webMethods)

Agenda review, AOB

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.

Call for corrections to the minutes

- 2005-03-14: http://www.w3.org/2002/ws/addr/5/03/14-ws-addr-minutes.html

Minutes of 2005-03-14 telcon approved.

Review action items http://www.w3.org/2002/ws/addr/admin#actionitems

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?


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?


Resolved to instruct editors to remove "(and opaquely)" from definition of Action in core document.

Core and SOAP Binding Issues http://www.w3.org/2002/ws/addr/wd-issues/

Issue i050 - Misalignment of treatment of reply messages and fault messages

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?


RESOLUTION: issue 50 closed with Jonathan's proposal.

Issue i054 - Extending MAPs to add new endpoint types

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.

Last Call Process Requirements

< 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?


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.

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.118 (CVS log)
$Date: 2005/03/23 02:07:49 $