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

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

From: Alex Rousskov <rousskov@measurement-factory.com>
Date: Sat, 29 Apr 2017 17:22:01 -0600
To: HTTP working group mailing list <ietf-http-wg@w3.org>
Message-ID: <22726a23-fa30-8c36-833e-8c75a474a18f@measurement-factory.com>
On 04/29/2017 11:45 AM, Poul-Henning Kamp wrote:
> Alex Rousskov writes:
>>  In draft-ietf-httpbis-header-structure-01.txt, "integer" is "identifier":
>>
>> Does not that contradict the self-identification claim? If it does not,
>> then what do we mean by "self identification" exactly?

> "Self-identification" refers to wrapping the entire header in > ... <

Understood, thank you.


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

I suspect you want to keep "integer" in the grammar (despite the fact
that it necessarily increases grammar complexity) to increase semantic
expressiveness/precision of some field definitions: Sometimes, you want
to say "integer" instead of vague "token". We do not have to make the
grammar ambiguous while achieving that particular goal! For example, we
could define "identifier" as a "token" that is not an "integer".

Do we care whether the grammar is ambiguous? We might. With an ambiguous
grammar, a generic >...< field parser would need "configuration" from
the semantics layer to build the right parsing tree. This configuration
increases generic parser API complexity (and often decreases parser
performance).

I realize that "integer" is not the only thing that makes the current
grammar ambiguous. I suspect we can get rid of all such ambiguity if we
want to, without sacrificing grammar "conciseness" and expressiveness.


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


Thank you,

Alex.
Received on Saturday, 29 April 2017 23:22:31 UTC

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