Subject: [Json] LC comment on http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-07#section-11

From: Julian Reschke <[email-masked]>
Date: Tue, 12 Nov 2013 08:18:54 +0100

<http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-07#section-11>:

>    Encoding considerations:  8bit if UTF-8; binary if UTF-16 or UTF-32.
>       JSON may be represented using UTF-8, UTF-16, or UTF-32.  When JSON
>       is written in UTF-8, JSON is 8bit compatible.  When JSON is
>       written in UTF-16 or UTF-32, the binary content-transfer-encoding
>       must be used.

That is a bit misleading, because content-transfer-encoding isn't needed 
(nor defined) if the transport allows binary anyway (such as HTTP).

Related to this: a frequent question on stackoverflow is about the 
charset parameter on application/json. Maybe it's worth re-stating that 
it is not only not defined but also really really has no effect.

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 12 Nov 2013 13:23:21 +0100

>(nor defined) if the transport allows binary anyway (such as HTTP).

RFC 6838 calls for using one of "binary", "framed", "8bit" and "7bit"
for this field, and using anything other than "binary" or "framed" is
almost always wrong ("7bit" and "8bit" require CRLF line endings). It
is not framed, so

  Encoding considerations: binary

is all that is called for here.

>it is not only not defined but also really really has no effect.

I agree that this is a common point of confusion, including in running
code, that should be explicitly addressed in the specification.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/