W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: Adjusting our spec names

From: Mark Nottingham <mnot@mnot.net>
Date: Sat, 31 Mar 2012 12:31:02 +0200
Cc: "<ietf-http-wg@w3.org> Group" <ietf-http-wg@w3.org>
Message-Id: <58AA9C23-AE98-40A2-AD10-D783016AAA64@mnot.net>
To: Willy Tarreau <w@1wt.eu>

On 31/03/2012, at 12:24 PM, Willy Tarreau wrote:

> On Sat, Mar 31, 2012 at 12:11:44PM +0200, Mark Nottingham wrote:
>> Our current products are named:
>> HTTP/1.1, part 1: URIs, Connections, and Message Parsing
>> HTTP/1.1, part 2: Message Semantics
>> HTTP/1.1, part 3: Message Payload and Content Negotiation
>> HTTP/1.1, part 4: Conditional Requests
>> HTTP/1.1, part 5: Range Requests and Partial Responses
>> HTTP/1.1, part 6: Caching
>> HTTP/1.1, part 7: Authentication
>> Note that many of the latter mechanisms are NOT specific to HTTP/1.1; i.e., they will work in an HTTP/1.0 message, and also (according to our charter) must work in a HTTP/2.0 message.
>> Therefore, I'm inclined to rename them, leading to something like:
>> HTTP/1.1 Message Format and Connections
>> HTTP Core Semantics  (combined p2 and p3, which the editors are currently undertaking)
>> HTTP Conditional Requests
>> HTTP Range Requests and Partial Responses
>> HTTP Caching
>> HTTP Authentication Framework
>> Thoughts? This doesn't (yet) account for the discussed p0.
> I've mixed opinions on this. I agree with having p1 become 1.1 specific.
> However there might be changes that are worth applying to other parts for
> HTTP/2.0 to improve reliability/speed/security and which can still be
> mapped 1-to-1 to HTTP/1.1. Some examples include date formats, and
> handling of field value lists which are worth changing in 2.0 in my
> opinion and which do not imply a change of semantics although being
> documented in P2. It's very likely that the caching guys have
> suggestions on cache/ranges/conditions.
> In the end, why not name everything 1.1 in order to avoid later confusion
> if we fix even very minor things in 2.0 ?

If we update the caching model in HTTP/2.0 so that it can't work in HTTP/1.1 (i.e., it violates the basic model defined there), I'd be very surprised, and we'd probably be outside our charter scope. Someone might make *updates* to the caching model that's already defined, but that doesn't require us to version its core.

Regarding specific syntax such as Dates - I agree that this might be worth factoring out into a 1.1-specific document.

I'm more sceptical about changing *generic* field-value lists; keeping in mind our need to be able to handle arbitrary 1.1 messages, I don't think we can change too much here.


Mark Nottingham
Received on Saturday, 31 March 2012 10:31:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:01 UTC