Hi Juergen, This sounds potentially useful to me, although should this be for general unicode strings (e.g. ones that might include spaces), or just identifiers (without any spaces)?. Is this something that could/should go into rfc6991-bis, or at least be discussed in that context?
I would have thought that normalization would be required wherever a configurable unicode string is used as a list key, or leaf-list. Thanks, Rob > -----Original Message----- > From: iesg <[email protected]> On Behalf Of Schönwälder, Jürgen > Sent: 13 February 2020 18:39 > To: Alexey Melnikov <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; Joel Jaeggli <[email protected]>; Christian Hopps > <[email protected]>; The IESG <[email protected]> > Subject: Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod- > module-tags-07: (with DISCUSS) > > And a longer term solution might be to define a YANG Net-Unicode string > datatype that can be used in all situations where non-normalized strings > may cause problems. The problem (if one agrees it is one) is likely much > bigger than just YANG tags, there likely are many uses of YANG strings > where normalization would be desirable. > > /js > > On Thu, Feb 13, 2020 at 01:10:02PM +0000, Alexey Melnikov wrote: > > Hi Christian, > > > > On Thu, Feb 13, 2020, at 12:30 AM, Christian Hopps wrote: > > > The intent in the document is to place as few restrictions on tags > > > as possible to allow for future-proofing and organic growth of use > > > both within and outside of SDOs. For standard tags we trust IANA > > > (and the human behind the process) to make the call on whether a tag > > > is already present. :) > > > > And the problem with that is that because there might be multiple ways > to encode in Unicode visually indistinguishable tags IANA would end up > asking IESG for help. > > > > So you need to at minimum specify a Unicode normalization form to use. I > suggest you normatively reference RFC 5198 here. > > > > > Having worked for a company where a lot of XML string data was > > > non-ascii I find limiting to ascii to be rather restrictive. > > > > Best Regards, > > Alexey > > > > > > > > Thanks, > > > Chris. > > > > > > > On Apr 11, 2019, at 9:41 AM, Alexey Melnikov via Datatracker > <[email protected]> wrote: > > > > > > > > Alexey Melnikov has entered the following ballot position for > > > > draft-ietf-netmod-module-tags-07: Discuss > > > > > > > > When responding, please keep the subject line intact and reply to > > > > all email addresses included in the To and CC lines. (Feel free to > > > > cut this introductory paragraph, however.) > > > > > > > > > > > > Please refer to > > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > The document, along with other ballot positions, can be found here: > > > > https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/ > > > > > > > > > > > > > > > > ------------------------------------------------------------------ > > > > ---- > > > > DISCUSS: > > > > ------------------------------------------------------------------ > > > > ---- > > > > > > > > This is generally a fine document, but after checking RFC 7950 > > > > syntax for strings I question why you think you need non ASCII > > > > tags. There are so many problems that can arise from that. For > > > > example, how would IANA be able to enforce uniqueness of Unicode > > > > tags written in different Unicode canonicalisation forms? > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
