Subject: [Ltru] [psg.com #954] all aliases must be equally supported

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 10 May 2005 15:01:48 -0700

Hi -

> Comment 25 in message
> http://www.ietf.org/mail-archive/web/ltru/current/msg00540.html
> says:  "25. 2.3: recommendation 3 seems inappropriate. Aliases are
> aliases. All the
> aliases must be equally supported because (a) they are aliases (b) to
> make
> sure developers develops correct code."
>
> Discussion clarified that the intent is
> "All aliases are equally supported.  Not all aliases are equally
> recommended."
> see http://www.ietf.org/mail-archive/web/ltru/current/msg00628.html

Randy, ltru co-chair

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

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 11 May 2005 06:35:19 +0200

Randy Presuhn wrote:

>> "All aliases are equally supported.  Not all aliases are
>>  equally recommended."

Unfortunately the draft does not yet follow what its sources
recommend, it freezes not only registered tags, but also the
status of their recommendation (aka "Canonical") in certain
cases.

The "canonical forever" concept is unnecessary and potentially
harmful:  If long deprecated 3166-1 tags are reused, but the
registry still propagates some obsolete values as "canonical".

"Canonical" and "Deprecated" should a far as possible reflect
what the source standards define.

                          Bye, Frank

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 10 May 2005 21:54:53 -0700

Hi -

Could you suggest some specific replacement text that would
address your concerns?

Randy

> From: "Frank Ellermann" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, May 10, 2005 9:35 PM
> Subject: [Ltru] Re: [psg.com #954] all aliases must be equally supported
>

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 11 May 2005 08:38:49 +0200

> Could you suggest some specific replacement text that would

It was point (4) of five on my ToDo list in:

<http://mid.gmane.org/[email-masked]>

For point (1) Doug and Addison apparently prefer to get an
RfC for the registry draft _before_ discussing the final
draft registry (i.e. determine more / other Suppress-Scripts).

That strategy surprised me, but it could be a good idea for
my point (5) in:

<http://mid.gmane.org/[email-masked]>

Point (2) is actually something for you, I wanted a SHOULD
with rationale for the Suppress-Script issue, you found that
what I want is in fact a "MUST NOT unless" with rationale,
and that's still missing in draft -01.

That leaves point (4) "canonical", and admittedly I was too
lazy to find all occurences of "canonical" in the text so
far.  An incomplete attempt:

Line 512, stick to canonical alpha-3 tag even if an alpha-2
is added => no problem, that only tries to avoid unnecessary
aliases.

Line 630, UN region numbers are the final canonical value
for any given region with "ambiguous" alpha-2 codes => okay.

Line 1088, never add Canonical => delete
Line 1089, never modify Canonical => delete

That's the paragraph defining the problematic "canonical
forever" concept, it should be deleted.

Line 1095: get rid of "STRONGLY" (fourth reminder, IIRC)

Line 1112:
- Although valid in language tags, subtags and tags with a 'Deprecated'
- field are deprecated and validating processors SHOULD NOT generate
- these subtags.  Note that a record that contains a 'Deprecated' field
- and no corresponding 'Canonical' field has no replacement mapping.
+
+ Although valid in language tags, subtags and tags with a 'Deprecated'
+ field SHOULD NOT be generated by validating processor.  Note hat a
+ record that contains a 'Deprecated' field and no corresponding
+ 'Canonical' field has no replacement mapping.
+
+ Future updates of the source standards may replace former canonical
+ tags by new tags.  In that case the old tag is marked as 'Deprecated'
+ with a pointer to the the new tag in the 'Canonical' field.  Pointers
+ to the old canonical value in other tags are updated.  Validating
+ processors SHOULD use the the most recent registry.

The latter SHOULD is no new restriction, it was always implied.

Line 1242:

| Values in the fields 'Type', 'Subtag', 'Tag', 'Added' and
| 'Canonical' MUST NOT be changed and are guaranteed to be
| stable over time.

s/'Added' and 'Canonical'/and 'Added'/
In theory we hope that that 'Deprecated' is guaranteed to be
stable, but in practice not mentioning this allows Murphy to
rule and SNAFU on the side of the source standards.

Line 1277 - 1297:  Modify the procedures for withdrawn / added
tags to be reflected as deprecated / canonical in the registry.

Remove IM example (it could be still correct dependig on how
we want to handle the introduction of alpha-2 codes for regions
formerly only known by their number, but it's no example for
"canonical reflects the sources").  BTW, if GG and JE would be
added this cries for a judgement call.  Insisting on 830 as a
canonical value for both GG and JE would be ridiculous.  And
not reflect Doug's undocumented "same piece of land" concept.

Etc., e.g. line 1355, there are more lies, where the "canonical
forever" concept is just wrong, forcing users to consider an
obsolete tag for their region as "canonical" will never fly.

I would never follow this idea no matter what any "least common
practice" states.  It's ZW, not RH.  If I look into the source
standard I want a decent chance to guess what the canonical tag
might be without unnecessary surprises in the 3066bis registry.

                             Bye, Frank

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 11 May 2005 09:01:58 -0700

Although I agree with Frank on many other items, 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. Stability gives implementations the assurance
that 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. If not,
then it's only "mostly-canonical", and that is of limited use.

I think part of the issue is that the *presentation* of language tags may
not want to be the canonical form. That is, the UI for presentation to users
should use whichever variant makes the most sense. But that doesn't have to
be the canonical form. In reality, that wants to use native names that make
sense to end users anyway, eg. in Russian the following (fake) tag:

aa-Arab-AD presented to the user as "Афар (Арабская, Андорра)"
etc.

If we do anything, it should be to add a note to that effect.

‎Mark

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 11 May 2005 22:44:05 +0200

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

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 11 May 2005 20:49:50 +0200

>then it's only "mostly-canonical", and that is of limited use.

Mark,
I am sorry, Frank is right. You cannot be cannonical with tables you do not 
control. This is precisely the problem the charter wants us to address. 
Stability is not in the ID but in the documented object.  You have two 
possibilities: to attach a date to the ID or to define your own canonical 
table and relate it to the ID.
jfc