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

Re: DRAFT: more details for HTTPtre

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 28 Nov 2017 17:44:08 +1100
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Patrick McManus <mcmanus@ducksong.com>
Message-Id: <8F9E63C1-D47C-456D-8834-A46AF2247F96@mnot.net>
To: "Julian F. Reschke" <julian.reschke@gmx.de>

> On 28 Nov 2017, at 5:42 pm, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 2017-11-28 03:03, Mark Nottingham wrote:
>> [ 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
> +1
>> * draft-01: Update references, incorporate errata
> +1
>> * draft-02: Re-organise to put all HTTP/1.1-specific information in one draft, remaining architectural content from RFC7230 into RFC7231's draft
> Not convinced yet that merging the remainder of RFC 7231 with RFC 7232 is a good thing....

I think that's a preliminary approach we could try; we'll only know after we do.

>> * draft-03: Start addressing issues, adding text about abstract model
>> * [further drafts as needed]
> Where I'm not sure whether we want to address *everything* that's currently sitting in github issues. Some of this would require changing our strategy with respect to handling malformed messages...

Agreed; many issues will be closed with no action (see previous message about scope).

>> 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.
> Let's keep them apart at the beginning. We may want to analyze how much they cross-reference each other, and then decide on a per document basis.


>> Does this seem reasonable?
> Yes.
> Best regards, Julian

Mark Nottingham   https://www.mnot.net/
Received on Tuesday, 28 November 2017 06:44:38 UTC

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