Re: [Json] [Technical Errata Reported] RFC8259 (7603)

[Tim Bray <[e-mail]>]

On Aug 16, 2023 at 2:31:30 PM, Carsten Bormann <[e-mail]> wrote:

> Section 1.  Introduction
>
>   A string is a sequence of zero or more Unicode characters [UNICODE].
>
> This is the one we have been discussing (Section 1 discusses the JSON data
> model).
> From [1], D76 is the definition that works for me, not D10.
>

Yes, you’ve been clear about what you want, but obviously we can’ t do that
because JSON has been clear for years that naked surrogates are allowed
(obviously this makes me unhappy) and we can’t retroactively assert that
all these formerly compliant JSON documents are no longer valid. Not
without chartering another WG.

Section 8.2.  Unicode Characters
>
>   When all the strings represented in a JSON text are composed entirely
>   of Unicode characters [UNICODE] (however escaped), then that JSON
>   text is interoperable in the sense that all software implementations
> …
>   However, the ABNF in this specification allows member names and
>   string values to contain bit sequences that cannot encode Unicode
>   characters; for example, "\uDEAD" (a single unpaired UTF-16
>   surrogate).  Instances of this have been observed, for example, when
>
> Obviously, this whole section only works when Unicode Characters is D76.
>

I draw the opposite conclusion: That since JSON clearly blesses D10 not
D76, you should be careful to provide only D76 characters per Postel’s law.

I stand by my observation that this errata report tries to do in the errata
> process what only can be done in a proper WG consensus process.
>

I agree that the effect you’d like to achieve would require proper process.
I however do maintain that the report might be correct in that the choice
of “Unicode character” is potentially misleading.


> Grüße, Carsten
>
>