On Mon, Feb 17, 2020 at 10:40:30AM -0500, Christian Hopps wrote: > > > > On Feb 17, 2020, at 9:07 AM, Rob Wilton (rwilton) <rwil...@cisco.com> wrote: > > > > Hi Juergen, > > > > Please see inline ... > > > >> -----Original Message----- > >> From: Schönwälder, Jürgen <j.schoenwael...@jacobs-university.de> > >> Sent: 14 February 2020 14:31 > >> To: Rob Wilton (rwilton) <rwil...@cisco.com> > >> Cc: Alexey Melnikov <aamelni...@fastmail.fm>; 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) > >> > >> 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. > > [RW] > > > > I agree. Note, I am also not proposing that we delay module-tags for > > rfc6991-bis. > > > > RFC 7950 states that strings are not normalized by default (section > > 9.4..2). Thinking about this some more, I think that it is reasonable to > > make it the client's responsibility to normalize strings, if required. > > > > Chris, this would mean that no change to the typedef description is > > required. > > > >> > >> 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. > > [RW] > > > > So, solving B seems reasonable for the IANA defined module tags, following > > Alexey's suggestion of referencing RFC 5198 for normalization. > > I will not put the additional text in the typedef and instead put it in the > guidance for the IANA registry then: > > This registry allocates tags that have the registered prefix > "ietf:". New values should be well considered and not achievable > -through a combination of already existing IETF tags. > +through a combination of already existing IETF tags. For comparing > +non-ascii strings, 'NFC' [[RFC5198]] normalization SHOULD be used. > > Unless there are further objections, I believe this, and a small change to > the security section suggested by Benjamin K, will clear the remaining > DISCUSS so I will republish soon.
Perhaps this wording is clearer about who is responsible for normalization: -through a combination of already existing IETF tags. +through a combination of already existing IETF tags. IANA assigned +tags must conform to Net-Unicode as defined in RFC 5198 and they shall +not need normalization. And then lets hope that others assigning tags follow this advice. ;-) /js -- 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
