On 17/03/13 10:33, Peter Cordell wrote:
On 13/03/2017 07:51, Martin J. Dürst wrote:
My personal opinion is that we could try to fix this by changing the
following:
JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32 [UNICODE]
(Section 3). The default encoding is UTF-8, and JSON texts that are
encoded in UTF-8 are interoperable in the sense that they will be
read successfully by the maximum number of implementations; there are
many implementations that cannot successfully read texts in other
encodings (such as UTF-16 and UTF-32).
to something like the following:
JSON text SHOULD be encoded in UTF-8 [UNICODE]
(Section 3). JSON texts that are
encoded in UTF-8 are interoperable in the sense that they will be
read successfully by the maximum number of implementations.
There are
many implementations that cannot successfully read texts in other
encodings (such as UTF-16 and UTF-32). JSON text MAY be encoded in
UTF-16 or UTF-32 [UNICODE] (Section 3) if the sender is sure that
the intended recipients can read them.
My only thought is to perhaps reflect that JSON isn't only transmitted,
and JSON can be used for file based configuration etc, (even if this
isn't strictly IETFs concern). So perhaps s/sender/encoder/ in the last
sentence, plus a few other tweaks yielding something like:
There are many implementations that cannot successfully read texts
in other encodings (such as UTF-16 and UTF-32 [UNICODE]). JSON
text MAY be encoded in other encodings if the encoder is sure that
the intended recipients can read them.
Pete.
/me doffs hat
I like this change myself.
/me dons hat
As I recall, the table was removed mostly because the vast majority of
implementations did not support any encoding other than UTF-8, and no
one (that I recall) reported implementing the detection table.
- m&m
Matthew A. Miller
< http://goo.gl/LM55L >
signature.asc
Description: OpenPGP digital signature