Mark Davis wrote:
> I disagree strongly on this one. It is very important for
> people to be able to depend on stability in IDs, and the
> whole purpose of a canonical ID would be subverted if we
> allowed it to be unstable.
You identify "stable" and "canonical". As soon as you've
done this it's clear that we come to different conclusions,
because my premise is "stable" != "canonical".
We both see "canonical" as an equivalence class, where the
canonical value represents the class. You want always the
same "oldest" representantive, I want something like the
"newest" representantive.
> once an ID is transformed into a canonical form, you can
> store it and always be assured that a comparison of the
> same ID put in canonical form by any other conformant
> implementation, at any other time, will match.
Makes sense. It's a conflict of interests, because these
classes change over time. New items are added, others are
"removed" (not in the registry, but in the source standards).
> "mostly-canonical", and that is of limited use.
The "newest" approach is useful as soon as ISO 3166-1 reuses
an "oldest" alpha-2 tag for a completely different region.
Otherwise it has no real advantage, maybe it simplifies the
job of the tag reviewer, "just do what the sources say if
there's no conflict" is a pretty simple rule. And we are
almost sure that there never will be any conflict, except
from these funny region codes.
But in theory Addison's NH -> VU example would be exactly
the same for future cases of iw -> he, ji -> yi, jw -> jv,
With your choice you'd get "canonical" subtags iw, ji, jw.
And IMHO you couldn't declare he, yi, jv as "deprecated",
that would be too obviously backwards.
You also can't declare iw, ji, jw as "deprecated" if they
are at the same time "canonical". The whole concept of a
"deprecated" tag does not work as I'd expect it for your
"canonical" iw, ji. jw.
Of course it's nice to have always the same representantive,
e.g. the smallest number in sets of numbers. Less so if
new arbitrary negative values could be added to these sets.
Bye, Frank
_______________________________________________
Ltru mailing list
Ltru at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.