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

[Bjoern Hoehrmann <[e-mail]>]

* Julian Reschke wrote:
><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).

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.

>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.

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:[e-mail] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: [phone] · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/