Preliminary Community Review: text/json

[Douglas Crockford]

I am persuaded. I agree that it should be application/json.

Martin Duerst wrote:
> At 09:14 06/02/10, Graham Klyne wrote:
> 
>  >There is one other thing I noticed.  The proposed MIME type is 
> text/json.  I
>  >think that, based on comments I have seen made previously, that 
> application/json
>  >would be more appropriate.  My understanding is that text/... is 
> intended for
>  >textual information that is suitable for display to a general human 
> audience;
>  >e.g., it has been suggested that text/html was a mistake, which should 
> not be
>  >repeated.
> 
> I agree with Graham and others. I have looked at the spec. The fact
> that it contains 'text' 12 times, but 'application' 0 times is a result
> of the particular use of the word 'text' in the spec, which does not
> match the use of the word 'text' in MIME types.
> 
> One additional comment regarding section 3, encodings. The spec says:
> 
>  >>>>
> 3. Encoding
> 
>    JSON text SHOULD be encoded in Unicode. The default encoding is
>    UTF-8.
> 
>    Since the first two characters of a JSON text will always be ASCII
>    characters [RFC-0020], it is possible to determine if an octet stream
>    is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking at the
>    pattern of nulls in the first four octets.
> 
>            00 00 00 xx  UTF-32BE
>            00 xx 00 xx  UTF-16BE
>            xx 00 00 00  UTF-32LE
>            xx 00 xx 00  UTF-16LE
>            xx xx xx xx  UTF-8
>  >>>>
> 
> This is almost okay. What is unclear is whether other encodings
> (e.g. iso-8859-1) are okay or not. If they are okay, that should be
> said, and it should be explained how they can be identified.
> If they are not okay, that should be said, too. I'd prefer that.
> Simply adding a sentence saying something like "Other encodings
> than UTF-8, UTF-16BE, UTF-16LE, UTF-32BE or UTF-32LE MUST NOT
> be used." should be okay.
> 
> It may also be worth to clarify that BOMs/encoding signatures
> are not allowed.
> 
> Regards,    Martin.
> 
>