Subject: Call for Adoption: draft-reschke-http-jfv

From: Mark Nottingham <[email-masked]>
Date: Fri, 11 Mar 2016 17:02:26 +1100

<https://tools.ietf.org/html/draft-reschke-http-jfv>

We've talked about this draft several times, and it appears there's decent interest in it. We also have external groups (e.g., W3C WebAppSec) starting to experiment with this format for headers.

My personal observation is that because of their open syntax, minting new HTTP headers is difficult to do correctly, even with the advice we gave in RFC7231. Providing a framework like this one can help guide authors, as well as ease the burden of reviewers. 

Julian has confirmed that he is willing to continue editing, and our AD is aware of this work. The only thing I'll add is that people shouldn't get too hung up on the exact syntax currently proposed; based on our discussions, it might change significantly.

There's already been support for it demonstrated at the meetings we've talked about it. Any additional thoughts?

--
Mark Nottingham   https://www.mnot.net/

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 11 Mar 2016 07:41:52 +0100

> <https://tools.ietf.org/html/draft-reschke-http-jfv>
(...)
> Julian has confirmed that he is willing to continue editing, and our AD is
> aware of this work. The only thing I'll add is that people shouldn't get too
> hung up on the exact syntax currently proposed; based on our discussions, it
> might change significantly.
> 

I'm personally not fond of JSON, I remember that the first time Julian
talked about this, I had a grimace. But short after that I had to admit
I couldn't find any solid technical argument against this choice. JSON has
the merit of being relatively easy to encode and decode, to be flexible,
and to add very low overhead on top of text-based communications (which is
our case here).

I remember that Kazuho showed it was possible to simplify the common case
(single value) to end up with basically no change compared to the current
format.

I think my real fear comes from the risk of seeing people start to serialize
whatever they can imagine into header fields. We've already seen multi-kilobyte
cookies in the wild, if headers become officially JSON-like, maybe some
people will consider it normal to abuse them. On the other hand it's hard
to declare some protocol limits that we won't regret later.

The other point to think about is to help recipients detect the presence
of such encoding in unknown header fields. I guess that the current draft
makes this relatively easy and that Kazuho's suggestion maintains this
possibility.

I'm seeing a risk of corruption along the path due to the use of the
comma in JSON, because unaware intermediaries may consider this as a
series of comma-delimited values and possibly fail to properly re-encode
them (or modify some of them). But at this point that's a minor detail.

Overall I think this is very useful research work and I hope to see it
make forward progress. The faster we can rely on such a document for
new fields, the better. And it's important not to start to use parts of
it until it's adopted, we definitely don't want to have multiple decoders
depending on the fields that will have been invented before and the ones
after the adoption!

Just my two cents,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Fri, 11 Mar 2016 08:12:06 +0100

> talked about this, I had a grimace. But short after that I had to admit

(Believe me, I'm not a JSON fan boy, either. Spending a lot of my time 
with XML and XSLT and enjoying it...)

> (single value) to end up with basically no change compared to the current

Yes, and I apologize not to have fully followed up on this...

> to declare some protocol limits that we won't regret later.

That is indeed a risk; is there anything we can do about it except warning?

> makes this relatively easy and that Kazuho's suggestion maintains this

That's a discussion I'd like to have later. For now this is just for new 
header fields where the recipient will know about the format. Simple 
things first...

> them (or modify some of them). But at this point that's a minor detail.

Interesting point. Have you seen this in practice?

> depending on the fields that will have been invented before and the ones

Best regards, Julian

---

From: Cory Benfield <[email-masked]>
Date: Fri, 11 Mar 2016 10:07:26 +0000

> On 11 Mar 2016, at 06:02, Mark Nottingham <[email-masked]> wrote:
> 

In general I think this is a good idea and I’m +1 on it. I think the reasoning for the implicit array markers might want to be elaborated on because it took me a few moments to work it out (it’s to allow header field coalescing), and without it it’s hard to understand why a new specification was required for this at all.

That, also, is a question this RFC needs to answer: why is simply throwing JSON into a header value insufficient? The *actual* answer is that it doesn’t behave well in lots of edge cases (newlines in strings etc. etc.), but if this document doesn’t say that it risks a lot of readers concluding that the IETF spent 10 pages saying “put JSON in header field values”, which isn’t true.

Cory