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

"Matthew A. Miller" <> Thu, 16 March 2017 20:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E7D43129A62 for <>; Thu, 16 Mar 2017 13:25:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c6j-bh4FqXAU for <>; Thu, 16 Mar 2017 13:25:27 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c0f::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 87C67129A57 for <>; Thu, 16 Mar 2017 13:25:27 -0700 (PDT)
Received: by with SMTP id a12so9624978ota.2 for <>; Thu, 16 Mar 2017 13:25:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=wDF3iV2xjqiSJU3I36/YAMSxwcGxY7Cuy0sxa8EvXQA=; b=sKSiJ2CFESxDlEXbSpPAE1awSZW+TBXd7IYG9fGoGjCv6S8Mk0SuwcEvinpCHBJIi9 PaSSv8PAjbeFVAPhRpm4Mw7bPd1kn8rhE+P9fruSaq3yjVDiFG+y8xopaRBrEVMvKbi/ cOXZfx2aIZbtmcS08irtQRvSVi62d+F+w8TKY4fsj88DsJthSRcCh62n2BqpG2BQbz7a Q/m0wmkD9tshfZFsc0kld8yuaVjW1az++nBue+ZYD9uZMB0hOybvvGjOf845FLomDfe5 mNLEx8007FTulNTV1slkosDw3i+UXGkQzMzyvyBBL5MdahwFs/XC3RUWqYG1Czvoh+gC NCFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to; bh=wDF3iV2xjqiSJU3I36/YAMSxwcGxY7Cuy0sxa8EvXQA=; b=fPMLhPJ+dLdTGupwfSMwmdGt9J0jOMIib9M2uiV4f57ERqEoZGwSsbUrZccOCNcfMh T+pToUSW2W6qETfywX97FT4m4llRj/Gc4McAVXY+aRCDUawJEFPprrNuaEGxRdbzHFXF 96peA662rEc8FbGgpxUjzxbhJ3/laSaoFmqorpGEfTKbahKKHzHbWsnAbchZA2I8Ji+4 bv8y1PD2MXcjBwKLWeZbIpqFfTS3OPoAj331nmTy4AycFOrj3FerkMwsOEAaoIXzc7Qu 7gJ5m9VUvQ9LwGTPJZVx0eq/2rBNeLdLDXhezBGODDuT76iKavdtEzoIkB3al19KUijZ UnaA==
X-Gm-Message-State: AFeK/H2rXC0tPldPxhlZxKdK/ZgkADirKe0N6jttp5WiAFqVvR1XVmSaPvtn9h7woUwwLw==
X-Received: by with SMTP id o206mr5836846oib.37.1489695926929; Thu, 16 Mar 2017 13:25:26 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id v74sm2560468oie.3.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Mar 2017 13:25:26 -0700 (PDT)
Sender: Matthew Miller <>
To: John Cowan <>
Cc: Peter Cordell <>, Alexey Melnikov <>, Julian Reschke <>,, "" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: "Matthew A. Miller" <>
Message-ID: <>
Date: Thu, 16 Mar 2017 14:25:24 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UrGKF8OVetQO1QV4LPgsiCx3k3xLE68w5"
Archived-At: <>
Subject: Re: [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 [rfc7159bis scope]
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Mar 2017 20:25:29 -0000

On 17/03/16 11:33, John Cowan wrote:
> On Thu, Mar 16, 2017 at 11:18 AM, Matthew A. Miller
> <
> <>> wrote:
>     While I am generally sympathetic to accommodation, I don't think there
>     is support in the working group for expanding the allowed encodings
>     beyond what RFC 7159 already stated.
> Indeed, I will now go further.  I am now in favor of saying "JSON SHALL
> be encoded in UTF-8", without further qualification.  This is what
> everybody actually does, and why shouldn't we say so?

[ /me doffs hat ]

To keep the change from being too drastic, I think it necessary to leave
in the text forbidding a byte order mark.

For completeness, the complete text for 8.1 would be:

   JSON text SHALL be encoded in UTF-8 [UNICODE] (Section 3).

   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.

That said, I'm not quite sure about going that far.  The web certainly
uses UTF-8 and no other, but the scope is greater than that.  I would
suggest keeping much of Peter's original text, with a small change to
include the prohibition of encodings outside of UTF-8/-16/-32[1]:

   JSON text SHOULD be encoded in UTF-8 [UNICODE] (Section 3), and MAY
   be encoded in UTF-16 or UTF-32.  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.

- m&m

Matthew A. Miller

[1] RFC 7159 used "SHALL", which RFC 2119 specifies the meaning to be
identical to "MUST".