IETF Logo Mail Archive

Re: [Json] I-D Action: draft-ietf-jsonbis-rfc7159bis-04.txt

Carsten Bormann <cabo@tzi.org> Fri, 21 July 2017 05:14 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 4319C12EAAA for <json@ietfa.amsl.com>; Thu, 20 Jul 2017 22:14:58 -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 P9xi9UFurl8z for <json@ietfa.amsl.com>; Thu, 20 Jul 2017 22:14:57 -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 BDC0C126C23 for <json@ietf.org>; Thu, 20 Jul 2017 22:14:56 -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 v6L5EquQ026277; Fri, 21 Jul 2017 07:14:53 +0200 (CEST)
Received: from surfer-172-30-2-218-hotspot.internet-for-guests.com (107.223.broadband2.iol.cz [83.208.223.107]) (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 3xDJqJ5SFkz3ZK4; Fri, 21 Jul 2017 07:14:52 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <f1a6b553-c787-e248-67bd-74d68d98a845@gmx.de>
Date: Fri, 21 Jul 2017 07:14:52 +0200
Cc: Peter Saint-Andre - Filament <peter@filament.com>, json@ietf.org
X-Mao-Original-Outgoing-Id: 522306892.012584-824a091485022e90ff5ad4991b49f226
Content-Transfer-Encoding: quoted-printable
Message-Id: <262E8314-263A-4443-B912-AFCF1A3277B2@tzi.org>
References: <150047191184.7507.7143481683564082881@ietfa.amsl.com> <DB9BA7EA-D393-4079-B347-620A09280B26@isode.com> <CAC4RtVBYMrRCrUZ1qqD+_rH4M8N23GOgbbh=921fEYqH+gCm5Q@mail.gmail.com> <c06e583a-965e-9eaf-975f-e6876ac056ed@filament.com> <f1a6b553-c787-e248-67bd-74d68d98a845@gmx.de>
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/fmv9-jYWYVd9_fBKWNuV902EuFE>
Subject: Re: [Json] I-D Action: draft-ietf-jsonbis-rfc7159bis-04.txt
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: Fri, 21 Jul 2017 05:14:58 -0000

On Jul 21, 2017, at 06:20, Julian Reschke <julian.reschke@gmx.de> wrote:
> 
>> 
>> I suggest:
>>    When an entity transmits JSON text over a network, e.g. as the
>>    payload of an application protocol, it MUST encode that text using
>>    UTF-8 [RFC3629].
> 
> This gets us back to the suggestion to apply this rule to the use of the application/json media type (and types derived from it).

The nit-picking opportunity here is that we don’t want to change NFS in case someone accesses a file with UTF-32 JSON in it over the network protocol NFS.  We could recognize this as nit-picking, or use a phrase such as “intended by the protocol to be JSON” — media types are not the only way such an intention could take shape.

(Re the previous discussion: We do not have to define “network protocol” further.  Sheesh.  But the point is that any protocol that claims to interchange JSON should define the JSON to be used in UTF-8 format, just as we define application/json to be UTF-8 format.)

Grüße, Carsten

v2.23.0 | Report a Bug | By Email