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

Re: New Version Notification for draft-nottingham-structured-headers-00.txt

From: Kazuho Oku <kazuhooku@gmail.com>
Date: Mon, 30 Oct 2017 10:50:46 +0900
Message-ID: <CANatvzwhueLPeM_-9ExzjfU=g-tJym8CjjGBM=3GzWkWXxirzA@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>
Thank you for working on the draft.

I like this approach very much. It is evolutional, and to me seems
very practical.

What we have suffered until today is not being able to reuse a lexer
for parsing headers.

To me it seems that the draft is trying to solve that issue only, and
I think that it would be a good approach considering that we have had
issues in previous attempts that tried to provide other changes at the
same time.

My comments in-line.

2017-10-30 9:57 GMT+09:00 Mark Nottingham <mnot@mnot.net>:
> PHK and I have been talking in the background about how to progress the
> "Common Headers" work item.
> Last week we put together a straw-man of what I thought we might want the
> eventual product to look like. Please have a look; it'd be interesting to
> see how close/far this is from where we want to go.
> Note that it *is* pretty thrown together, and there are a couple of TBDs.
> I'm also certain that the algorithms are buggy as can be.
> The interesting things to discuss here IMO are:
> * Are the basic data types offered the right ones? Too many, too few?
> * Should parameters on parameterised labels be ordered or unordered (since
> writing that, I've found a use case for ordered)?

I think that the decision should be left up to the user of Structured
Headers. In other words, I think that the draft should focus on how
the input should be parsed.

> * Are the limited levels of structure (most complex being a list of
> parameterised labels) sufficient?
> * Is limiting size and number of elements appropriate? Are the limits
> proposed the right ones (warning: bikeshed)?

My +1 goes to not having limits. Instead, a specification that uses
Structured Headers should set limits, if that deems appropriate.

My feeling is that it seems awkward to me to have the restrictions in
Structured Headers, considering the fact that other aspects of HTTP do
not have. For example, there is no hard limit on the length of an HTTP
header field value or on the number of HTTP headers.

> * Is saying that non-ASCII content can use the binary content type + UTF-8
> sufficient?
> * Is the parsing too strict, not strict enough, or just right?
> Etc.
> Cheers,
> P.S. Pretty version at:
>   https://mnot.github.io/I-D/structured-headers/
> Begin forwarded message:
> From: internet-drafts@ietf.org
> Subject: New Version Notification for
> draft-nottingham-structured-headers-00.txt
> Date: 30 October 2017 at 11:50:24 am AEDT
> To: "Poul-Henning Kamp" <phk@varnish-cache.org>, "Mark Nottingham"
> <mnot@mnot.net>
> A new version of I-D, draft-nottingham-structured-headers-00.txt
> has been successfully submitted by Mark Nottingham and posted to the
> IETF repository.
> Name: draft-nottingham-structured-headers
> Revision: 00
> Title: Structured Headers for HTTP
> Document date: 2017-10-30
> Group: Individual Submission
> Pages: 16
> URL:
> https://www.ietf.org/internet-drafts/draft-nottingham-structured-headers-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-nottingham-structured-headers/
> Htmlized:
> https://tools.ietf.org/html/draft-nottingham-structured-headers-00
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-nottingham-structured-headers-00
> Abstract:
>   This document describes Structured Headers, a way of simplifying HTTP
>   header field definition and parsing.  It is intended for use by new
>   HTTP header fields.
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> The IETF Secretariat
> --
> Mark Nottingham   https://www.mnot.net/

Kazuho Oku
Received on Monday, 30 October 2017 01:51:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 November 2017 00:14:14 UTC