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

Hi Kazuho,

> On 30 Oct 2017, at 12:50 pm, Kazuho Oku <kazuhooku@gmail.com> wrote:
> 
> Thank you for working on the draft.
> 
> I like this approach very much. It is evolutional, and to me seems
> very practical.

Thanks!

> 
> 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.

Seems reasonable to me. Perhaps it would be good to have a non-normative appendix or similar offering guidance to library implementations on things like this.


>> * 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.

The one thing that makes me pause here is how rarely headers specify limits like this if left to their own devices, and how much trouble it can cause because there are different implementation-specific limits imposed.

Given that, it seems like if we ever want to have some general limits (with the ability for specific headers to tighten them, of course), this is a good time to try.

But it might be that we decide it's not worth trying.

Cheers,

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

Received on Monday, 30 October 2017 04:51:07 UTC