JSON had already existed for a long time, as defined by json..org and 4627. There was/is a huge amount of deployed software that conformed to those definitions, which all allowed surrogates. 4627 was informative and thus couldn’t be cited, we needed a standards-track RFC for people to cite, but we totally couldn’t retroactively change the definition of JSON given the existence of all that deployed software.
You may also find this interesting: https://www.ietf.org/archive/id/draft-bray-unichars-08.html
On May 20, 2024 at 11:35:16 AM, Dale R. Worley <worley@xxxxxxxxxxx> wrote:
Tim Bray <tbray@xxxxxxxxxxxxxx> writes:4627 has been obsoleted by the current operative specification of JSON,RFC8259 (disclosure: editor), from which:
Well, ugh. I have to take it all back.
Uh, is there a coherent explanation why RFC 8259 allows non-character
code points? Or specifically why it allows surrogate code points?
"net-yet-assigned" code points I can see as plausibly allowing, but
surrogate code points will never be assigned characters.
Dale
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
