Re: [art] draft-bray-unichars

[Carsten Bormann <[e-mail]>]

On 31. Aug 2023, at 12:17, tom petch <[e-mail]> wrote:
> 
> And AFAICT none of them cover the case I know best, that of YANG RFC7950 p.209.

At least you excluded the surrogates code points...

> This is a topic that surfaces regularly with YANG modules where there are many display strings and the question is what to allow and what not to allow.  It was an issue with SMI previously but there there was a type intended for that use but YANG does not have that.  I cannot recall a YANG module specifying a Unicode subset to use.

Just a random observation: If you want to *display* these strings outside the English-language-only engineering environment, you’d probably want to provide for a language tag.
(I think YANG 1.1 did a good thing keeping this open.)

I wrote modern-network-unicode [1] for a similar case, where the authors of a draft naturally weren’t experts in the relevant questions.
There then is a strong danger of the restatement anti-pattern (*), as well as some incompleteness in the actual design.

So I agree we want to crystallize some advice, as well as providing a document that specifications can point to.
I just seem to have a slightly different perception than draft-bray-unichars on what the information in there should be…

Grüße, Carsten



[1]: https://datatracker.ietf.org/doc/draft-bormann-dispatch-modern-network-unicode/

(*) E.g., should every piece of ABNF respecify what are the Unicode non-characters today?  I don’t think so.