W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Our Schedule

From: Mark Nottingham <mnot@mnot.net>
Date: Sat, 24 May 2014 09:23:30 +1000
Message-Id: <4D514C13-D7B6-4E42-B057-1C4446A132AC@mnot.net>
To: HTTP Working Group <ietf-http-wg@w3.org>
In a little less than two weeks, we have an interim in NYC.

We’ve designated that as an interop event for draft -12 (and associated specs), and so far we seem to have good representation (reminder: if you haven’t already, please update <https://github.com/http2/http2-spec/wiki/Implementations>).

Our agenda for the interim is to go (yet again) through our open issues:

Assuming we can close those at or soon after the interim, we’ll issue another draft around mid-June. 

My current thinking — again, assuming we leave the interim with no open issues (or a plan to close them) — is to:

* Mark that draft as an Implementation Draft, with the interop targeted at our meeting in Toronto
* Issue a Working Group Last Call with a deadline in mid-July
* Based upon WGLC feedback and interop feedback, make a decision about submitting the documents to the IESG at our Toronto meeting.

The IETF LC will last at least two weeks, and then it goes to the IESG for their consideration. Personally, I think that if we follow the plan above, we have every chance of having an RFC well before the end of the calendar year.

All of this is contingent on being able to close out our issues in a timely manner, and not discovering significant new issues in WGLC, of course. If that happens, we’re going to need more rounds of interop, we’ll likely need more meetings, and the schedule will slip (perhaps significantly).

We’ll discuss all of this in more detail in NYC, but I wanted to give people a heads-up on the list as to where I think we’re heading.

So far, I’ve heard strong preferences across the board for keeping the schedule tight, and the above reflects that.  Going into NYC and Toronto, we need to keep this in mind as we make decisions; every change we make and especially every feature we add has the potential to delay us.


Mark Nottingham   http://www.mnot.net/
Received on Friday, 23 May 2014 23:24:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC