Thank you for the review Henry. And thank you for the engagement on it Carsten.
I do appreciate the desire to be precise with language and that it can be difficult to do so, particularly with respect to various encodings. Nonetheless, there have been a nontrivial number of implementations already that have not misunderstood what's required. I would be very reluctant to make a lot of changes based on a hypothetical misunderstanding. The content of this thread (to me anyway, who honestly didn't understand large parts of it), shows the ample opportunities for confusion that come in this area and I'd like to avoid the risk of introducing new confusion into the document. That being said, if there are bits of text that are outright wrong or misleading, those should be corrected.
On Fri, May 2, 2025 at 9:34 AM Carsten Bormann <cabo@xxxxxxx> wrote:
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
CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
