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

On Fri, Mar 11, 2016 at 05:02:26PM +1100, Mark Nottingham wrote:
> <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.
> 
> There's already been support for it demonstrated at the meetings we've talked
> about it. Any additional thoughts?

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

Received on Friday, 11 March 2016 06:42:20 UTC