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

Stefan Hagen <stefan@dilettant.eu> Mon, 13 March 2017 16:18 UTC

Return-Path: <stefan@dilettant.eu>
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 E5AA0129509 for <json@ietfa.amsl.com>; Mon, 13 Mar 2017 09:18:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 Q6rBiXxW786h for <json@ietfa.amsl.com>; Mon, 13 Mar 2017 09:18:03 -0700 (PDT)
Received: from mailrelay2.pub.mailoutpod1-wdc1.one.com (mailrelay2.pub.mailoutpod1-wdc1.one.com [104.37.35.57]) (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 12A94129522 for <json@ietf.org>; Mon, 13 Mar 2017 09:18:02 -0700 (PDT)
X-HalOne-Cookie: 9db20b3b3eef183271b7f381933937b44264d427
X-HalOne-ID: 601bc2a5-0806-11e7-b39d-549f35fe4221
Received: from [10.86.247.37] (unknown [198.135.0.233]) by mailrelay1.pub.mailoutpod1-wdc1.one.com (Halon) with ESMTPSA id 601bc2a5-0806-11e7-b39d-549f35fe4221; Mon, 13 Mar 2017 16:01:58 +0000 (UTC)
To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
References: <otwresf20y4vnpmoboqqjnux.1489359742487@email.android.com> <0d3258fa-0f9d-cc5d-06d7-fcba943349ad@gmx.de> <f63c6a4a-dfbb-e03a-ea1e-38002f81ced8@it.aoyama.ac.jp>
From: Stefan Hagen <stefan@dilettant.eu>
Message-ID: <bf1db249-faf3-f0bd-76a4-5b73e816280e@dilettant.eu>
Date: Mon, 13 Mar 2017 17:01:52 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <f63c6a4a-dfbb-e03a-ea1e-38002f81ced8@it.aoyama.ac.jp>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/4ubY45sLMt_Co00tesMl3DltQd8>
Cc: Benjamin Kaduk <kaduk@mit.edu>, draft-ietf-jsonbis-rfc7159bis.all@ietf.org, "json@ietf.org" <json@ietf.org>, 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 16:18:05 -0000

Yes, tired is a good match && I second the proposed change.
"Stefan"

On 13/03/17 08:51, Martin J. Dürst 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