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

Julian Reschke <julian.reschke@gmx.de> Thu, 16 March 2017 11:35 UTC

Return-Path: <julian.reschke@gmx.de>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C6F1293DA; Thu, 16 Mar 2017 04:35:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.896
X-Spam-Level:
X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfRkaeN2dBB1; Thu, 16 Mar 2017 04:35:53 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D04F1293F3; Thu, 16 Mar 2017 04:35:48 -0700 (PDT)
Received: from [192.168.1.57] ([5.10.171.186]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LpKY5-1cLBDr1zuP-00f8L7; Thu, 16 Mar 2017 12:35:38 +0100
To: Peter Cordell <petejson@codalogic.com>, John Cowan <cowan@ccil.org>, Carsten Bormann <cabo@tzi.org>
References: <otwresf20y4vnpmoboqqjnux.1489359742487@email.android.com> <0d3258fa-0f9d-cc5d-06d7-fcba943349ad@gmx.de> <f63c6a4a-dfbb-e03a-ea1e-38002f81ced8@it.aoyama.ac.jp> <0631d12c-f447-8904-6e2d-81e02cc6e8d3@codalogic.com> <1e075450-d958-db9c-ae63-3cbf3733024c@outer-planes.net> <cf6e35ba-6a67-4b35-d4e1-e99fee6e9f19@gmx.de> <1F1D1DCB-767F-490D-A425-AB5E66D51D3E@tzi.org> <CAD2gp_R7raq0mzfhATTYONdowBm0HvVHFAqJqoVcLmYABrgPpA@mail.gmail.com> <c20a17b7-0329-db5b-0983-23ebe11720f2@codalogic.com> <1f87f5d4-cbb0-9350-2d08-31350fa7438d@gmx.de> <24d37dc6-eee2-5e0c-6d33-d3450750e886@codalogic.com>
Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, secdir@ietf.org, "json@ietf.org" <json@ietf.org>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <d520cf1f-bafd-6f62-c46c-482ad3a01f20@gmx.de>
Date: Thu, 16 Mar 2017 12:35:39 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <24d37dc6-eee2-5e0c-6d33-d3450750e886@codalogic.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:QvYKNl+YIL28AD0XU1A2JGKp6S6M3DOUVc1EaGB/G+UkBAFivk3 +AAJJB9OaotXw776xLwx6N5o4mq1iyiLqDsXPymrzhzaAjv7dZTPo3w/RYHpDrEqTqaOBHm m7vb/dgyziSA+4B6e2/utSbSYTtLrQHsHR9p6b9GUSDw4/+uxni+eJhhdNMjjYVBrfOiR18 QVCYbFGDRZ1b2ynAkEl4w==
X-UI-Out-Filterresults: notjunk:1;V01:K0:JMA4pUnV9jM=:yOcAwhox+cAoqmRwsIggql 0LsLsmfc5GzrT2+KEMmrfJQ0gacMRmobSLuk6VpTPmVd847EznRn18B9C1tPjpBMoG1ZAjV8a RCjCu0vsP5CHcaf+wVirFO2skmAac3nGO1dfdDJirfu5Ui0HJgKNvtMbMAqW4lWMWLUdadXVE 6oIAxU/Z9nhFG7uu5qIPStKcdwDtMYnKqRSx9qYoKGa2vFgsl5IPCLBU2XBcegXw+CEvjlhJB tLi7GFYjcLWDNYIcYoj6brByYskswdVYcB6xbrCOU9plGkEl72CqPaP4riTvy+plW1rmGEVW7 DbphptrLIydRo8Y400DHBK0o+OMsKTjlKJXwZ1TxvxsnNX/T+122p7xKxoGhmO98yRS7foY4f rHRzaTt4R391PbYCpUoL1L//vPXrM5cz3XEkYIOn6/7r9TmBnH7IC+3TigcNabO/KpkVOfKbM 1oPXFviF5eyj9x25HTkIwcJ8nc+6WNIkOpp/qxw6LkRfeyq6JHtVwhGAyLiiMHWm6yK2i6Dlo Qd225aUvi/HRd/ueGeHUo6NB+NR7oKRs1JYw4z2dQx8nCjCk5VoB3D4rZ1fucJQXdIraVFzJh 992v3FT7WUf8RcOcMzDQZce8ZuYkKcddU4S6L5yybxe2FULE7lT+KL2AeRT/XroSP0DhvyfPC gGKrLmk8kQIaMAuF0xVpwVPDcNK2AvOl54o9sjkPMowYCdbbLMitZ4JLB7ZtB7E1zRNWlXfI/ 5F2DnwL7w3chISCDxYFLrrUvyD9VqsRKHn9Ebzyb+he3CXnlxJZ4rwyEPKYn1uZ3y7oT7pCso IRfJOQd
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/DJsMR83PeIl2vA_ymBaoGGC2HXA>
Subject: Re: [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Mar 2017 11:35:56 -0000

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.

>> b) It doesn't state that the only way to support encodings other than
>> UTF-8 is to inspect the leading octets for zeros (or their lack of).
>
> UTF detection is one way.  It's not the only way.  If you want to go the
> UTF detection way or some other way, rfc7159bis shouldn't prevent it,
> but it doesn't have to tell you how to do it.

Oh, it's not the only way?

How do we interoperate then?

Best regards, Julian