Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03

[Alexey Melnikov <[e-mail]>]

> On 16 Mar 2017, at 11:35, Julian Reschke <[e-mail]> wrote:
> 
>> On 2017-03-16 12:23, Peter Cordell wrote:
>>> On 16/03/2017 10:49, Julian Reschke wrote:
>>>> On 2017-03-16 11:28, Peter Cordell wrote:
>>>> 
>>>> 8.1.  Character Encoding
>>>> 
>>>>   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.  JSON text MAY be encoded in other encodings if
>>>>   the generator is sure that the intended parsers can read them.
>>>> 
>>>>   Implementations MUST NOT add a byte order mark to the beginning of a
>>>>   JSON text.  In the interests of interoperability, implementations
>>>>   that parse JSON texts MAY ignore the presence of a byte order mark
>>>>   rather than treating it as an error.
>>>> 
>>>> Are "generator" and "parser" the correct terms to use in this instance,
>>>> or does that functionality sit above the character encoding layer?
>>>> ...
>>> 
>>> Not convinced.
>>> 
>>> a) It's not constrained to UTF-8/16/32, so people might decide to
>>> support ISO-8859-1, or UTF-7-
>> 
>> Why is that a problem if the generator knows the parser can read it?  If
>> someone wants to use EBCDIC for whatever reason, are they not allowed to
>> call it JSON?
> 
> For application/json, it would violate a SHOULD-level requirement... <https://greenbytes.de/tech/webdav/rfc7159.html#rfc.section.8.1.p.1>:
> 
> "JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32. 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)."
> 
> So I agree it's technically allowed.

As this document is intended to be Internet Standard, it should strive to remove number of choices and generally non interoperable features. So listing the minimal list of allowed encodings in this document would be a good thing.