Subject: [Ltru] rfc4646bis-18 propageted subtag churn

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 2 Nov 2008 03:47:03 -0700

Hi -

As a technical contributor...

We seem to lose sight of the spirit of section 3.4 13 
   13.  Codes assigned by ISO 15924 and ISO 3166-1 that do not conflict
        with existing subtags of the associated type and whose meaning
        is not the same as an existing subtag of the same type are
        entered into the IANA registry as new records.

in the example in section 3.1.7:
   2.  Subtags (with types other than language or extlang) taken from
       codes or values that have been withdrawn in favor of a new code.
       In particular, this applies to region subtags taken from ISO
       3166-1, because sometimes a country will change its name or
       administration in such a way that warrants a new region code.  In
       some cases, countries have reverted to an older name, which might
       already be encoded.  For example, the subtag 'ZR' (Zaire) was
       replaced by the subtag 'CD' (Democratic Republic of the Congo)
       when that country's name was changed.

and Section 3.4 14:
   14.  Codes assigned by ISO 639, ISO 15924, or ISO 3166-1 that are
        withdrawn by their respective maintenance or registration
        authority remain valid in language tags.  A 'Deprecated' field
        containing the date of withdrawal MUST be added to the record.
        If a new record of the same type is added that represents a
        replacement value, then a 'Preferred-Value' field MAY also be
        added.  The registration process MAY be used to add comments
        about the withdrawal of the code by the respective standard.

           For example: the region code 'TL' was assigned to the country
           'Timor-Leste', replacing the code 'TP' (which was assigned to
           'East Timor' when it was under administration by Portugal).
           The subtag 'TP' remains valid in language tags, but its
           record contains the a 'Preferred-Value' of 'TL' and its field
           'Deprecated' contains the date the new code was assigned
           ('2004-07-06').

It is much better for the stability of language tags to *NOT* propagate
such churn.  Our philosophy at the outset was to use various specs as sources
of codes, not to somehow mirror them as they evolved in ways potentially
incompatible with useful language tagging practices.  The current
language permits the LSR to not propagate the changes, but one needs
to squint really hard to see it - the text we have now makes it easier
to do the wrong thing than the right.

When ISO produces a new code that means exactly the same thing as
something already in the registry, it seems to me that the correct
thing to do is to create an entry for the *new* code with a status
of "deprecated" and a preferred-value pointing to the *old* code.
I wouldn't suggest going back and trying to fix the ones that are
already messed up, but do think some guidance for the future would
be helpful.

(BTW, there is an editorial "the a" to be fixed in 3.4.14)

Randy

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

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 2 Nov 2008 09:17:20 -0700

Randy Presuhn <randy underscore presuhn at mindspring dot com> wrote:

> It is much better for the stability of language tags to *NOT* 
> propagate such churn.  Our philosophy at the outset was to use various 
> specs as sources of codes, not to somehow mirror them as they evolved 
> in ways potentially incompatible with useful language tagging 
> practices.  The current language permits the LSR to not propagate the 
> changes, but one needs to squint really hard to see it - the text we 
> have now makes it easier to do the wrong thing than the right.

I'm surprised to see this come up now.  It seems to me we discussed it 
quite a bit during both LTRU I and LTRU II, including the famed "Date A" 
and "Date B" milestones.

One of the main reasons for starting the LTRU project 5 years ago was to 
insulate language tagging from gratuitous churn in the core standards, 
and in particular from bad ideas like redefining code elements after 5 
years.  (ISO 3166 has fixed this now, but that was not the case in 
2003.)  Then, at some point, it became very important for some people to 
be able to

(a) trace the "exact meaning" of the subtag back to the core standards, 
even though most of the core standards don't define the exact meaning 
either, and

(b) use the Language Subtag Registry as a central code list for purposes 
having nothing to do with language tagging (which is why we have "EU" 
and other unassigned ISO 3166 code elements).

Those additional requirements caused us to compromise our original 
philosophy to some extent.

> already messed up, but do think some guidance for the future would be 
> helpful.

'ZR' was deprecated in favor of 'CD' due to the Date A/Date B rules, 
which I thought were clear and well understood and did insulate language 
tagging from unnecessary churn.  What is new is the suggestion to 
re-adopt 'ZR' and deprecate 'CD' in favor of 'ZR' in case the Democratic 
Republic of the Congo goes back to being called "Zaire."  That is due to 
the compromise.  I agree with Randy's viewpoint, and did at the time it 
was discussed, but did not manage to convince the rest of the WG and 
have not elected to continue fighting this losing cause.

--
Doug Ewell  *  Thornton, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ