Re: [Json] Unpaired surrogates in JSON strings

[Douglas Crockford <[e-mail]>]

On 6/5/2013 5:18 PM, Tim Bray wrote:
> In section 2.5 of 4627, a reasonable reading of the text clearly 
> disallows unpaired surrogates, because the discussion is exclusively 
> of characters, which surrogates aren’t; they are code points, but 
> there are no characters that have those code points. From the 
> introduction: “A string is a sequence of zero or more Unicode 
> characters”. Case closed.
>
> A loose reading of the BNF probably allows naked surrogates if you 
> ignore what the text says.
>
> I think anyone who’s delivering those codepoints is already in 
> violation of 4627, and I don’t think we should retroactively forgive 
> those sins.
>
> -T
>
>
> On Wed, Jun 5, 2013 at 4:55 PM, Paul Hoffman <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     On Jun 5, 2013, at 11:57 AM, Douglas Crockford
>     <[e-mail] <mailto:[e-mail]>> wrote:
>
>     > On 6/5/2013 11:47 AM, John Cowan wrote:
>     >> Douglas Crockford scripsit:
>     >>
>     >>> Such a requirement will be breaking. Breaking changes are out
>     of scope.
>     >> How is it a breaking change to limit what documents are allowed
>     to be
>     >> *generated*?
>     >>
>     > Because JSON is currently being used in applications that
>     deliver those codepoints.
>
>     Can you say why an application would do that, given the JSON
>     specification?
>
The application that does that is JavaScript. Any 16-bit value can be 
put next to any other 16-bit value and then JSON encoded. The meaning of 
'character' throughout the RFC is ECMAScript's, which is roughly the 
same as Unicode's code point. This can be seen in the BNF. When the RFC 
talks about Unicode Characters, it is in the sense of Unicode 
Characters  and not EBCDIC Characters.

JSON is just the pipe. It doesn't need to be enforcing Unicode over 
JavaScript. The sender and receiver can argue about what it means to be 
a character. JSON has always been agnostic about this.