Re: identifier in draft-ietf-httpbis-header-structure-01.txt

On 04/30/2017 01:48 AM, Poul-Henning Kamp wrote:
> Alex  Rousskov writes:
>> On 04/29/2017 11:45 AM, Poul-Henning Kamp wrote:
>>> And yes, in HTTP/1.1 serialization you cannot tell if a particular
>>> identifier is a word or a number, you need to definition of the
>>> header in question to tell you that, that's the cost of a very
>>> concise definition and backwards compatibility with standardized
>>> headers.

>> The "cost" part does not compute: A grammar without any "integer"
>> element would be even more "concise" and still backwards compatible.

> The serialization in HTTP/2/HPACK+ or QUIC might distinguish between
> identifiers and numbers for efficiency reasons.

I do not see why "HTTP/2/HPACK+ or QUIC might distinguish" but HTTP/1
must not. HTTP/1 parsers do care about "efficiency".


>> IMHO, if the grammar remains ambiguous, then we should explicitly state
>> that because that property may seriously affect parser implementations.

> Header Structure is not a syntactical specification, 

You have fooled several people into thinking that the draft specifies
syntax rules (among other things). If the draft is not a syntactical
specification, then please remove all rules that contain ">", "<", ":",
'.', and other syntactical details and formats. Those things do not
belong to a pure "vocabulary" specification.


> so the ambiguity is not a problem.

Ambiguity is usually a "problem" for any specification, "syntactical" or
not. However, if you remove syntactical details, then there will be no
implied ambiguity in the draft. Keeping the abstract structure
unambiguous could then become a goal of various syntactical
specifications based on the draft (e.g., a draft covering HTTP/1 rules
could define "integer" syntax to never clash with "identifier", and
another draft for QUIC will accomplish the same goal using different
means). I am not implying you _should_ remove syntactical details, but
doing so would address my concerns.


> HS is more like a vocabulary trying to prevent
> future headers from being needlessly inventive.

I fully support the intent, but the draft does not yet reflect it well
IMO. The Daft is currently full of vocabulary-unrelated details such as
specific delimiter characters and "formats".

IMHO, you have to decide where to stop:

Level 1: Specify vocabulary and associated abstract structure to help
minimize needless invention. Limiting the Draft scope isolates it from
syntax-related problems (such as needless ambiguity). It also naturally
limits its practical influence (but other drafts can cover the holes by
providing the necessary syntactical details).

Level 2: Add field syntax to help folks inventing fields and building
field parsers for specific protocols. The Draft ability to minimize
needless invention would significantly increase, but you would have to
deal with syntax-level concerns such as integer-vs-identifier ambiguity.

AFAICT, the current Draft works at Level 2 but you are dismissing
problems as if it is limited to Level 1.


Cheers,

Alex.

Received on Sunday, 30 April 2017 16:09:37 UTC