Re: explanation for ensuring no duplicate identifiers

W. Trevor King

On Thu, Jun 14, 2018 at 01:28:11PM -0600, J Lovejoy wrote:
• Short identifiers must not be duplicative: newly added short
identifiers will be checked to ensure they are different from all
pre-existing short identifiers, regardless of upper/lower case
Wherever we put this commitment, I think we also want something like

List consumers are enouraged to use the canonical identifier casing,
but this uniqueness commitment ensures that case-insensitive
comparison with listed identifiers will be unambiguous.

In a spec, I'd make that a SHOULD recommendation [2]. Encouraging the
use of canonical casing reduces the need for a case-canonicalizer [3],
by giving tools that choose not to implement a canonicalizer something
to point at if/when users complain about unrecognized, non-canonical
identifiers. It also makes it less likely that tools decide to change
the case without thinking about downstream compatibility (e.g. [4]).

I also prefer focusing on the list state (across versions) instead of
using "newly added" to focus on changes to the list state. For
example, my earlier wording [5]:

This project commits to never, in any past or future version,
contain identifiers which differ only in case but have different

makes it clear that the current list is already free of case-insentive
ambiguity. With the "newly added" wording, we could already have
case-insentive ambiguous IDs and just be committing to not adding



This email may be signed or encrypted with GnuPG (
For more information, see

Join to automatically receive all group messages.