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

On 05/01/2017 10:17 AM, Poul-Henning Kamp wrote:

> To be brutally honest, it has never been entirely clear what the goal
> of this document is :-)

I applaud your honesty, but since this is a WG draft now, the lack of a
clear goal is no longer your personal fault :-). I hope we can fix that
flaw before it becomes fatal.

>> [...] and we should focus on a small set of unambiguous elements [...]

> That is simply not possible for existing headers.

Can we define all existing headers using a small set of unambiguous
elements? Probably not, but that should not be our goal. We only need to
cover common usage of common fields plus (nearly) all future ones.

> Current header definitions make 3.14159265 a valid "token":

Yes, but _we_ do not have to define 3.14159265 as both "number" and
"identifier". AFAICT, we can define it as "number" only, excluding
tokens that start with [-]DIGIT from our "identifier" definition.
Ambiguity problem solved! This works for both parsers and generators.

> So there is no way to tell what you have when you encounter that,
> unless you know which header you are in and where in that header
> you are.

There is a way to tell for all the important use cases AFAICT.

Yes, if I am building a generic parser that wants to understand senders
intent in _all_ legacy cases, then my parse tree cannot use some of the
draft elements "as is", but since understanding senders intent in all
cases is an unsolvable problem in legacy HTTP, we should not focus on
that esoteric use case too much!

A generic parser that might confuse a number with identifier is possible
to build for legacy HTTP while perfect parsers are possible for new
>fields<, and that is good enough. Same for generators.



Received on Monday, 1 May 2017 17:03:45 UTC