Subject: [Json] The General Way Forward

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Thu, 22 Aug 2013 15:51:12 +0000

The Working Group had a very productive discussion on August 21 (15:00 UTC); minutes will be posted presently. The discussion centered on how to arrive at an acceptable replacement document for RFC 4627. The general approach discussed in the interim is to document the known likely interoperability issues.  For each issue, the document will note the most interoperable behavior, and describe a couple of behaviors that can lead to interoperability problems.  The normative language will remain unchanged.

Matt and I want to verify that the WG agrees with this proposal for a way forwards from yesterday's WG meeting. If you do not agree with the above, please say so within the next few days, and certainly say why and what you would prefer instead.

If there is WG agreement about this way forward, expect to see new proposed text changes -- or revival of previously proposed changes -- written in this vein.  With these proposals, we will try using the acceptance process first posited in < www.ietf.org/mail-archive/web/json/current/msg00293.html >.

The current list of known issues are:

* Unicode surrogates
* duplicate names in objects
* comparison of strings (for object name uniqueness)
* number precision

Thank you,

Paul Hoffman and Matt Miller

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 22 Aug 2013 20:28:18 +0200

> The current list of known issues are:

I didn't quite get the conclusion of what seemed to be a brief discussion of this at the virtual interim, but any use of the Unicode encodings other than UTF-8 would be a real-world interop problem, too.
(The only reason I can find that it might not be a "likely" interop problem is that it's not happening a lot in the first place.)

Grüße, Carsten

---

From: John Cowan <[email-masked]>
Date: Sat, 24 Aug 2013 22:17:18 -0400

Carsten Bormann scripsit:

> I didn't quite get the conclusion of what seemed to be a brief
> discussion of this at the virtual interim, but any use of the Unicode
> encodings other than UTF-8 would be a real-world interop problem, too.

>From what I gather, we are forbidden to say anything about the encoding.

-- 
Evolutionary psychology is the theory           John Cowan
that men are nothing but horn-dogs,             http://www.ccil.org/~cowan
and that women only want them for their money.  [email-masked]
        --Susan McCarthy (adapted)

---

From: "John Levine" <[email-masked]>
Date: 25 Aug 2013 02:31:56 -0000

>From what I gather, we are forbidden to say anything about the encoding.

RFC 4627 says:

3.  Encoding

   JSON text SHALL be encoded in Unicode.  The default encoding is
   UTF-8.

   Since the first two characters of a JSON text will always be ASCII
   characters [RFC0020], it is possible to determine whether an octet
   stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking
   at the pattern of nulls in the first four octets.

           00 00 00 xx  UTF-32BE
           00 xx 00 xx  UTF-16BE
           xx 00 00 00  UTF-32LE
           xx 00 xx 00  UTF-16LE
           xx xx xx xx  UTF-8

It seems to me that it would not be a big leap to say that the
encoding SHOULD be UTF-8 and note that in practice many
implementations don't recognise other flavors of UTF.

R's,
John

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 25 Aug 2013 08:06:32 -0700

<definitely no hat>

> implementations don't recognise other flavors of UTF.

"The default encoding" in the current text sounds like a type of "SHOULD use this encoding".

--Paul Hoffman