W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2017

Re: DRAFT - HTTPtre scope of work

From: Willy Tarreau <w@1wt.eu>
Date: Wed, 11 Oct 2017 13:48:42 +0200
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Alexey Melnikov <alexey.melnikov@isode.com>, Patrick McManus <mcmanus@ducksong.com>
Message-ID: <20171011114842.GA754@1wt.eu>
Hi Mark,

On Tue, Oct 10, 2017 at 08:43:10AM -0700, Mark Nottingham wrote:
> Hi everyone,
> 
> We've talked about revising the HTTP/1.1 documents a few times; I think the next step is to agree on a scope of work. See draft proposal below.
> 
> --->8---
> 
> The Working Group will revise the RFC723[0-5] document set. The primary goals of this work will be:
> 
> 1)  To clearly separate the version-dependent aspects of HTTP from those that are version-independent, to aid readers and implementers, and assist definition of future protocol versions;
> 
> 2) Clarifying HTTP's underlying abstractions and guarantees (the "abstract model" of HTTP), to define a target for future versions of the protocol;
> 
> 3) Incorporating errata;
> 
> 4) Clarifying how HTTP is extended and versioned, as necessary; and
> 
> 5) Addressing significant (as determined by the Chairs) security and interoperability issues that are raised.
> 
> Issues that are specific to HTTP/1.1 (e.g., chunked encoding, connection handling) will only be addressed if there is broad (as determined by the Chairs) implementation support for doing so.
> 
> The number and focus of the resulting documents might be the same, or might differ. It is expected that the resulting documents will be suitable for publication as Internet Standard. 
> 
> ---8<---
> 
> Thoughts?

This sounds pretty reasonable and will possibly lead to better design choices
in the future now that we have some experience feedback making two versions
coexist.

I think that we should also start to give more recommendations about things
that should/should not be done to ease porting. I don't have anything
specific in mind, but it can range from new header field names to adopting
stricter types for values to ease parsing or structured representation for
example.

In short, we used to only know H/1 and its deployed implementations. Now
that many of us have known some difficulties dealing with H1+H2, we'll
probably want to be a bit more directive.

Cheers,
Willy
Received on Wednesday, 11 October 2017 11:49:16 UTC

This archive was generated by hypermail 2.3.1 : Monday, 9 September 2019 17:48:38 UTC