Proposed structure of HTTP 1.1 document(s).

By this date, you all should have reviewed the issues list and commented
and/or raised additional issues. I will be working over the next several
days on the issues list to make it somewhat clearer and better organized.

The schedule calls for me to publish an editorial organization of 1.1 today,
so here it is.

John Klensin (no longer applications area director, but generally worth listening
to), expressed the opinion that no more documents than necessary be processed 
by IESG.  If items are left to separate documents
unnecessarily, it is less likely they will be implemented, and the result
is more confusing to implemetors.  On the other hand, we cannot allow
less essential issues to hold up getting the basic part of HTTP to draft
standard status.

There are two possible space travel-inspired models for handling the 
HTTP 1.1 documents.
	Allow for "explosive bolts", so that it is possible to
		explode non-essential issues from the core
		document if controversy arises.
	Allow for "soft docking", so that controversial issues can
		dock with the core document if IETF "rough consensus"
		is reached in time.

I propose we allow for both models.

I expect we will end up with no more than 4 documents as part of 1.1.  I hope
for only two or three.  Ideally, we end up with only one.

A group of us held a teleconference last Thursday (3/14) and reviewed the state
of all parts of 1.1 and the issues list.  After some thought, I think the 
following overall editorial organization makes the most sense.

Core HTTP 1.1 document:
	solution to the host problem.
	integrate caching subgroup work into core
		This appears essential, and pervasive, and so will have to
		be integral to the core document.
	persistent connections. (as separate chapter, so that
		if there is some hold up, we can eject it).
	byte range retrival extension (as separate chapter, so that
		if there is some hold up, we can eject it).
	resolution of outstanding issues in the 1.1 draft 1, per issues list.

Initially separate documents (will be handled independently until/unless
it is clear they are adopted in time for W.G. last call of core document):

1) Digest Access Authentication
	We believe a separate document here is the wisest course, as both
	the HTTP and the WTS groups need to review this document before
	adoption.
2) Proposed HTTP state management mechanism
	This might be able to become part of the core 1.1 document as
	a chapter.  The authors, however, are not available until around the
	beginning of April, so unless/until it becomes clear that closure
	can be reached in time for 1.1 we will keep it separate.
3) Content negotiation (still under discussion)
	At the moment, the largest uncertainty seems to be in content
	negotiation.  Dan Connolly and Tim Berners-Lee expressed during
	our teleconference last Thursday serious reservations 
	(more than just small details) about the current
	draft of the subgroup.  They owe a writeup of a reputedly simpler
	counter proposal on Thursday, March 21 to the working group.

By far the most worrying issue for 1.1 are potential interactions
between content negotiation and caching.

It is possible that any/all of these three documents may become
standards at the same time as 1.1, if rough consensus over
them can be reached.  The sooner consensus is reached on them,
the more likely they could be integrated into the core document.
Consensus will have to be reached in time for editorial grunt work
before W.G. last call on the core document to allow docking of these
independent documents.

Very likely left to after 1.1:
	Any issues we can't reach closure in time on the documents above, or 
		issues already marked as deferred in the issues list.
	PEP: An Extension Mechanism for HTTP
	Demographics issues.
		Extended log file format
		Session Identification URI
		Notification for Proxy caches

Please let me know of any comments you have to this editorial proposal...
				- Jim Gettys

Received on Monday, 18 March 1996 12:10:11 UTC