Web Services Addressing Teleconference

approving minutes

July 11 minutes approved

July 18 + 19 minutes approved

draft review

no issues with drafts

Candidate Recommendation discussion

status section okay

substantive change okay

features at risk

no more features identified at risk

<anish> how are we identifying features?

four interoperable implementations enough?

<RebeccaB> +1 on Jeff's requirement

each implementation has to support all features?

That is, all features identified on test suite

mnot: 4 implementaitons of every feature; 2 complete implementations?

<mnot> Text from Charter: A test suite intended to promote implementation of the Candidate Recommendation, and to assess interoperability between these implementations. The Working Group is expected to demonstrate four interoperable implementations during the Call for Implementations step.

<Zakim> anish, you wanted to ask about how we identify features

anish: how will we identify features? 4 interoperable implementaitons for each feature?

mnot: yes

uyalcina: what is process with CR?

mnot: explaining process

plh: looking for complete implementations, but may make exception for optional features

<uyalcina> I presume "should" is considered to be optional for this discussion?

<anish> umit, that is a good question, i think this is the sort of thing that we need to decide when we identify features

<pauld> heard the sound of combinations exploding ..

<uyalcina> people are talking about "required" vs. "optional". I would like to clarify what that means.

various combinations of required, optional features discussed, and

and how the four implementations are mapped to the features

mnot: recommendation is per implementation, not per feature

should optional features be required to have an implmentation count as one of the four interoperable implementations?

mnot: if both mandatory and optional features are required in 4 implementations, we may want to mark some of the optional features as "at risk"

marsh: nothing wrong with profiles
... there is a demand for profiles in the industry, as seen in the mobile phone industry

jeff: we have an obligation to ensure we have real interoperability

TRutt: optional features need to have at least some implementation; maybe only 2-3 impementations supporting them

Paco: 4 full implementations should be a given, but there should be some flexibility - so we are not gated by waiting for four full implementations of every feature

<jeffm> thank you :-)

daveo: if there is aproblem with some optional feature, we should catch that. SOAP 1.2 had the bar of at least 2 interoperable implementations of each feature. We should have a higher bar.
... 4 implementations of mandatory features is needed.

anish: 4 impl. for each mandatory feature

mnot: 4 instances of implementations with all mandatory features plus ...

<Zakim> plh, you wanted to ask the Group about who is planning to provide an implementation

mnot: plus 4 implementations (not necessarily full) of optional features

plh: who is planning implementations?

answers from: IBM, BEA, Apache, Microsoft, also Oracle (not committed to full implementation)

fujitsu, hitachi also speak up

<jeffm> a more precise statement for Oracle is no data for complete impl -- just not sure what our product plans are at the moment

<Arun> Sun also said they'll have an implementation

Also, iona, sun

mnot: we are not asking for commitments, these are directions of product plans
... what is appropriate bar for numbers of implementations? 4 full and 4 for each optional feature.

<anish> there is no such thing as 'feature' in the charter

jeff: 4 implementations of everything

mnot: 4 implementations of entire stack with all options

the requirement is not for products, but for W3C to be able to assert that there is an interoperable base, to vet the spec

plh: uncomfortable if not have 4 complete implementations of required features

<MSEder> fine

<Zakim> pauld, you wanted to ask about consequences

Marsh: worried about extending schedule if we only have 3, then waiting for another one; if we can be more flexible with support for optiona features we can finish earlier

PaulD: what are consequences of not having the implementations all complete? What is the definition of a "feature" (as anish asked)?

<uyalcina> +1 to Paul. I have exactly the same concerns.

<jeffm> seems like SHOULDs are optional

<jeffm> MUSTS and MUST NOTS are mandory

<TonyR> Isn't "MUST" mandatory, "SHOULD" or "MAY" optional

<Marsh> I like a slightly higher-level concept of feature, possibly wrapping several MUSTs and SHOULDs.

<jeffm> MAYs are also obviously optional

<jeffm> sure --

mnot: we will need to define this clearly, since we have not always used RFC2119 language precisely.

<vikas> +1 to Pual

<uyalcina> Itis not simple. Take ReplyTo. Is it optional with respect to the core ? Is that a feature? Our charter talks about async. Is it required?

PaulD: we may need to have the test suite in front of us to identify or mark each one as required/optional

mnot: that would require us to NOT go to CR now.

<jeffm> i'm not trying to imply its simple -- i'm just starting with the obvious consequences of MUST/SHOULD/ etc.

<uyalcina> Agreed Jeff. However, the specs are not writted with the RFC2119 language to make the determination well.

TRutt: there is not much that is optional in this spec... The options are on the sending side. Maybe every receiver must be able3 to handle all options?

<Marsh> +1 to mostly academic

<dhull> +1 to Tom. The direct constraints are on the receiver.

<anish> we need to look for assertions beyond 2119 assertions as well -- for mandatory features

mnot: maybe based on test suite, it will determine if we can get out of CR phase (?)

<Zakim> dorchard, you wanted to point out that "to demonstrate four interoperable implementations" can easily be interpreted as 4 interopable impls of each feature.

uyal: need better definition of required/optional

dorch: charter is not clear about "full implementations"

<MSEder> Thats why I asked plh to answer that

<Arun> stepping out for a minute

jeff: the reason for setting these quality criteria is to show that we have it right, by getting several inplementations interoperating.
... possible compromise - we need to clarify what is in the charter, because there are various interpretations - suggest 4 full implementations of mandatory, plus:

<Arun> back now

jeff: plus 2 implmentations of each optional features (?) (missed a bit, this is 4-4-2 proposal)

Marsh: waiting for implementations will delay the spec; some will wait to implement
... 2 absolutely complete plus 2 with all mandatory (4-2)

<prasad> +1 to above. IMO Optional stuff cannot exist independent of Mandatory one. Sometimes we seem to be speaking as if they are disjoint and implemented and tested independently.

Marsh: 4 with all mandatory, plus 2 of those with all required features (this is 4-2)

<anish> there are three proposals: 4-4-2, 4-4 and 4-2

jeff: agree except that charter says 4

<vikas> Do we need to agree on a use case to showcase these implementations? How do we define a features is implementable?

mnot: mlh said that 4-2 is likely to be acceptable

PaulD: still concerned about setting the bar too high, slowing things down, what is process for deleting features to get through CR?

<uyalcina> If we can identify what is optional, then you can mark them at risk, which is not easy...

<jeffm> that seems reasonable, in a weird way --

plh: if features are noted as at risk, they can be dropped during CR, but cannot get out of CR if they are not marked at risk and are dropped

<jeffm> it meets the quality bar which is my concern

<TRutt> I can live with 4/2

mnot: how do people feel about 4-2?

<bob> just drop all of the optionals now and be done with it

<Katy> I like the 4-2 proposal

jeff: 4 complete implementations of all mandatory features; two of those also implement all optional features. This is 4-2.

<Zakim> uyalcina, you wanted to ask a question.

jeff: straw poll?

uyal: if we do 4-2 should we mark features at risk?

Marsh: no

<pauld> i'd be happy to accept Jonathan's proposal AIUI, but worry what happens if one or two optional 'features' don't hit the 2 bar

invite: chad

<uyalcina> I do not want to mark optional features at risk. It is solving a problem in the wrong way.

<jeffm> to respond to paul: then we've learned that they are not well specified, and they need to be fixed/dropped

<RebeccaB> I really don't like the idea of marking all of the optional features 'at risk' so they can be dropped later!!

<pauld> chad, say hi

<Marsh> chad: option 2: 4-4 proposal: 4 complete of mandatory features, + 4 implementations of each optional feature.

<TonyR> chad: option 0: status quo

<Marsh> chad: option 3: 4-2 proposal: 4 complete of mandatory features, of which 2 also implement all optional features.

<mnot> chad: option 1: 4-4-2 proposal: 4 complete of mandatory features, + 4 implementations of each optional feature, + 2 complete implementations of each optional feature

<pauld> chad, question: meaning of "4 interoperable implementations" for CR exit

<TonyR> chad: options?

<uyalcina> +1 mnot

<abbie> vote: 3

<vikas> vote: 1

<RebeccaB> vote: 3

<jeffm> vote: 1,3,2

<Marsh> vote: 2, 3

mnot: one vote per company

<mlpeel> vote: 3, 2

<Arun> vote: 3,1,2

<TonyR> vote: 3, 1, 2, 0

<abbie> vote:0,3

<prasad> vote: 2, 3

<MSEder> chad MSEder votes: 3

<uyalcina> vote: 3

<Nilo> vote: 2, 3

<TRutt> vote: 3,2

<Paco> vote: 3, 2, 1, 0

<dorchard> vote: 3,2

<pauld> vote: 2,3

<yinleng> 3,2,1

<dhull> vote: 3, 2, 1

<bob> vote: none of the abov

<GlenD> vote: 3,2

<Pete> vote: 2,3,1

<MSEder> vote: 3

<uyalcina> vote: 3, 2

<pauld> chad, option none: none of the above

<pauld> vote: bob: none

<pauld> chad, count

<chad> Question: meaning of "4 interoperable implementations" for CR exit

<chad> Option 0: status quo (1)

<chad> Option 1: 4-4-2 proposal: 4 complete of mandatory features, + 4 implementations of each optional feature, + 2 complete implementations of each optional feature (2)

<chad> Option 2: 4-4 proposal: 4 complete of mandatory features, + 4 implementations of each optional feature. (5)

<chad> Option 3: 4-2 proposal: 4 complete of mandatory features, of which 2 also implement all optional features. (11)

<chad> Option none: none of the above (1)

<chad> 20 voters: abbie (0, 3) , Arun (3, 1, 2) , bob (none) , dhull (3, 2, 1) , dorchard (3, 2) , GlenD (3, 2) , jeffm (1, 3, 2) , Marsh (2, 3) , mlpeel (3, 2) , MSEder (3) , Nilo (2, 3) , Paco (3, 2, 1, 0) , pauld (2, 3) , Pete (2, 3, 1) , prasad (2, 3) , RebeccaB (3) , TonyR (3, 1, 2, 0) , TRutt (3, 2) , uyalcina (3, 2) , vikas (1)

<chad> Round 1: Count of first place rankings.

<chad> Candidate 3 is elected.

<chad> Winner is option 3 - 4-2 proposal: 4 complete of mandatory features, of which 2 also implement all optional features.

<anish> chad, details

mnot: go with 4-2 proposal

No objections to accepting this as the group concensus

implementation schedule

mnot: lock period until end of September?

<TRutt> I like november lockin

<prasad> +1 to Nov

mnot: lock until November F2F?
... NOv. 1 as end of lock period?
... this is lower bound, not upper

no objections to Nov. 1 as lock period

<RebeccaB> +1 to Nov.1 - that's a quarter from now

mnot: estimates of earliest implementations?
... same - NOvember 1?
... we will expect to have some implementation data, enough to move forward, at that date. This is not binding (except lock period).

no objections to Nov. 1 as early implementation date

PaulD: can we keep to schedule?

mnot: clarifying dates: not go to PR before Nov. 1 (lock date); also expect to have some implementation experience at that date

<prasad> Wonder if we should set a realistic than an optimistic date? Why set a date we are liekly to slip?

no objection to these dates (Nov. 1 for both)

mnot: Does anyone object to requesting a Call For Implementations on the Core and SOAP binding documents?

No objection to going to CR.

future meetings

mnot: take off first 3 weeks of august, 1,8,15 . ??
... calls on 22 and 29 august shorter (1 hour); maybe cancel 29 august if enough done during aug 22 meeting
... cancel 1, 8, 15th
... meet august 22; need to be able to react to CR reports coming back
... may cancel august 29 meeting.

F2F meeting in Bay Area, week of Sept. 26

mnot: F2F set for November 7-8-9, Tokyo
... will put up poll on web site to plan attendance for Tokyo F2F.
... full day Sept 7 and 8, morning of 9th
... continue discussion of test suite, and exactly what is a feature, identifying the features and whether they are optional or mandatory, also sender/receiver.

<scribe> ACTION: PaulD to make enumerated list of features [recorded in http://www.w3.org/2005/07/25-ws-addr-minutes.html#action01]

dhull: will look over, give early feedback

anish: SOAP 1.2 (?) spec has embedded links to testable assertions. This may be a good idea - including hyperlinks in main spec.

PaulD: Don't want to put the main spec in danger by adding these marking.. ?

dhull: tagging would not be a substantive change. It is useful, and not hard.

PaulD: Asynch scenarios

mnot: we need discussion of test suite during August
... next meeting in 4 weeks: 22 August

<RebeccaB> bye

good august to all