Subject: [Ltru] Re: ISO 3166-1 DIS ballot

From: Frank Ellermann <[email-masked]>
Date: Sun, 01 May 2005 08:29:13 +0200

Doug Ewell wrote:
 
> The draft contains SPECIFIC, EXPLICIT steps for what to do
> if and when ISO 3166/MA ever reuses a code element.  This
> is one of the basic rationales for the whole LTRU project.

Specific and explicit steps drifting away from the ISO 3166-1
alpha-2 codes faster than necessary, because it insists on a
"canonical forever" fiction in addition to stability.

For something like RH => ZW or YU => CS after date-B these
steps would keep the old RH and YU as canonical, instead of
propoagating the new codes ZW and CS.  No difference for the
stability, all four codes are allowed and "stable forever"
from the POV of the registry.

But fifty years later RH and YU might be reused for other
and new regions.  In that case the explicit and specific
steps will add the UN numbers for these regios if available.

Let's assume that this works (without a petition from the
tag reviewer to the UN - what an idea) and the new RH and YU
are registered by their UN number.  Of course users will get
it wrong.  Almost all regions use their ISO 3166-1 alpha-2
codes in tags, it's hard to understand why that should be
wrong for codes that haven't be used for more than 50 years.

And then these errors will not only clash with deprecated
stable codes, but with canonical stable codes.  A complete
50 years transition period wasted for nothing insisting on
a "canonical forever" fiction.

> To state that the draft will "work without problems" only
> until ISO 3166/MA reuses a code element, and that at that
> point the registry will be "forced to take an emergency
> exit," demonstrates complete misunderstanding of the
> mechanism described in the draft.

Quite the contrary, the draft demonstrates a complete lack
of understanding of what was wrong with RfC 3066.  The draft
indirectly says "tags ougt to be stable, and if ISO 3166-1
isn't then ISO 3166-1 is wrong".  But the opposite is true,
ISO 3166-1 was never stable, will never be stable, is not
meant to be stable, and attempts to abuse it as source for
stable codes are doomed.  See CS, GE, SK, etc.  Bye, Frank

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru