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

[Rob Sayre <[e-mail]>]

On Wed, Sep 27, 2023 at 9:21 AM Tim Bray <[e-mail]> wrote:

> On Sep 25, 2023 at 10:53:44 PM, Asmus Freytag <[e-mail]>
> wrote:
>
>>
>> I would argue that at the end of 1. Introduction would be a good place to
>> mention what this document does *not* address.
>>
>> "This document does not address protocols where every single Unicode code
>> point must be supported for specific reasons, or protocols and data formats
>> that need to further subset the valid code points based on criteria
>> different from the ones presented here."
>>
>
> Having thought about this, I can see no value in mentioning
> situations/components that handle all-the-code-points garbage.  This
> document exists to provide options for people specifying new protocols &
> data formats and explains (clearly, I hope) why all-the-code-points is not
> provided as one of those options.
>
> On the other half, it is certainly the case that some text fields are
> going to have much more restricted repertoires than any of the ones listed
> in this document. I’m trying to imagine a situation in which stating this
> fact would be helpful to a reader, and what that reader would need to hear.
> So far I’m coming up empty.
>

At first, I thought it was a nice way to deal with this problem:
"In a way, just adding that explicitly also prevents abuse of the document
by people making false claims that it is intended to prevent you from
dealing with the full set or restricted sets,"

But the sentence is not actually true. The document does address the JSON
issue in a few places. Maybe

"Some protocols and data formats allow every single Unicode code point, and
some further subset the valid code points based on criteria different from
the ones presented here."

The question for the authors is whether they think the claim Asmus
describes would be a bogus one. I think it would be, and I believe what I
wrote is true. It's less direct than saying one way to deal with
problematic code points is to accept them (also true), but it gets the job
done.

Side note: Section 3 says "Surrogate characters have been observed to cause
software failures." but I think you want to say "Surrogate code points"
here.

thanks,
Rob