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

--------
In message <59f3d7c9-ecbc-6f32-0bad-985095f80bba@measurement-factory.com>, Alex Rousskov writes:

>We may be talking past each other

I think we are.

>A. If the goal is [...]

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

It came into existence after attempts to fit almost-but-not-quite-JSON
into HTTP headers, because I had a trainride from Stockholm to
Copenhagen and Mark had given me the idea to find out what kind of
structure our existing headers actually fit into.

Because of the JSON heritage, I approached it as "can we synthesize
a format which will allow us to move the same data as JSON could have
moved, and the draft as currently written (still) reflects this, despite
active lack of enthusiasm for this aspect in the WG.

As a beneficial side-effect, a HPACK2 which could semantically compress
headers more efficiently than HPACK might be possible.

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

That is simply not possible for existing headers.

Current header definitions make 3.14159265 a valid "token":

   tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
    "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA

   token = 1*tchar

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.

What we can do is make it easier to get from the definition of
the header to code which can parse it, or at least check its
validity.

And those (machine-readable!) definitions could still be used to
produce a semantic compressor (HPACK2 or whatever).

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Monday, 1 May 2017 16:18:21 UTC