|>My own opinion is that the most expeditious path is to document the current
|>practise and publish it as one or more Informational RFCs, rather than
|>pursue standardization. If we standardize the current practise, we really
|>can't make any standards-track changes for about a year. The pressure for
|>enhancements is pretty strong, as I read it.
I suggest that we start out with a road map of version numbers. There is no
point in doing anything with HTTP/1.0. By now everyone has had a go at it!
I suggest :-
HTTP/1.0 Anything you like and can find a URL to discribe :-(
HTTP/1.1 First cleanup version, basically describe current practice,
i.e "what Mosaic does" and the servers do.
HTTP/2.0 First target version, standard which browsers should be
trying to attain :-
1) Methods, GET, HEAD, PUT, POST, DELETE, kill the CHECKIN/CHECKOUT
methods etc.
2) Referer field mandatory.
3) Digest authentication method (to eventually replace basic) must
be supported.
4) Clients should send quality field for accepts.
HTTP/3.0 The target protocol, asynchronous support for conferencing,
MGET etc.
I would like to propose a distinction between the protocol specification
and the client/server specification.
Protocol specification: What the clients and servers must tolerate
Client specification: The subset of the protocol that a client may use
Server specification: The subset of the protocol that a server may use.
Thus a client claiming to meet the HTTP/2.0 spec must provide the referer
field (subject to security restrictions), but a server may not require it
to be provided.
Before being fixed each version would have a revision number so that the
February spec for HTTP/1.1 can be distinguished from the March one etc. When
the standard is fixed then the revision is dropped. Ie my above proposals
should really be HTTP/1.1R1 etc.
As far as standards tracks go. I think we will always have at least
three on the go. There will be an established one in use, static and supported.
There will be another that has been fixed and is undergoing minor revisions
during the standards process and there will be a third highly volatile
development spec.
Here we can knock out the HTTP/1.1 spec with little difficulty as an
informational RFC. HTTP/2.0 would be the one to put through standards
track and HTTP/3.0 would be the development one.
Hopefully once we have the filter for turning RFCs into code finished
we can speed up the development process.
-- Phillip M. Hallam-BakerNot Speaking for anyone else.