Re: HTTP 1.1 Server Available for Testing

David W. Morris:
>On Thu, 15 Aug 1996, Roy T. Fielding wrote:
>>
>> I don't anticipate any more changes to the protocol, but stranger things
>> have happened.  I'd like to minimize the number of noncompliant servers
>> advertizing HTTP/1.1, and one way to do that is to encourage people to
>> implement the features within HTTP/1.0 first and only switch the version
>> when it can be tested against a completed RFC.
>
>Impossible Roy ... many aspects of the new protocol depend on the version
>for a experimental client to recognize the server as 1.1 and vice versa.

I agree.  For a start, the persistent connections default case depends
on the version number.  So does the `Message Transmission
Requirements' stuff.

>It is VERY IMPORTANT that such experimental servers not be released /
>distributed as anything other than internet drafts until the RFC is
>approved. But lets focus on the issue that experiments be identified
>as such. Who knows, perhaps the protocol will change as a result of 
>this experiment.

I think that Roy is attacking a non-problem here.  We have anticipated
all along that it might be necessary to change the 1.1 version number
into 1.23723 if too much non-compliant stuff happens under the name of
1.1.

The IESG could change the version number the day before the draft gets
RFC status if too much non-compliant stuff happens, irrespective of
whether the non-compliant stuff was caused by the draft changing or by
the actions of some marketing department.

I don't see the need to aggressively protect the 1.1 `brand name'
before the draft makes RFC status; in fact I think it would be *very
dangerous* to do so.

I think we absolutely need large scale compatibility experiments with
1.1 draft compliant software actually calling itself HTTP/1.1
compliant.  Only large scale experiments with sending the 1.1 version
number will make it clear whether existing 1.0 proxies and gateways
correctly downgrade request and response message versions, and whether
there are browsers that choke on seeing `HTTP/1.1 200 OK'.  The HTTP
minor version number being insignificant might be a nice and
time-honored design goal for 1.1, but it it as yet unknown whether
this design goal is actually met *by all 1.0 implementations out
there*.  We cannot afford to discourage testing in this area.  It is
vastly preferable to get nasty surprises *before* the draft is frozen
as an RFC.

Shipping 1.1 draft compatible software which calls itself 1.1 by
default would also be a bit too much for my taste, but I would
definitely encourage shipping such software with a `send version
number 1.0 or 1.1' toggle defaulting to 1.0.

Finally, the slogan

  `Save the Internet! Implement HTTP/1.1 *now*! Don't say you
  implement HTTP/1.1!'

sounds like something out of a Dilbert cartoon.  This is not the
message I would want to send to the development community.

>Dave Morris

Koen.

Received on Friday, 16 August 1996 06:19:17 UTC