Subject: draft-kamp-httpbis-structure-00 comments

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Oct 2016 09:37:17 +1100

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.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 11 Oct 2016 06:51:51 +0000

--------
In message <[email-masked]>
, Martin Thomson writes:

>probably something here, but I'm not sure what it is.

Reading through your comments, it is obvious that I have not been
able to articulate what I want this draft to do.

> - (there are probably some other goals too)

Yes, that's a pretty good list.

But those are the "stretch goals", things which this draft tries to enable.

>whatever tools the draft describes. 

My draft is not aimed at implementations but at RFC writers, such
as yourself, so that for instance your encryption draft does not
take us further away from the stretch goals.

>they need to see some tangible benefits.

With or without this draft, you can write a serializer and parser
for common structure, put it in your code, use it for 19 headers,
and nobody but you would know, because it is 100% compatible.

That's probably not worth it for anybody.

But if this draft goes forward, the WG essentially promises "This
is the last header field parser/serializer we ever ask you to write,
and you can already use it for these 19 headers".

That might be a good incentive.

>used and use the encoding there.

No, the plan is for all future RFC's from this WG to stay inside
the lines drawn up by this draft (except of course when 'bis-ing
existing headers).

That gives us a limited universe of header syntax from which to
pursue the stretch goals.

>definitively incompatible.

No, it describes how to define *new* header fields, so that they
will not be incompatible with the structure of existing header fields.

>That probably means you will need a way to learn on a
>per-header-field basis whether the common form is supported.
>[...] but NeckoFace:>n< probably isn't going to

Why not ?

To any code which hasn't heard about my draft and common structure 
">n<" is just a string to parse, just like any other string containing
a http header.

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

---

From: Kari Hurtta <[email-masked]>
Date: Thu, 13 Oct 2016 07:23:17 +0300 (EEST)

> will not be incompatible with the structure of existing header fields.

3.  HTTP/1 serialization of HTTP header Common Structure
https://tools.ietf.org/html/draft-kamp-httpbis-structure-00#section-3

|       h1_common-structure-header =
|               ( field-name ":" OWS ">" h1_common_structure "<" )
|                       # Self-identifying HTTP headers
|               ( field-name ":" OWS h1_common_structure ) /
|                       # legacy HTTP headers on white-list, see {{iana}}

So *new* header fields are form

new-field: >value<

where syntax of value is h1_common_structure.

> and you can already use it for these 19 headers".

And you can autodetect that syntax from new header fields because > and < -characters.

This was idea, right?

/ Kari Hurtta

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 13 Oct 2016 06:23:59 +0000

--------
In message <[email-masked]>, Kari Hurtta wri

>where syntax of value is h1_common_structure.

Yes.

>And you can autodetect that syntax from new header fields because > and < -characters.

Yes, exactly.

That means installations can have private headers also in common
structure without having to register those with IANA etc.