- From: Mark Nottingham <mnot@mnot.net>
- Date: Sat, 31 Mar 2012 12:31:02 +0200
- To: Willy Tarreau <w@1wt.eu>
- Cc: "<ietf-http-wg@w3.org> Group" <ietf-http-wg@w3.org>
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. Regards, -- Mark Nottingham http://www.mnot.net/
Received on Saturday, 31 March 2012 10:31:26 UTC