Rob, I think there are two related issues here:
a) If we need normalized strings (to avoid comparison suprises), we should have a common type for them; rfc6991-bis would be a proper home. I am _not_ saying we should delay the tags document for this, but we should think about providing a solution that can be easily reused. Right now, we often use strings as part of keys, which can lead to comparison issues. b) It seems that normalized strings only solve part of the problem. If an organization creates names for 'things', the organization likely wants to further restrict the format of these names to something sensible to avoid fun with different kinds of hyphens or emojis or ... So while creative unicode characters may technically work, there will likely be good reasons to avoid some of them. (There are reasons why we have coding styles for most programming languages.) These rules may, however, differ between organizations. We should not confuse a) and b). If IANA needs additional guidelines for tags (their coding style for tags), then we should provide these guidelines, i.e., this is a type b) action. The type a) action is needed to technically ensure that comparisons do not lead to surprises. But a) won't be an answer for all type b) issues. Of course, we could give IANA a 'coding style' that avoids any normalization issues. This would make IANA assigned tags safe but would not avoid comparison surprises for other sources of tags. /js On Fri, Feb 14, 2020 at 10:30:50AM +0000, Rob Wilton (rwilton) wrote: > 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 <iesg-boun...@ietf.org> On Behalf Of Schönwälder, Jürgen > > Sent: 13 February 2020 18:39 > > To: Alexey Melnikov <aamelni...@fastmail.fm> > > Cc: netmod-cha...@ietf.org; draft-ietf-netmod-module-t...@ietf.org; > > netmod@ietf.org; Joel Jaeggli <joe...@gmail.com>; Christian Hopps > > <cho...@chopps.org>; The IESG <i...@ietf.org> > > 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 > > <nore...@ietf.org> 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 > > > netmod@ietf.org > > > 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/> > -- 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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
