Draft standard rules (was RE: What is Content-Length?)

I'll say it again; don't presume that a given solution will/will
not result in recycling at proposed; usually, when I see such comments made,
and it usually isn't true...

The point of draft standard is to show that all features of the
protocol have actually been tested a couple times by someone, somewhere,
and that the spec can be independently implemented successfully
(success is defined by interoperability.

The rules for draft standard are pretty clear:
	No INCOMPATIBLE protocol changes.
	Changes are to fix bugs in the proposed standard protocol.
	No new functionality.
	2 tested interoperable implementations (doesn't have to
		be shipped as product.)

It isn't that hard to get two implementations; as usual, Henrik has
one in his pocket for almost everything in Rev-01.  Everything
that goes to draft standard has to have two interoperable implementations,
and they can be by anyone. You don't have to show a single implementation
of everything (in HTTP's case, this would be very unlikely in any case,
since we worry about clients, servers, and proxies).
The IESG is pragmatic about interpreting the rules.

If you have to break compatibility (at least once there are significant 
implementations out there, so that interoperability is disturbed), you have 
to recycle at proposed.

This is why Larry called the process "The Frankenstein's Monster"
process; you get to take pieces from anywhere to put the monster together.
				- Jim

Received on Wednesday, 17 December 1997 14:17:49 UTC