Re: [I18ndir] I18ndir last call review of draft-ietf-regext-dnrd-objects-mapping-06

[John C Klensin <[e-mail]>]

--On Friday, March 6, 2020 07:55 -0500 Marc Blanchet
<[e-mail]> wrote:

>> If a protocol allows mulitple forms, as Unicode does for its
>> identifiers, it would still be good form to pick a canonical
>> representation for such protocol-relevant items and as
>> reviewers we should have a policy on that.
> 
> For protocol identifiers, there is already a framework to
> manage that: Precis. We don't need to reinvent the wheel in
> this directorate.

Marc,

Agree completely.  However, my interpretation of Asmus's
suggestion and my variation on it is that the requirement could
be satisfied by a pointer to PRECIS (and, presumably, a
particular profile of PRECIS, which allows many options).   In
that sense, this is just like the "support UTF-8 and nothing
else unless you have a clear reason and explanation" policy that
all three of us are suggesting.  "Use and conform to PRECIS and
specify what profile is being used unless you have a good reason
to do something different and, if you do have such a reason, you
MUST describe and explain it" would be a perfectly good rule.  

That said, and noting that Section 5.1 of RFC 8264 (which is a
clear statement of the "too many profiles or canonical forms are
a bad idea" principle that Asmus and I have suggested in this
discussion), I note that RFC 8265 requires NFC and RFC 8266
requires NFKC.   So, if the "don't normalize, leave that for
comparison time" is appropriate for some strings, especially
those in Asmus's second category, than a PRECIS reference would
presumably need an additional profile.

best,
   john