Subject: Re: [http-state] wrt documenting current practice or/and specifying new beharvior

From: =JeffH <[email-masked]>
Date: Fri, 28 Aug 2009 11:26:16 -0700

Dan Winship <[email-masked]> wrote:
 >
 > There is actually a three-way split here, not two-way:
 >
 >     1. Document what existing implementations do, noting differences
 >        (descriptive spec)
 >
 >     2. Document what a hypothetical implementation should do if it
 >        wants to be maximally interoperable (normative spec)
 >
 >     3. Document what we wish implementations did, a la RFC 2109/2965
 >        ("optative spec"?)

That's helpful, thanks.

Daniel Stenberg <[email-masked]> replied:
 >
 > My primary motivation for staying in camp (1) has been since that's how I've
 > viewed our set out task and then I've seen it as a worthwhile task to make
 > sure we stay within set the boundaries.
 >
 > If we decide we should rather be more camp (2), then I'll be willing to
 > adjust to that and quickly adapt to match the other campers in here.

Adam Barth <[email-masked]> replied to Daniel:
 >
 > I think our work will be most valuable of we reside in camp (2).  I'm
 > glad that we have some conservative voices in the group to help us
 > avoid slipping into camp (3).

Dave Kristol <[email-masked]> cautions:
 >
 > My argument was that recommending or, especially, specifying behavior is
 > fruitless unless you have buy-in from the people who would make changes
 > to the servers and browsers, i.e., the *vendors*.  And even then you
 > face the problem that zillions of web apps might also need to be
 > changed.  Things were much simpler in 1996, and we still failed to make
 > recommendations stick.
 >
 > My recommendation:  stick to the things you can control.

Adam Barth <[email-masked]> replied to Dave:
 >
 > Yes.  Getting buy-in from vendors is important.  I'm happy that Opera
 > has made their buy-in clear on this list.  I'm in contact with the
 > various vendors.  While no one has said "go to town and we'll
 > implement whatever you spec," the prevailing mood seems to be "cookie
 > compatibility is a pain point and we wish we had a spec we could
 > actually follow and still interoperate with the web."  I think we
 > should see producing that spec as our goal for "phase 1," as Jeff
 > calls it.

So, note that there's at least two ways to approach tasks (aka camps) (1) and 
(2)...

a. write one spec that addresses both (1) and (2).

b. write one spec addressing (1) [spec-1], write another addressing (2) 
[spec-2] which references (1).

Note that with (b), spec-1 and spec-2 could be on different tracks, e.g. 
informational and standards, respectively.

The ADs and IESG will help us decide this, in my experience.

Overall, the key thing as Dave & Adam note, is having the attention and buy-in 
of UA/browser implementors, regardless of nuances of how the spec(s) is/are 
manifested.

HTH,

=JeffH

---

From: Bil Corry <[email-masked]>
Date: Fri, 28 Aug 2009 21:08:32 -0500

=JeffH wrote on 8/28/2009 1:26 PM: 
> Overall, the key thing as Dave & Adam note, is having the attention and
> buy-in of UA/browser implementors, regardless of nuances of how the
> spec(s) is/are manifested.

I agree having the attention and buy-in of UA/browser implementors is good, but I don't think it's entirely necessary for phase 1 (descriptive/normative spec) as all we're doing is documenting existing behavior and specifying specific behaviors for maximum interoperability.

Once we hit phase 2 and are specifying new behavior, then yes -- if we don't have the vendors participating, I'm uncertain that the work will be worthwhile (i.e. adopted/implemented).

- Bil