On 2. May 2025, at 16:18, Henry S. Thompson <ht=40inf.ed.ac.uk@xxxxxxxxxxxxxx> wrote: > > Carsten Bormann writes: > >> ... > >> For IETF purposes, JSON text is always UTF-8 encoded, so there is no >> difference. > > I don't agree, based on my reading of 8259. It's clear that a single > U+0076 character can occur in "JSON text", but as such that text is > _not_ a byte sequence JSON (STD90) is phrased in terms of Unicode code points. You have to read STD63 to find out how the byte sequences are generated from those code points (and which code points are valid in the first place). Most implementers have done that reading in the last 25 years or so... I don’t think it is the purpose of this specification to regurgitate UTF-8 and JSON principles. >>> The problem you've encountered arises when one tries to illustrate >>> UTF-8 byte sequences in an unambiuous way in, for example, an IETF >>> RFC. >> >> You can always write the whole thing in hex. > > Not in the kind of spec we're discussing here, I would think. (Not following, sorry) >> But typically that is really needed only in very few places, and I think we can assume that readers of this document understand JSON at least a little bit. > >> Apart from that, you can use JSON’s \u escapes (but then you get >> different JSON text). > > Indeed, that's part of what I was trying to make sure is properly > illustrated. Again, I don’t think this is necessary, and a single example in hex might suffice if there really is appetite for adding this. > '["_26bc4LT-ac6q2KI6cBW5es", "family_name", "Möbius"]' Oh no. Grüße, Carsten -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
