Re: [Json] Call for Consensus: Proposed Text for "8.1 Character Encoding"

"Matthew A. Miller" <> Thu, 23 March 2017 14:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 65FAD129702 for <>; Thu, 23 Mar 2017 07:40:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 FfnIYfWRWxIQ for <>; Thu, 23 Mar 2017 07:40:54 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5C8281296D6 for <>; Thu, 23 Mar 2017 07:40:54 -0700 (PDT)
Received: by with SMTP id y18so41394554itc.0 for <>; Thu, 23 Mar 2017 07:40:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=I/TsAIMHo5+5VGa0hmYO73Sx2A+7m7IjyQMvz3oK/Xw=; b=bZ1YzvHFVmSRLInw9RUfGXB428a0PctPgu1fHV+ct6aOZ5UhmNAnoiLgRySNH+q/dN uosPGkGzTUViz5RAz70tNi06xRfpmzSDUDBIVrQ4hC8oR5idSNiKkEg3aIMXev0a7Q0D fPMtFtnQgs9iZOFudwsLxoQj1NjSKTw4kiS+4fmpI260F5rnINVQd7SRCKVfqMMRM9ep qUTGsvzEnbnQhcJpG3eCU6y7Fy6QZtkIP7Vs+AttUbQPiESJXcCF1XDW0cjzREAPRys8 iibvH94a8ncTNtAh05Au/UoNehfVEG4696kN/7EZZQyG+CwkwT8TbxF5DLgHblLK1VYW nN5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=I/TsAIMHo5+5VGa0hmYO73Sx2A+7m7IjyQMvz3oK/Xw=; b=Xq92Cqa5flfpNQ5XIfaWAOZ522tbbuRDox0mLsomy43WYWPoUIJd85FwvqG2srYDWr UkOfwkfE1EmBeH8h9FSud9StqHnJWcNE4Ep3o9rWhYsOO/L9n3rWR1Z3KCfY/zEMs/XN t+tL67VW7mPuotzaVZxObQtNxeSo+erRtwkOmlfT5kYK1KM5uwfGUonQlwMVKLg8+lMq UJjZUlQ4L7woZLEf5dAyBD8ecrlCK10Ht+tnmuHbG+hELEPt9KTFz0Lkjy1vEGn1hib1 Dhf3NxCM5kpbqasKmBRNkC6Dbd2pXYA3xgv67DTko30RmLOqVZcy8zFriQSZen4jffd0 g/aQ==
X-Gm-Message-State: AFeK/H2eBe+JX1g3HRJv8QgT6I1fTPckyjVQNxi94XafYXeEpFtGm0q53tfj1lERosaUCA==
X-Received: by with SMTP id a3mr2895831itg.30.1490280053471; Thu, 23 Mar 2017 07:40:53 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id f130sm209237iof.2.2017. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Mar 2017 07:40:52 -0700 (PDT)
References: <> <> <> <> <> <> <> <>
From: "Matthew A. Miller" <>
Message-ID: <>
Date: Thu, 23 Mar 2017 08:40:52 -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="kBOxtUweijlSsKhkWgcoKPAmewxvdtEKs"
Archived-At: <>
Subject: Re: [Json] Call for Consensus: Proposed Text for "8.1 Character Encoding"
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, 23 Mar 2017 14:40:55 -0000

Hello JSONbis,

It looks like we have consensus for the following text for all of
Section 8.1:

JSON text MUST be encoded in UTF-8, UTF-16, or UTF-32 Section 3 of
[UNICODE].  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 encoded in
UTF-16 or UTF-32. Text encoded in character encodings other than UTF-8,
UTF-16, or UTF-32 cannot be used with the media type "application/json".

Implementations MUST NOT add a byte order mark (U+FEFF) 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.

Recipients that wish to support Unicode encodings other than UTF-8
can do this using a detection mechanism that is based on the fact
that the first character will always have a Unicode code point
greater than 0 and less than 128, thus the UTF-16/32 variants can
be detected by inspecting the first octets for nulls.

Please speak now if you have any objections.

Thank you all,

- m&m

Matthew A. Miller
JSONbis Chair