Re: JFV and Common Structure specifications

In message <>, Martin Thomson writes:
>On 21 November 2016 at 13:38, Mark Nottingham <> wrote:
>> The feeling in the room was that we should abandon the JFV draft
>and adopt the structure draft in its place, with the understanding
>that it better reflected our current thinking in this area.
>This seems like a good plan.  PHK's work is closer to what we do today
>and therefore less disruptive.
>We discussed some of the more ambitious features of the common
>structure document, such as integer dates and the angle bracket; is
>the intent to pursue these separately?

My personal opinion: Yes, and no, in that order.

The integer date is only a "gedankenexperiment" in this draft,
included simply to indicate one potential future benefit of CS.

To actually deploy integer Date in CS format in H1, will require a
separate draft which goes into how detection/negotiation works.

A HPACKbis or H3 protocol could/should use a binary CS serialization
and could decide to convert H1 Date headers to CS integers during
transmission, but that would also be in a separate draft.

I think using the angle brackets to say "this header is common
structure" for privately defined headers should be part of this
draft, so the future HPACKbis/H3 can semantically compress them
without needing a white-list.

There is a good argument for also decorating future standardized
headers with ><, so that the IANA registry white-list does not
need to be monitored in (near) real-time.

I also think we should keep the angle brackets/recursion "trick",
so that complex data structures can be built for privately defined
headers.  Recursion is what makes it possible to convert 1:1 from
JSON to CS and back.

But we should probably caution or even SHALL NOT against using
recursion in standardized headers.


PS: I'm personally not terribly happy about the name "Common
Structure", but I found "Http-Header Data Model" even worse.

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, 21 November 2016 09:23:32 UTC