> On Feb 14, 2020, at 1:05 PM, Randy Presuhn
> <randy_pres...@alumni.stanford.edu> wrote:
>
> Hi -
>
> On 2/14/2020 3:21 AM, Christian Hopps wrote:
>> How about I add this to the description of "typedef tag" in the module:
>>
>> description
>> "A tag is a type 'string' value that does not include carriage
>> return, newline or tab characters. It SHOULD begin with a
>> registered prefix; however, tags without a registered prefix
>> - SHOULD NOT be treated as invalid.";
>> + SHOULD NOT be treated as invalid. For the purposes of comparison
>> + non-ascii strings should use 'NFC' (RFC5198) normalization";
>> }
>>
>
> There are other considerations beyond normalization form.
> For the tip of the iceberg, see the definition of SnmpAdminString
> in RFC 3411, or the "SHOULD be avoided" stuff in RFC 5198.
Do you think that the above is appropriate to include, or should be left out as
doing more harm than helping?
BTW, I did look at the "SHOULD be avoided" (occurs twice that I saw) once
dealing with LFs and CRs which lucky for us is not part of a tags allowable
characters.
"
typedef tag {
type string {
length "1..max";
pattern '[\S ]+';
}
"
The other is about private use unicode, and I don't know anything about that.
I think we either include the diff quoted above, or do nothing, as this isn't
the document, as we all seem to agree, to fix the larger unicode issues with
YANG string type.
Thanks,
Chris.
>
> For things like tags where one would like to minimize accidental
> visual punning, I'd suggest NFKC should probably be given some
> consideration. Excellent presentation of the issues is
> available at https://unicode.org/reports/tr15/
>
> That said, these are issues that were raised in the earliest days of Netmod /
> Netconf, and no one should be surprised that they haven't gone away by
> themselves. So I find my self in ironic agreement with Andy that it doesn't
> make sense to wait for / impose a global solution, because there's plenty
> of evidence that having all sorts of ill-defined cases of questionable
> interoperability in theory hasn't been sufficient to prevent adoption of
> the technology.
>
> Randy
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
