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

[Tim Bray <[e-mail]>]

On Sep 23, 2023 at 8:24:15 AM, Asmus Freytag <[e-mail]> wrote:

> Identifiers benefit from a limited repertoire, often sharply limited, to
> aid in reliable recognition. Being mnemonic devices, there's no need to be
> able to represent all edge cases for all languages, as there would be for
> text. There are many other specifications that provide identifier
> repertoires, such as UAX#31, IDAN2008, domain-specific repertoires, and so
> on. For the purpose here, it would be useful to mention that there is a
> class of use cases that does need stricter repertoire limits than discussed
> here and that what is discussed here isn't recommended for those purposes.
>

So, you’re suggesting a note saying that protocols can further restrict
repertoires on a per-field basis.  This seems so obvious that I doubt it
adds value, but if multiple people want it I guess it can do no harm.

> Then there's a the string data type. We don't need to define it, because
> Unicode defines it already, but it would be useful to put it into
> perspective. As defined, the string data type includes code points that can
> only ever be used in internal processing, and it includes ill-formed
> encoding forms, because they will normally occur in transient states during
> processing and may need to be temporarily held when receiving input (before
> and during verification). Those are the reasons that generic string data
> types are not restricted, unlike text content fields conforming to a
> protocol. (There may be protocols that should be defined on the basis of
> strings and not text content and for those, the recommendations here would
> not apply. And that should be explained).
>
I can’t see any reason to discuss string processing in programming
languages. The IETF is concerned with the bytes that flow across the
network. Our job is to document what to transmit and what to receive.