[art] Re: draft-bray-unichars-09 review

[Tim Bray <[e-mail]>]

>
> On Oct 8, 2024 at 10:14:23 AM, Julian Reschke <[e-mail]>
> wrote:
>
I believe we should avoid BCP14 keywords here; they are for protocol
> definitions (etc), not to put requirements on other specs or even spec
> authors.
>

At one level, I sort of agree, if only because I’ve worked on a lot of
drafts over the years and can’t remember ever using this language except
for describing a particular protocol or data format.

On the other hand, I just went and re-read RFC2119 and it doesn’t limit the
kinds of usages of its keywords at all. So this is more about IETF culture?

I also went and looked at RFC7564, PRECIS, and because it’s extensible, it
uses RFC2119 language to describe limitations on extensions. E.g. "A
profile of a PRECIS string class MUST define the width mapping…”

Unichars doesn’t offer any extensibility, it just defines three subsets. I
had thought that BCP14 would come into play in other drafts that reference
it, E.g. “The content of the Sender field MUST contain text conforming to
the Unicode Assignables Subset as specified in [Unichars].”

Now it occurs to me that we could beef up the definition of each of the
Unichars profiles with BCP14 language. Currently it says "Unicode
Assignables can be expressed as an ABNF production:” and it could say.
“Unicode Assignables text MUST consist of Unicode code points encoded in
UTF-8 and conforming to the following ABNF.” Or some such. Does that help
spec authors who want to reference Unichars? Not obvious to me that it’s
better or worse…