Subject: [Json] Proposal for texts and string for next draft

From: Paul Hoffman <[email-masked]>
Date: Tue, 3 Sep 2013 14:10:28 -0700

Greetings again. The WG chairs are continuing the effort to get specific wording for the next draft so that people will be able to see all the proposed text changes together so that we can continue to hone each one. We have recently done "numbers and precesion", and it's time to do "JSON texts and strings".

The following is the text that most recently seemed to enjoy general agreement. Does anyone have any strong objection to adding the following to the draft?

A JSON text which is composed entirely of Unicode characters (however encoded) will be interoperable in the sense that all Unicode-capable software which parses it will agree on the contents of names and values of object members.  However, the ABNF in this specification allows member names and string values to contain bit sequences which cannot encode Unicode characters, for example "\udddd" (an unpaired UTF-16 surrogate).  Instances of this have been observed, for example when a library truncates a UTF-16 string to a maximum allowable length without checking whether the truncation split a surrogate pair.  The behavior of software which receives JSON texts containing such values is unpredictable; for example, two different implementations might return different values for the length of a string value, or even suffer a fatal runtime exception.

--Matt Miller and Paul Hoffman

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 05 Sep 2013 11:05:20 +0900

Hello Paul,

Seeing nobody else responding, I'll give it a start.

> The following is the text that most recently seemed to enjoy general agreement. Does anyone have any strong objection to adding the following to the draft?

I don't have any strong objection, so please go with this text if that 
helps move things forward.

However, I have a number of minor improvements (I hope):

> A JSON text which is composed entirely of Unicode characters (however encoded) will be interoperable in the sense that all Unicode-capable software which parses it will agree on the contents of names and values of object members.

1) Why use future tense here? It's not wrong, but present would work 
too, and would make the (rather lengthy) sentence a bit simpler. So:
"will be interoperable" -> "is interoperable" and
"will agree" -> "agrees".

2) It would be good to have a reference just after "Unicode characters", 
to make sure that any potential discussions can be resolved unambiguously.

3) "(however encoded)" has the potential to include stuff that we don't 
want to include. It might be preferable to leave it out or to be more 
precise (e.g. "either directly encoded or encoded using escaping"). This 
may be a bigger or smaller issue depending on context, and depending on 
what reference we use in 2).

4) "all Unicode-capable software": This seems to legitimize JSON 
processing software that isn't Unicode-capable. That's certainly not 
what I'd want, and I hope that's not what the group wants.
So this is actually (at least close to) a non-editorial issue.

> However, the ABNF in this specification allows member names and string values to contain bit sequences which cannot encode Unicode characters, for example "\udddd" (an unpaired UTF-16 surrogate).  Instances of this have been observed, for example when a library truncates a UTF-16 string to a maximum allowable length without checking whether the truncation split a surrogate pair.  The behavior of software which receives JSON texts containing such values is unpredictable; for example, two different implementations might return different values for the length of a string value, or even suffer a fatal runtime exception.

5) "to a maximum allowable length": There is a minor potential that this 
confuses some people to think that such limitations are part of JSON, or 
are a good idea for applications using JSON. So I'd personally prefer to 
remove these few words.

6) There is a number allignment problem in the last sentence. It becomes 
obvious if you remove one clause: "two different implementations might 
suffer a fatal runtime exception".

Regards,   Martin.

---

From: Tim Bray <[email-masked]>
Date: Fri, 6 Sep 2013 14:20:48 -0700

I think most of Martin’s edits are improvements, specifically:

> Seeing nobody else responding, I'll give it a start.

[Paul called for objections, nobody responding is a GOOD THING.  But thanks
anyhow.]

> 1) Why use future tense here? It's not wrong, but present would work too,
> and would make the (rather lengthy) sentence a bit simpler. So:

Improvement

2) It would be good to have a reference just after "Unicode characters", to
> make sure that any potential discussions can be resolved unambiguously.'
>

Improvement

> what reference we use in 2).

Not worried, but could live with Martin's “either directly encoded...

> processing software that isn't Unicode-capable. That's certainly not what
> I'd want, and I hope that's not what the group wants.

Meh

> are a good idea for applications using JSON. So I'd personally prefer to

Improvement.

> suffer a fatal runtime exception".

Yep

> ______________________________**_________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/json<https://www.ietf.org/mailman/listinfo/json>
>