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

RE: DRAFT: more details for HTTPtre

From: Lucas Pardue <Lucas.Pardue@bbc.co.uk>
Date: Tue, 28 Nov 2017 11:20:38 +0000
To: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
CC: Patrick McManus <mcmanus@ducksong.com>
Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BAA0105@bgb01xud1012>
Hi Mark,

I'll pose a different question sorry.

Having recently spent a bit of time reading "newer" HTTP related documents, there seem to be a few concepts that are growing from a HTTP/2 root and describe themselves as an HTTP/2 semantic, for example, server push or header compression.

I have also been reading the HTTP/QUIC mapping again, and digesting it. I've come to the opinion (shared with some others) that this is most certainly not HTTP/2 over QUIC. This subtlety is sometimes hard to articulate or maintain, especially given the legacy of gQUIC and earlier mapping documents. This seems to mirror some of the issues related to HTTP/1.1 vs HTTP that the proposed changes would attempt to address.

So I guess the question I have is, is there any appetite to extract out of HTTP/2 any common semantic that could apply to HTTP/QUIC or HTTP/next?

Note, Alt-Svc seems to have avoided the issue I describe. The separation of HTTP/2 and HTTP/QUIC extension spaces will allow for a new ALTSVC frame to be coined cleanly, rather than muddled by HTTP/2 luggage. In contrast, I find something like RFC 8030 (Generic Event Delivery Using HTTP Push) gets caught up in the HTTP/2 trap.

Kind regards
Lucas
________________________________________
From: Mark Nottingham [mnot@mnot.net]
Sent: 28 November 2017 02:03
To: HTTP Working Group
Cc: Patrick McManus
Subject: DRAFT: more details for HTTPtre

[ proposer, not Chair, hat on ]

In Singapore, it seems like there was broad acknowledgement that doing HTTPter is a good idea, but there was some concern about the schedule, especially since QUIC might depend upon or interact with it.

I think this work would go something like this:

* draft-00: Copy of RFC723X for future diffs
* draft-01: Update references, incorporate errata
* draft-02: Re-organise to put all HTTP/1.1-specific information in one draft, remaining architectural content from RFC7230 into RFC7231's draft
* draft-03: Start addressing issues, adding text about abstract model
* [further drafts as needed]

I think we can get to the draft-03 milestone above in a matter of 2-3 months, and cap ourselves at say six months beyond that.

The intent here is to end up with something like this set of documents:

a) HTTP Architecture and Core Semantics - currently parts of RFC7230, all of 7231, plus more text on abstractions
b) HTTP/1.1  - connection management, mapping to TCP transport
c) HTTP Conditional Requests
d) HTTP Range Requests
e) HTTP Caching
f) HTTP Authentication

We *can* combine (c) (d), (e), and (f) into (a), but for simplicity's sake I think we should at least start by keeping them apart.

Does this seem reasonable?


> On 11 Oct 2017, at 2:43 am, Mark Nottingham <mnot@mnot.net> 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<---

--
Mark Nottingham   https://www.mnot.net/




-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------
Received on Tuesday, 28 November 2017 11:21:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:11 UTC