Subject: [Ltru] Notes before draft-4645bis-02

From: "Doug Ewell" <[email-masked]>
Date: Thu, 16 Aug 2007 22:46:07 -0700

I'm getting ready to put together draft-ietf-ltru-4645bis-02, and I have 
a few random comments for the list before I do.

I'm going to go ahead and be consistent with the model set in 
draft-4646bis-07, which has both extlang subtags and the Macrolanguage 
field, though I continue to believe only one of these features should 
ultimately be offered, to avoid needless confusion and duplication. 
Only seven primary language subtags will have a Macrolanguage field; for 
all the non-sign language extlangs -- 330 of them -- the Macrolanguage 
and Prefix fields will contain the exact same information.

One result of using extlangs is that the new ISO 639-3 code elements for 
sign languages will continue to be implemented as extlangs.  British 
Sign Language will be coded as "sgn-bfi" and not "bfi".  There are 152 
of these.

The reloaded Registry provided in draft-4645bis will continue to use hex 
NCRs instead of UTF-8, because Internet-Drafts must be all ASCII.  IANA 
will be responsible for converting the hex NCRs into UTF-8.  They have 
indicated that they can handle this, and I am willing to help with the 
process if needed.

We need to agree on what to do with almost-identical Description fields 
that will be created by adopting the exact ISO 639-3 reference names, 
which is an important point for some.  Without some other arrangement, 
we will have to add:

    Gwichʼin   to the existing   Gwich´in
    N'Ko   to the existing   N’Ko
    Macedo Romanian   to the existing   Macedo-Romanian

and keep the following pairs of descriptions which will be separated 
into their own fields:

    Geʻez   and   Ge'ez
    Hangul   and   Hangŭl   (plus Hangeul)
    Hanunoo   and   Hanunóo

(Whether your e-mail system shows or does not show the correct UTF-8 
characters above, the problem should be apparent.)

At this point, exactly 7,223 new language and extlang subtags will be 
added to the existing 490 language subtags.

As in previous drafts, the capitalization of the grandfathered tag 
"yi-latn" will be canonicalized to "yi-Latn", and the language subtags 
"anp" and "frr" will be moved out of the range of 2-letter subtags and 
into alphabetical order within the 3-letter range.  Draft-4645bis-02 
will add script subtag "Avst" to this list, which was inserted ahead of 
"Arab" and "Armn" in the existing Registry.  RFC 4646 says it is not an 
error for IANA to insert new subtags out of alphabetical order, but I 
think it would be more consistent to reload the Registry with them in 
order, and others have not objected in the past.

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://users.adelphia.net/~dewell/
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages

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

---

From: John Cowan <[email-masked]>
Date: Fri, 17 Aug 2007 18:18:39 -0400

> ultimately be offered, to avoid needless confusion and duplication. 

I've been trying to think how to formulate my perception that both
extlangs and the Macrolanguage: header have their place for some weeks
now, but am not entirely satisfied with any of it.  However, I'm going
to go ahead rather than continue in silence.

I think that extlang subtags and the Macrolanguage: header serve separate
purposes.  Extlang subtags are normative, and provide a shim between the
639-2 world we are in and the 639-3 world we are going to.  I would be
quite happy if, after the initial load, no more extlang subtags were
created *ever*.  It just allows people to tag their Algerian Arabic
content unambiguously without breaking the link to the existing tag "ar".

The Macrolanguage: header, however, is informative, not normative, and
it's subject to change as SIL adds and removes languages.  If a language
is split, the old tag may become a macrolanguage rather than being retired
by SIL (though this has not happened so far); if two languages are merged,
a new macrolanguage level may be created above them.  A language may be
moved into or out of an existing macrolanguage cluster.  All of this
change we can adapt to in order to provide additional assistance to
"RFC 4647 plus" matchers.  Authoritatively recording the relationship
between no, nb, and nn can't be anything but useful to those who care,
and at worst an excrescence (but a small one) to those who don't.

Comments?

> which is an important point for some.  

Let's blow off the 639-2 names; they are much less well checked and
maintained, and the field is only informative anyhow.

> As in previous drafts,  [...]

+1 to all.

-- 
We do, doodley do, doodley do, doodley do,        John Cowan <[email-masked]>
What we must, muddily must, muddily must, muddily must; 
Muddily do, muddily do, muddily do, muddily do,    http://www.ccil.org/~cowan
Until we bust, bodily bust, bodily bust, bodily bust.  --Bokonon