As you probably know by now... (schedule and important points)

I've taken over as editor of the HTTP 1.1 document.

Jim's koans for HTTP:

	o The perfect is the enemy of the good
	o If a bus does not leave this station, there will be no future busses
	  to interesting destinations from this station
	o If you win at pin-ball, you get to play again

Those being said:

I managed to forget the calendar we wrote on at the IETF meeting
when I came into work today; I'll post the dates from that calendar
to the list this evening when I get home, to confirm what Larry
has said in his minutes.  Here is the schedule as Larry's minutes

	o March 15 - Issue list review by WG.
	o March 18 - Tentative feature list of 1.1, and structure
		of resulting document(s).
	o April 1 - New draft for comment by WG.
	o May 1 - submission to IESG

1) We need a pretty complete issues list by the end of this week.
Larry will be out of town after this week for two weeks (a good
boondoggle to Japan), and in his absense, I'll maintain the issues

It is VERY important for you all to PLEASE REVIEW and COMMENT (when
needed) on the Issues list this week.

Send mail to Larry and myself on problems/additions/resolution of
items on the list.

2) We need to keep the signal to noise ratio on the list as favorable
as possible.  I am making a request of those on the list to try
to resolve ambiguities/issues with the major subgroup chairs, and
report the results of these side conversations as a single message to the
list once complete, if possible.  This may help the keep messages
delving into a given topic from swamping the list, as it has been
in danger of from time to time.

3) We need to quickly move from general closure of issues to
drafting exactly the words required to implement the closure.

4) I plan to organize a committee of people to help with drafting
the words in the document, and hold a teleconference with those
people (at least) weekly to cover issues.   Various people will likely
be drafted into those teleconferences as needed.

5) I will attempt to organize the document to allow separate pieces to
become separate documents so that if we find that we cannot reach closure
on those pieces as part of basic 1.1, they will be able to proceed independently
without holding up the core of 1.1.

				- Jim Gettys

Received on Tuesday, 12 March 1996 12:25:20 UTC