draft-kamp-httpbis-structure-00 comments

[Martin Thomson <[e-mail]>]

I've spent a bit of time thinking about this, and that there is
probably something here, but I'm not sure what it is.  I'd like to see
if we can up-level the discussion a little and concentrate on what we
have and what we want.

I want to concentrate on these issues rather than the specifics of the
document, because I'm not sure that the document is clear enough about
articulating its goals right now.  The introduction is pretty good
about setting out the state of play (it's a mess), but I would really
appreciate it it it also included both a desired end-state and a plan
for reaching that place.

1. Desired end-state

Though it is not stated, there are many potential properties we might
want to obtain by making this sort of change:
 - more consistent representation of header fields
 - easier to specify new, compatible header fields
 - more capable header fields (more resolution on dates, for instance)
 - more efficient parsing and processing code
 - smaller header field representations
 - (there are probably some other goals too)

The draft is clearly aiming at the some of these, but it's less clear
about its stance with respect to some of the other ones.

Any draft also needs to describe when an implementation might use
whatever tools the draft describes.  It looks like the intent is to
find "compatible" header fields, but to what end?  After all,
virtually all header fields can be made compatible by cramming them
into a string (that's essentially the mess we have today), so there
has to be something better than that.

The draft should at least acknowledge incentive to deploy.  In order
for it to be attractive to both clients and servers to support this,
they need to see some tangible benefits.  I can say that from a
browser perspective, reliability and performance are pretty good
incentives.  Parsing efficiency isn't a big deal for us, and new code
has an automatic reliability penalty, so a more compact form might be
a good place to look.  Clearly, constrained implementations (and
servers count) benefit greatly from parsing efficiencies.

2. Getting from here to there

Presumably the plan is to find some place that a new encoding can be
used and use the encoding there.

But the draft describes how to encode header fields in a new syntax
that is distinctly different to existing header fields, and therefore
definitively incompatible.  That implies the need for some way to
decide to send header fields in this new form.  It mentions existing
header fields, but offers no plan that would let a client or server
decide to use this form.

I can imagine negotiating support for this in HTTP/2 with settings or
something like that (it's surprisingly complicated in practice); I can
also imagine that a server might advertise support for this using a
.well-known resource (YAWK); I can even imagine using connection-level
negotiation in http/1.1 with an inter-request stateful mechanism
(YUCK).

It's never going to be possible to construct a rule to translate an
arbitrary header field unless you want to commit to crappy
translations for stuff that exists now that we don't bother to create
good rules for.  That probably means you will need a way to learn on a
per-header-field basis whether the common form is supported.  That
might be done in sets (you could provide rules for the existing set of
registered header fields), but NeckoFace:>n< probably isn't going to
be something you can use from the outset.