[Last-Call] Re: [art] Re: Artart telechat review of draft-ietf-jmap-contacts-09

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux