Re: [I18ndir] [art] New Version Notification for draft-bray-unichars-06.txt

[Rob Sayre <[e-mail]>]

On Mon, Oct 2, 2023 at 9:14 AM Carsten Bormann <[e-mail]> wrote:

> >
> > I don't think anyone really disagrees with the ideals you've got here.
> The problem is that a large amount of running code is confused in exactly
> the way you describe. So, implementers do have to know about code points.
> The IETF could pound its collective fist and say "all ill-formed Unicode
> must be rejected”,
>
> Yes, please.
> The fact that this is the only reasonable way forward is the point of RFC
> 9413.
>
> > but that won't work. This document is a decent attempt at gradually
> improving things.
>
> Rob, you come from a perspective where everyone already is wearing rubber
> boots so they can slog through the toxic waste.
> This is relevant for maybe 5 % of the IETF protocols.
> This document needs to be useful for the other 95 %, without dipping those
> protocols in toxic waste, too.
>

I mean, I didn't really get my way, though. The document still doesn't
acknowledge that you can accept the toxic waste! But that's ok, I can live
with it. The repertoires it describes are really helpful, because they make
it very easy to write a test suite. Just loop through many code points
(maybe all of them), knowing which ones are not allowed.

As for the merits of "halt and catch fire" error handling, I'm pretty sure
the author has been around the block on that one, and he's not going for
that here. It makes sense to me.

Basically, UTF-8 is a work of genius, but it arrived 10 years too late.
JavaScript, Windows, Java, and all the rest of them were underway before we
got RFC 2277. Things would be much different if it had appeared in 1982 and
everyone then realized that you don't need Θ(1) access to characters in a
string...

thanks,
Rob