Web Services Addressing F2F Berlin

3 Jun 2005


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


<mnot> Scribe: vikas

i059 (async task force)

Glen: Discussing Asynch Task Force

One way patern being discussed. WSDL group asking coordination group to take lead

Took use cases that went from one way with one transport session to multi way to multiple transport sessions. The group as a whole has come to a consensus at this level on what things should look like

When you start to map this to specification; thats when you come across issues that are still unresolved

mnot: Was there a discussion on one way request/response

glen: Did you accept that as use case
... Did not accept that as use case (correction)

mnot: It would be a nice proof point if you do that

glen: Some of the paths that we will go down will allow us to do it

mnot: clarifying use case: one request response multiplexed over multiple open transport session

glen: We do have consensus that it is perfectly acceptable to bind a single wsdl response to multiple underlying soap meps. We do not yet have a solid consensus, I think, to do that over multiple transport protocols
... I have heard from SAP that that was a wrong headed thing

umit: No that is not right
... If you have capability to present one way ... glemm interrupts... cross talk...

vikas: dialog between umit and glen, too fast to capture

anish: three different ways to do it;

do it as a binding, have multiple meps in different wsdl operations

glen: setting context, take request/request

<pauld> ping

glen: to make it work, we have two proposals
... glen: describing use case which has a timeline issue where reply to may have to be held back depending upon FaultTo
... Need SOAP MEP
... Our decision points: How you think about what is going on with SOAP MEP
... Mr. Chair, Can I help you with something

mnot: I can do it to you

all: laughs

glen: Some flexible SOAP MEP ; in message and flexible out message
... in messaage, don't know the out message until run-time

dhull: asks for clarification

glen: yes can be done
... continues..
... SOAP MEP in general... wheather they are really needed, how to describe binding, capabilities of channels
... interesting conversatio... but where it goes in getting stuff done is probably not going to be too far
... Too much actual process work to try and force ... we need to change SOAP
... What new SOAP meps do we define? What new binding? How many?
... How does that stuff bind in a clean way ?
... Ok, so... decision points

glnem: we have soap mep decision point

and this gets into our wwsdl issues

glen: some was something else in lc 101 discussion
... we decided in wsdl group that ,... well... no... silence.. aahh
... how do we make this discussion relevant to this group

mnot: Can you guys come up with a package that you can handoff to coordination group

glen: SAP/IBM has a proposal for SOAP binding
... Describing the proposal.. use two http connection behind the MEP, generated binding
... potential valid way to go
... another valid way... the ability to make flexible binding, change MEPs mid-flight, use wsdl extensibility to bind at message level and not operation level
... changing hats to sonic
... concerned about problems related to multi connection http binding

dorchard: adding on... cardinality of wsdl meps to soap meps. (1) Map wsdl meps to one or two soap meps (2) 1 wsld req/res mep always maps to one soap meps (3)
... (2) nothing to distinguish soap mep from wsdl mep

umit: soliciting interest in proposal

glen: set deadline, and get a package from task force

dhull: what part of our work hinges on asych tf

pauld: wondering.. interrupted by mnot...
... agrees with mnot

mnot: sharing his perspectives, bring up i59
... highlights concerns and unspoken requirements

<pauld> i was wondering on the packaging of this potential work (note, rec), who was going to deliver it, when and our dependency as a WG upon that work

anish: querying, what are people's dispositions on glen's and dorchard's points

glen: we did not give details to get a brainstorm going

anish: those who have opinions to share them

umit: two approaches are not compatible,

dorchard: are you championing your proposal

umit: no, what is scope of asych TF and WS-A related to this

anish: Just want to know what people think

pauld: communicate succintly, discussing dependency

glen: until TF is resolved, cannot come out CR

pauld: Looking for a decoupling with TF's work and this group's work

glen: no, no ; lets dig into dependencies

mnot: technical and charter dependency
... TF goign on for long time; progress not sufficient
... ready to go to CR with core documents

glen: agrees
... create work package and find a group to host the work
... then the TF's job is done

mnot: if the hosting working group accepts that

glen: may be none of the WG will like any packages

dhull: sharing his perspective
... going over a use case
... wsa is not specificying anything that cannot be put on the wire
... can put up a straw man proposal for how to put wsa on the wire
... wsa can map to soap bindings in multiple ways

hugo: verifying consenss and shares a concern
... the final plan is still not done.

<pauld> they're 99% complete, it's just that last 1% that's a b$#%$r

hugo: accept multiple ways to doing that. take a few ways and move on

mnot: need to decide on CR exit criteria

anish: lot of work has been done even though no final planyet
... have multiple proposals
... describes the proposals
... proposals are concrete

glen: takes responsibility
... for delay

anish: it is not that we are not doing anything

mnot: quantify when the cut-off i

anish: give TF a deadline

pauld: would like to see options as a one pager

mnot: Should regularly monitor TF's status

glen: Take proposals and present to WG

katy: Prioritize proposals

glen: no agreement on prioritites

katy: Usage scenarios discussion and prioritize usage scenarious

glen: 99% is done

dorchard: TF would have ideally wanted to have complete proposals.
... Past month's interesting happenings..
... Multi connection http bindings proposals
... simple paper writing is hard
... options are not clean, overlapping options and sub-options
... We are getting there

pauld: Concrete proposals look like they are quite complicated

dorchard: key issues are wsdl to soap mep mapping

pauld: looks like you are debating requirements

dorchard: we are going to hit the hockey stick and it will happen

glen: Choice between (1) Get something that meets short term requirements (2) Meet longer term requirements. That is the tricky point

pauld: don't cut anymore slack for TF because of time pressures; make decision

glen: TF is seeing light at the end of tunnel
... There is more TF work TBD, would be nice to have a deadline
... Sending something out a few telecons before the next F2F
... thinking out loud.. TF should be done before WSA comes out of CR

dhull: three points (1) Echo glen, good progress 99% done
... (2) Have enough for testing WSA
... discusses the test case
... Some technical decisions will need to be made to proceed with testing
... Confusion relates to mapping wsdl/soap meps to bits on wire
... it depends upon transport;
... giving a concrete example
... spending too much time analysing mappings

mark: 7 minutes to break

jeffm: TF does not have to make decisions, give us options

glen: that is what we are trying to do

<pauld> 2000/2001/2002/2003/2004/2005 will be the year of Web services

jeffm: discusses web services hype that started 4 yrs ago but has not been realized yet
... contrasts this with RPC 20 years ago
... schedule driving the TF may not help. People want more now

dorchard: soap 1.2 binding state machine is the complexity part
... Can use it or design around it
... Cannot change soap binding for asych

jmarsh: *frustrated* TF may push CR until october; unlikely to get traction in indigo
... puts forward a proposal
... move ahead with one way
... Start testing, get Core out

anish: validating his understanding of jmarsh
... instead of spec put a test suite

dhull: test suite might help

anish: Decision Tree is not really a tree
... It is more like a web
... tree nodes are not exclusive

pauld: key concern is schedule
... TF should deliver scenarios

<Jonathan> Proposal: Ask CG to cause SOAP 1.2 one-way MEP to be done; add Dave's one-way MEP to our test harness; TF close - use incubator for these other specs.

pauld: references jmarsh's proposal ; perhaps move with one way binding ; create test scenarious and move ahead

<anish> the important point is to specify things (at least a way) to do this to get interop. Interop is quite important here

mnot: BREAK********************************

<pauld> build test cases based on the SOAP 1.2 Email binding


resuming 10, 9 , 8 ...

mnot: wrapping up
... TFs save WG time
... this TF is successful in doing that; Moving forward we need to make decisions
... Need to figure out if we need to put CR criteria on the TF
... TF should report 2 weeks before next F2F

glen: ok

mnot: 2 constraints, charter asks for asynchrony mechanisms
... the scope for fixing asynchrony does not extend to entire web services
... curious about phone participants
... if the TF cannot give us a package by next F2F, will need to rethink position on i59 and CR
... i60 discussion



jmarsh: refers to mail from 24th

<TIBCO-dmh> Specifizierungsnahmenraümteverscheidung oder so etwas

jmarsh: Dependencies which prevent independent versioning
... Namespace is shared between core and SOAP binding.
... Need to document namespace policy

anish: clarifies dependency with jmarsh; splitting namespace? as suggested by mhadley

discussion between jmarsh and anish; too quick to capture

jmarsh: Reserve namespace for W3C defined specs.
... paco says core and soap binding should be versioned together

dorchard: discusses a scenario of new soap fault code. Is this backwards compatible?
... If it is compatible, use the same namespace

anish: Not true with SMTP binding

dorchard and jmarsh discussion on why core namespace should be closed

mhadley: is a non issue?

multiple discussions triggered by pauld on reserving use of namespace to W3C

continuing discussion on namespace reservation and encroachment by non-w3c

mnot: proposal to drop the issues with no action

dorchard: webarch document provides guidance on documenting namespace

mnot: strawpoll
... Who prefers to split namespace? 3 in person; none on phone
... Who prefers not to split? 7 in person; none on phone
... Not going to split.

dorchard and jmarsh discussion on documenting namespace controls

dorchard: Leave the namespace extensible

anish: why is this a wsa issue? Is a generic issue

rapid discussion between anish and jmarsh on anish's issue. point/counterpoint

mnot: off-topic warning
... i42 reference

mhadley: concern with anyone extending wsa namespace

dorchard: only this group can do it

mhadley: cool

discussion between glen, dorchard, jmarsh too fast to capture

<pauld> two separate issues: anyone else being able to add symbols to wsa namespace and a processor expecting/ignoring unknown values added to the wsa namespace by the w3c

mnot: Close i60 with no action
... That should be for WSDL issues: Time now 11:48pm, Lunch at 12:30pm
... Returning to LC issues

Next set of issues are dealing with LC58

mnot: LC 60 is the next one
... Next LC 79
... Next LC 91
... Finally LC 102
... Source Routing

GlenD: Should not preclude it

close LC60 declining request to support source routing

kate to reply on LC60 to submitter

mnot: resolving other issues can help resolve LC 58

anish: SOAP defines active intermediaries

mnot: move to specific issues

Discussion around lC 79

mnot: are the MAP immutable?
... Let's break for lunch

LUNCH ***************

<pauld> fulminates .. we're rehashing issue 9 and not the LC issue


DaveH: Not asking for semantic changes, just trying to clarify the spec.

DaveH: If we want to talk about it at all, we should be more detailed/precise about refPs, etc

Marc: MAPs targeted at the intermediary

DaveH: immutability is between source and the node the MAP is targeted at

Glen: What about Mark's case? HTTP -> intermediary -> SMTP where anonymous gets "rewritten"?

Mark: proposal is s/gathered by/targeted to/

Mark: Any objection to making this change?

DaveH: Would say "when that intermediary resends..." - active voice is better

Mark: Leave that to the editors?

DaveH: Unclear who's doing what...

Mark: Marc, can you take that on?

Marc: Clarify please?

DaveH: Make clear it's the targeted intermediary that is doing the resending.

DaveH: OK, editorial discretion, move on.

Mark: Yes, move on!

Mark: Any objections?

<GlenD> (no objections)

<GlenD> Next bullet - transport-specific representations

Jonathan: Shouldn't constrain bindings - good enough as is

Paul: Why constrain bindings

DaveH: This is about SOAP bindings not addressing bindings

Mark: Do we constrain this?

Anish: SOAP binding is independent of transports

DaveH: Is it permitted to define SOAP-over-email which lets you leave out WSA replyTo headers?

Jonathan: Can't use this SOAP binding and do that...

DaveO: So answer to 2nd question is "no"

DaveO: Binding is not required to put MAPs as headers, technically

<GlenD> (confusion about meaning of "binding")

<GlenD> UTB = Underlying Transport Binding, "WSA binding" = WSA binding

DaveO: Answer is still "no"

DaveO: I can write a UTB spec which serializes things in any way it wants

Jonathan: The SOAP header block always exists in the abstract, even if not explicitly as angle-brackets on the wire

<GlenD> (general nodding)

Mark: Generally you'd put this info in a primer, not the spec

Mark: Question 3 - is intermediary prevented from changing headers always or just when signed?

Jonathan: Under all circumstances.

Paul: Are we restating stuff from SOAP, or imposing WSA requirements on top (which would make all intermediaries require this spec?)?

Jonathan: SOAP canonicalization composes fine with this, so you shouldn't need WSA-aware intermediaries

Marc: Defaulting prevents you from removing an explicitly specified value...

DaveH: OK, won't beginners ask this same question, or should we just require them to know SOAP better?

Anish: seems like a really heavy hammer...

Mark: Lets's go through rest of intermediary qs first...

Tom: if sig is on whole message, removing a header will screw up signature...

Various: that's a general problem

Marc: I'll clarify this applies when the header in question is being forwarded

Mark: OK, any objection?

<GlenD> (no objection)

Vikas: SOAP spec wins when processing?

Mark: Doesn't do good to say that

Marc: If you need that precedence rule, your spec is broken



<GlenD> Comment 3

<TIBCO-dmh> ping

Glen: What about the "by default" change?

Jonathan: This is about the node, not the role. So it's ok.

<GlenD> (discussion of meaning of "next" and processing model)

<GlenD> (discussion of dynamic routing scenario and various ways to acheive it)

Mark: Change "are" to "MUST be"?

Glen: No, should add "by default"

Mark: Different issue

Mark: objections to closing?

<GlenD> (no objections)



<GlenD> Is this immutable only at infoset layer, or abstract?

<GlenD> Proposal is to move this to sec 3

Vikas: Do we need this, since the sentence before takes care of it? End-to-end means unchanged in the middle

Vikas: don't acknowledge message path in the core

Steve: There is a path, regardless of SOAP

Mark: Any objection to moving the text?

<GlenD> (no objection)

<GlenD> 2nd point - refps are mapped as header blocks - can disappear along the path

<GlenD> Suggestion is to exempt refps from this statement

<GlenD> Alternative is to do something to enable end-to-end transfer of refps....

Jonathan: abstraction leaks.. so let's support what we want on the wire and change the abstraction appropriately

Marc: Or we could not say anything about immutability in the core

Vikas: As long as it's transparent to you, it's end to end.

Jonathan: if we remove this, SOAP binding still acts the same way, so that's fine. If we write a new binding, should we preclude good reasons for changing these things en route?

Mark: Who thinks we should remove both?

<GlenD> 6 votes

Mark: Who thinks we should just remove the latter sentence?

<GlenD> 5 votes

Mark: Not live with either?

<GlenD> no objections to removing both

RESOLVED: LC102 by removing both of the first two sentences in section 3.2 of the core.


Mark: Do we need to do more here?

Vikas: OK by me

<GlenD> (discussion of "by default" proposal)

<GlenD> suggestion is to change wording to "By default, the resulting header blocks are targeted..."


RESOLVED: CLOSE LC58 with no additional changes


<GlenD> (discussion of trust and security issues)

<GlenD> BREAK - 15 minutes

<pauld> Scribe: pauld

LC87 Continued

<GlenD> Scribe: GlenD

Mark: When we closed issue 4 Marc suggested he wanted to see a concrete example of securing an EPR. We said we'd entertain that if it came up in LC. Marc, is that what you're saying here?

Marc: Agreed to close 4 to move forward, but didn't like it. Agreed specifically because we could have an LC issue. Closing it now would be disappointing.
... This seems like a different suggestion than "an example"

Mark: not really
... Willing to leave it open if you come back with an example

Marc: We don't have a security model, just a feel-good statement. Charter says we need one.

Paul: What's the expectation here? Changes, or additions, or test cases?

Marc: To have a security model.

Mark: This is about reopening the discussion we previously had and closed.

Marc: This is about additions to the spec, not changes.

Paul: Is there a way we can compose this on top of what we've got? Also, it would be good to see a concrete proposal here...

Jeff: Marc says we haven't met our charter. If that is upheld, that will hold us up even more.
... better off dealing with this rather than waiting and dealing with it procedurally

Paul: We could produce a separate security document. From a schedule POV perhaps that would be parallelizable

Jeff: Need to consider security as you do base

Hugo: We're talking about security model and "security model" is very vague. We could say we've done the bare minimum.

Mark: Which is what we did before

Hugo: Marc, what are you looking for exactly?

Marc: Specify at least one way of proving that you can speak for both the sender of an EPR and the endpoint the EPR is addressed to. Enables interoperably using the EPR without a vague "well do you trust it or not". If we don't do it, it'll never happen.
... Why even spec it if no one can ship it safely?

Jonathan: Several possible outcomes - close w/no action. AIs for concrete proposals. Close issue in positive way - now that one isn't going to happen at this meeting. As such maybe we should shoot for either closing it or getting AIs?

Mark: Yeah baby

<umit> +1 to Jonathan

DaveH: Nervous about normatively specing any security stuff as opposed to stating general guidelines
... lots of ways to make sure a given msg is OK. Don't want a one-size-fits-all model. Our current stuff isn't very coherent, however. Would be good to do some work on it.

Marc: Not suggesting The One Way to do it - but *a* way everyone can use.

Mark: Worried about this because there's no concrete proposal yet. Suggests a hard problem.

DaveO: sympathetic to Marc's position

Jonathan: Tried to get Gudge re-engaged. We will try and help out with this.

Mark: Let's not make a decision about reopening/closing yet, and see if we can make progress.
... but reluctant to do even that

Hugo: we don't have this idea of three parties - sender, receiver, and EPR minter

(yes we do?)

scribe: simple security model would be OK.

Paul: would be helpful even just to have test cases

Marc: We need a security model

Bob: Lots of good practice out there re: bulletproofing, etc

Marc: yes, but not relevant

Mark: Marc, would you make a proposal?

Jonathan: OK to leave this open today, but in a month, not so much....

PROPOSAL: LEAVE LC87 open, but not reopen i004

Mark: Marc can you give us a proposal ASAP?

Marc: Sure

<scribe> ACTION: Marc will write a concrete proposal for resolving issue LC87

LC55 - Tim Ewald's issue

Mark: let's leave this open for now pending resolution of LC87

Jonathan: should we say something about the fact that you can, for security purposes, refuse to send to an EPR you've been passed.

Anish: is this an issue?

ok, leaving it open for now

MessageID issues

LC75 / 88[

Bob explains the issue and proposal

Hugo: issue with using same message ID for retransmission

(discussion of message uniqueness and retransmission)

DaveH: This doesn't address my issue (neither enforceable nor necessary)

(more discussion)

DaveH: If messageid is optional, this matters a lot less...
... Slippery slope trying to define uniqueness in a useful way. Really asking people to be smart, which is SHOULD and not MUST...

Bob: various reasons you might use ID (correlation, dup detection, etc). Since cardinality is 0..1 it's optional unless expecting a reply

(discussion of the fact that WSA forces you to use MessageID if you are expecting a reply)

Jeff: we havent defined a layered model... transport vs. application vs. RM layers... not clear what the relationship between our spec and that sort of layered model is.

(discussion of requiring it for logging purposes, etc...)

Marc: are we assigning specific semantics to messageID, or just providing a field other specs are building semantics on?

Mark: let's look at other MID-related issues

<pauld> thinks making messageId optional prevents more use-cases than it enables

disagrees, but thinks we could benefit by being crisper about our semantics in general

<pauld> does wonder about removing our ability to use canned test documents though ..

Marc: facing a choice between really spec'ing MessageID as a useful field which people can use or not as desired, and treating it as a useful field with assigned semantics and have it ALWAYS be there.

Bob: if we can rely on semantics of MessageID, then it needs more definition. For instance, a method of constructing IDs which guarantees uniquenes....

DaveH: SMTP already includes a messageID. This may be happening at other levels anyway.
... We don't say anything about it except request-reply. If we're going to require it we should talk about it in way more detail.

Anish: could make it optional in core, but make it req'd in WSDL MEPs...

(discussion of adding a WSDL extension to switch on/off MessageID)

Umit: What if I don't use WSDL, how can I ensure messageID if I need it?

Paul: seems quite useful to have a req'd messageID that's unique, but we dont need to spec how to make it unique
... on the other hand not having it optional makes it hard to use canned docs in testing

Tom: both current reliability specs do their own thing
... worried about us trying to define globally useful thing

Steve: very useful to have this required, for lots of uses

Tom: not a bad thing to have it, but trying to make it work for everyone is hard/ill-advised

Anish: WSRX has begin/end along with ID, not an IRI... required is useful for monitoring/logging but when you bring in security they can't look at it anyway

DaveO: scalability problem in high-performance apps - messageID doesn't work in some cases.

Umit: this is just like action. messageID, even if it's not well-specified, should be required. Can't implement David's thingy without MessageID anyway (description offline)

DaveH: no problem making ID required in some context, just not for all of WSA

Hugo: why not propose calling it correlationID?

<pauld> an integer messageId is efficient for retrying but you don't need a 'roll-over'. how many Ids you remember within an interaction could just be a matter of policy - save the last 100 messages received etc.

Mark summarizes

two paths - generally useful, or just useful for our purposes (and we should make it more specific)

Jonathan: third path == status quo

Jeff: streaming stock quotes use case... droppage is OK. Some contexts don't need it.

<pauld> notes messageId/correlationId is a commonly used pair of names in protocols .. we'd have correlationId/relationship which jars with this reader

Jonathan: status quo is best we can do

DaveH: is anyone required to check for uniqueness if they're required everywhere?

(all - no)

Mark: Who thinks we need to have messageID be applicable to more than just correlation?


Mark: Just correlation?


Mark: We're a little wishy washy

Jeff: "run away..."

(discussion of optionality)

straw poll:

0) Status quo

1) Make messageID optional in the core, even if reply expected, but in WSDL binding spec we say exactly when it's needed AND create a facility for specifying when messageID is required/not (WSDL extension)

2) Require messageID always

options are -

0) status quo

1) optional in core

2) required in core

0 got 11 votes

0 got 13 votes, sorry

0 got 12 votes

1 got 6

2 got 4

Mark: do we need a vote?

Glen: I'd like to see a vote

VOTE: Close LC86 with no action.

BEA = yes

BT = yes

CA = yes

Ericsson = yes

Fujitsu = yes

Hitachi = yes

IBM = yes

IONA = yes

Microsoft = yes

Nokia = yes

Oracle = no

SAP = yes

Sonic = no

Sonoa = yes

Sun = abstain

TIBCO = no

W3C = abstain

12 yes

3 no

2 abstain


RESOLVED : close LC86 with no action


Jeff: Bob's proposal doesn't qualify the scope of the uniqueness

Mark: is that binding specific?

Tom: TCP connection is scope for HTTP
... binding specs uniqueness?

Jeff: do we say that in the core?

(more discussion of binding-specificness)

Umit says +1 to Jeff (uniqueness is from sender's perspective)

Paul: messages with same ID are same message

Jeff: up to sender to guarantee correctness in that context

DaveH: Better. Doesn't do much about logging, etc...

(discussion about proxies)

Jeff: sending endpoints responsibility to generate new ids for new messages
... allowable to drop dups

DaveO: good to define this based on the idea that the minter defines the scope of uniqueness.
... security specs demonstrate historical precedence of this idea

Bob proposes some text

<scribe> ACTION: Bob to revise his proposal for 75 and 78 and send it to the list

Splitting the WSDL spec

Anish: let's make WSDL 1.1 binding a note, so we don't have to wait for WSDL 2.0 to be done. Not a rec, so W3C won't have a problem with it. Keep WSDL 2.0 binding a rec-track document and move forward with it.

Mark: Would we fold in WSDL 1.1 into the WSDL 2.0 rec when we publish it?

Anish: either way

Marc: OK with this idea, but concerned with scheduling. When would we split?
... don't want to publish it before a last call
... Last call on the whole WSDL thing and then split it. Don't LC a note

Anish: but you can do so (media types note)

Jonathan: What's the difference between a note and a stable WD?

Hugo: details which need to be worked out. Issues with two recs. No issues with a note for 1.1. Rechartering might be needed, though? Easy way to go if in fact everyone wants to go there...

Mark: this might not be something we want to do until issues with WSDL stuff are resolved
... lets let this sit a bit

Hugo: worried about spending time figuring out what to do, and depending on what options we agree on it might add more time...

Mark: no concall on Monday - BUT everyone should be looking at the issues list


Summary of Action Items

[NEW] ACTION: Bob to revise his proposal for 75 and 78 and send it to the list
[NEW] ACTION: Marc will write a concrete proposal for resolving issue LC87
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.126 (CVS log)
$Date: 2005/06/12 10:36:28 $