- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 21 May 2020 12:52:16 +1000
- To: Benjamin Kaduk <kaduk@mit.edu>
- Cc: The IESG <iesg@ietf.org>, draft-ietf-httpbis-header-structure@ietf.org, httpbis-chairs@ietf.org, HTTP Working Group <ietf-http-wg@w3.org>, Tommy Pauly <tpauly@apple.com>
> On 21 May 2020, at 1:38 am, Benjamin Kaduk <kaduk@mit.edu> wrote: >> >>>> I think the solution here is to change the last paragraph of Notational Conventions to: >>>> >>>> """ >>>> For serialization to HTTP fields, the ABNF illustrates the expected wire representation with as much fidelity as possible, and the algorithms define the recommended way to produce them. Implementations MAY vary from the specified behavior so long as the output is still correctly handled by the parsing algorithm. >>>> """ >>>> >>>> Does that work for you, Ben? >>> >>> This makes the parsing algorithms normative for both parsing and >>> serialization, which alleviates the concerns about skew. >>> >>> I do agree with Julian that making the (minor!) change to the ABNF to >>> remove that axis of skew seems worthwhile, though I do not think I can make >>> that a Discuss point (given that I, like him, would prefer to keep the ABNF >>> as-is over removing it entirely as you propose). >> >> See latest commit. > > I see the update to make the parsing algorithm fully normative; is there > also something on the empty-list ABNF front that I'm failing to find? No. Making that change would be seen as encouraging sending of empty fields. >>>>> What's the motivation for "MUST omit values of boolean true" (in >>>>> parameters and dictionaries)? It seems to make the output rules more >>>>> complicated without a significant gain in encoding size. >>>> >>>> It allows some existing HTTP headers to be treated as structured for the purposes of serialisation. >>> >>> The downthread discussion also made the claim that this is due to a desire >>> to have exactly one way to serialize. But what's the good in having >>> exactly one way to serialize if you don't enforce that at the receiver? >>> (Compatibility with already-defined header fields, no doubt, but it does >>> kind of undercut some of the stated goals of this document.) >> >> Sorry, I lost state. Where did you get that impression? > > Julian said it at > https://lists.w3.org/Archives/Public/ietf-http-wg/2020AprJun/0172.html and > I didn't see anyone jumping up to correct it. That wasn't a motivation that we ever discussed, as I recall. I don't know why Julian asserts it here. -- Mark Nottingham https://www.mnot.net/
Received on Thursday, 21 May 2020 02:52:34 UTC