Re: [I18ndir] [art] Just uploaded draft-bray-unichars-03

[Tim Bray <[e-mail]>]

My understanding of what you’re saying: Since the IETF mandates the use of
UTF-8, and since the definition of UTF-8 forbids the encoding of surrogates
(while being technically capable of encoding them), there are no problems
here, nobody ever need worry about surrogates, even when a packaging format
explicitly allows all Unicode code points.

With respect, I disagree, if only because of JSON’s unfortunate escaping
mechanism, and because a service I helped build at AWS recently experienced
a production takedown because failure to deal with an incoming bogus
surrogate.  I think the statement in the current draft, that developers
must be prepared to handle various flavors of Unicode garbage, is factually
correct, and that explicitly restricting character repertoires will be
beneficial for specification authors and specification readers.

This is not trying to be a general how-to-use-Unicode BCP. If you want to
build one of those, spin up a WG. This draft identifies and discusses
several character repertoires, for use in references from other documents.


On Sep 10, 2023 at 12:30:32 PM, Carsten Bormann <[e-mail]> wrote:

>
>
> Sent from mobile, sorry for terse
>
> On 10. Sep 2023, at 19:52, Tim Bray <[e-mail]> wrote:
>
> However, you’ve established that the reading of 8949 is at least ambiguous
> on this point.
>
>
> That completely misleading impression is a symptom of the fact that this
> document is unsalvageable.
>
> STD 63 (RFC 3629) is utterly clear on what utf-8 is.
> Therefore rfc8949 did not have to do anything except reference STD  63 to
> be completely clear about what cbor text strings are as well.
>
> If you wonder about my strong reaction (and if you don’t), please do read
> rfc9413.
>
>
>