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

Carsten Bormann <cabo@tzi.org> Mon, 13 March 2017 15:56 UTC

Return-Path: <cabo@tzi.org>
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 C9E16129432; Mon, 13 Mar 2017 08:56:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=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 G5Czki8HfRA5; Mon, 13 Mar 2017 08:56:38 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63F381270B4; Mon, 13 Mar 2017 08:56:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2DFuY68002705; Mon, 13 Mar 2017 16:56:34 +0100 (CET)
Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vhjCk4LlrzDGt5; Mon, 13 Mar 2017 16:56:34 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <f63c6a4a-dfbb-e03a-ea1e-38002f81ced8@it.aoyama.ac.jp>
Date: Mon, 13 Mar 2017 16:56:33 +0100
X-Mao-Original-Outgoing-Id: 511113393.671415-a4a40423d1a75bc00add897e6d0ad1b2
Content-Transfer-Encoding: quoted-printable
Message-Id: <3DFA075D-3F19-48B3-821D-79EA3CB4A908@tzi.org>
References: <otwresf20y4vnpmoboqqjnux.1489359742487@email.android.com> <0d3258fa-0f9d-cc5d-06d7-fcba943349ad@gmx.de> <f63c6a4a-dfbb-e03a-ea1e-38002f81ced8@it.aoyama.ac.jp>
To: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/jnj5VnEwXhRIsgtZVMkSOc_rJzE>
Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, "json@ietf.org" <json@ietf.org>, IETF <ietf@ietf.org>, secdir@ietf.org
Subject: Re: [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 13 Mar 2017 15:56:40 -0000

+1000

Grüße, Carsten

> On 13 Mar 2017, at 08:51, Martin J. Dürst <duerst@it.aoyama.ac.jp> wrote:
> 
> On 2017/03/13 15:23, Julian Reschke wrote:
>> On 2017-03-13 00:07, Elwyn Davies wrote:
> 
>>> Does the WG really want to revisit the anguished discussions that
>>> resulted in the changes to Section 8.1 of draft-ietf-json-rfc4627bis
>>> between versions 07 and 08 back in late November 2013?
>>> 
>>> See https://www.ietf.org/mail-archive/web/json/current/msg02053.html and
>>> many, many messages beore this.
> 
>> No, but on the other hand, we should acknowledge that apparently the
>> text both about what's mandatory and how auto detection works is not as
>> clear as it should.
> 
> It looks to me as if at the time of the above message in the WG, the chairs were successful in presenting a consensus, probably at a stage when the participants in the discussion where getting tired.
> 
> It seems that when put in the wider context of the IETF, that compromise now looks somewhat shaky.
> 
> 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.
>>>>> 
> 
> That should then go together with a MIME registration that only lists UTF-8.
> 
> Regards,   Martin.
> 
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>