Subject: [Ltru] Click letters (was: Re: Is 639-3 bogus ?)

From: "Doug Ewell" <[email-masked]>
Date: Wed, 11 Oct 2006 06:22:10 -0700

Addison Phillips <addison at yahoo dash inc dot com> wrote:

> Frank Ellermann wrote:
>>> /, //, and ! are letters representing various clicks in languages of 
>>> South Africa and Namibia.
>>
>> Is that ! related to u+01C3 ?  Then the others might be 
>> u+01C0..u+10C2.
>
> Exactly so. The Unicode characters represent the specific "click" 
> characters from those languages and are distinct from the ASCII 
> punctuation commonly used to transcribe those languages in the Latin 
> script.

I suppose it's not too early to point out that I would be opposed to any 
nascent plans to "improve" on the characters used in ISO 639-3, by 
changing the ASCII slashes and bangs to "real" Unicode click letters. 
We just went through that with apostrophes and the battle was bloody. 
Applications are welcome to change these to the "correct" characters for 
display.

--
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: Wed, 11 Oct 2006 09:35:04 -0400

> changing the ASCII slashes and bangs to "real" Unicode click letters. 

+1

> Applications are welcome to change these to the "correct" characters for 

Not much point: they'd display the same way in any reasonable font.

The point of these letter clones of punctuation marks is so that
one can use natural-language identifiers (in programming languages,
XML documents, etc.) without straying into the domain of punctuation
marks, which are usually forbidden in identifiers.

-- 
John Cowan    [email-masked]    http://ccil.org/~cowan
The whole of Gaul is quartered into three halves.
        -- Julius Caesar

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 11 Oct 2006 06:56:39 -0700

Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:

> From my POV John already answered that, "orq" doesn't make much sense 
> in an *_Internet_* registry of language subtags.

In a Registry that already has Boontling and Klingon and Yinglish?

> We'll see if it's removed from the final version, and can pull the 
> emergency break before an IETF Last Call.  If all fails we could limit 
> the bulk update to type "L", and allow individual registrations of 
> subtags with other types under the review of the language subtag list, 
> or a similar rule.

Bad idea.  Big -1.  There is a demonstrated need to tag things like 
Middle English and Ancient Egyptian, not to mention Esperanto (which 
would cause another problem, as existing constructed languages would be 
grandfathered in, but new ones in 639-3 would be excluded).

>> By the time 639-3 is published, some of the spellings may be revised
>
> Maybe use Unicode for the descriptions, the reasons why we didn't 
> limit the registry to Latn (or even Latin-1) should also be okay for 
> the source standards.

At least one Description needs to match the source standard, no matter 
how bad we think the spellings might be.

>> there's no particular reason for members of this WG to be second 
>> guessing whether the content of ISO 639-3 is good enough for use in 
>> the LSR.
>
> IBTD.  If it appears to list "anything" it would hurt the deployment 
> of 4646bis.  If we ask folks to download 640 KB the content has to be 
> as good as possible.

Excluding about 500 to 600 non-"L" languages would reduce the size of 
the Registry by less than 8 percent, exclude some ISO-coded languages 
that people may need, and open us up to charges of arbitrariness.

> We're operating under a "get it right at the first attempt" doctrine, 
> we can't change our minds later and remove "orq".

I still don't know why we would want to do that.  The Language Subtag 
Reviewer and ietf-languages list can decide that a language requested 
for independent registration isn't "good enough," but if it's in an ISO 
standard, who are they (or we) to say?

> Or preserved as a comment:
>
> Subtag: xzh
> Description: Zhang-Zhung
> Comment: Ancient

I kind of see the writing on the wall here.

> If later one of the Ms gets type E adding (M,E) to a description (or 
> saying Macrolanguage, Extinct in a comment) is no problem.

If a currently non-extinct language that is widespread enough to serve 
as a macrolanguage goes extinct during our lifetime, it would amaze me.

> Changing the 4646 syntax adding a completely new field however is 
> IMNSHO a very bad idea.  We more or less promised that that won't 
> happen.

Where did we promise that no new fields would ever be added?  This would 
also affect Addison's proposal to replace Suppress-Script with something 
new.

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 11 Oct 2006 06:58:36 -0700

Peter Constable <petercon at microsoft dot com> wrote:

> May I suggest that if one is willing to read the FDIS text, it would 
> be reasonably clear that it doesn't aim to list "anything".

Please provide a link to the FDIS text.  I can't find it.

---

From: John Cowan <[email-masked]>
Date: Wed, 11 Oct 2006 10:31:45 -0400

> standard, who are they (or we) to say?

Yesterday, following Peter's suggestion, I petitioned the 639-3/RA and
the Linguist List maintainers (who are the sub-registrars for ancient and
constructed languages) to remove Ceqli = Tceqli (same language), Delason,
Linga, Jakelimota, and Orcish from the list as insufficiently documented
or used or both; also Glosa (because it is a dialect of Interglossa).
Anthony Aristar of Linguist List wrote back expressing substantial
agreement (and using the phrase "slipped through the cracks"), so I
think we can expect them to go away.

The remaining languages (Afrihili, Brithenig, Dutton World Speedwords,
Esperanto, Ido, Interglossa, Interlingue, Interlingua de IALA, Lojban,
Laadan, Novial, Occidental, Quenya, Romanova, Sindarin, Klingon, Volapuk)
all easily meet the relevant standards for literature and documentation:
they have, or have had, communities of use.

I think therefore that we should drop the subject.

> I kind of see the writing on the wall here.

So do I.  If a comment is that structured, make it a field.

+1

+1

-- 
"Well, I'm back."  --Sam        John Cowan <[email-masked]>

---

From: John Cowan <[email-masked]>
Date: Wed, 11 Oct 2006 10:33:04 -0400

John Cowan scripsit:

> I think we can expect them to go away.

Go away, I hasten to add, *before* the publication of IS 639-3, and
therefore before 4645bis.

-- 
John Cowan  [email-masked]  http://ccil.org/~cowan
Female celebrity stalker, on a hot morning in Cairo:
"Imagine, Colonel Lawrence, ninety-two already!"
El Auruns's reply:  "Many happy returns of the day!"

---

From: Peter Constable <[email-masked]>
Date: Wed, 11 Oct 2006 09:18:10 -0700

People can contact their national standards body to request the FDIS text. You can find the DIS here:

http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=PCUnicodeDocs&highlight=639#367db883-a50e5f80

Peter

> -----Original Message-----
> From: Doug Ewell [mailto:[email-masked]]
> Sent: Wednesday, October 11, 2006 6:59 AM
> To: LTRU Working Group
> Subject: [Ltru] Re: Is 639-3 bogus ?
>

---

From: "Kent Karlsson" <[email-masked]>
Date: Wed, 11 Oct 2006 20:51:54 +0200

> > changing the ASCII slashes and bangs to "real" Unicode 

The spelling should of course be fixed in the source standard, in this
case preferably before 639-3 is published so that we don't get these
ASCII fallbacks in the language subtag registry (not even initially).

I have been intending to write to the relevant JAC about this (see below).

> Not much point: they'd display the same way in any reasonable font.

No, they do not look like the ASCII fallbacks used at all, except for 
EXCLAMATION MARK vs. LATIN LETTER RETROFLEX CLICK.

> marks, which are usually forbidden in identifiers.

No, it most certainly is NOT the point of those characters. While they (for
many programming languages) are *allowed* in identifiers, I hardly expect
them to be used in that way. The point of them, instead, is to use them
in ordinary text, mostly in the languages that use click sounds. Some
of the language names are, really, in those languages, and should
therefore be spelled using the click letters.

=====================================

Below you fined my draft comment (intended for the JAC) on this issue
that I have. (Note that this e-mail was set to be sent in UTF-8. Hopefully
it is still in UTF-8 when you receive it.)

Another comment I have is that country names should not be used for
disambiguation of same-named but different languages. Country names
are not quite as stable as one would want for the langauge names. Rather
one should use language group names (at a suitable level). Nor is it always
clear from the country names if one refers to closely related languages, or
to languages that are not at all related (though one can sometimes guess).

-----------------------------------------------

The following language code descriptions (language names) should be
spelled with the proper letters, not using ASCII fallbacks. The fallback
to proper letter mapping appears to be as follows:

        /  -> ǀ    01C0;LATIN LETTER DENTAL CLICK;Lo;0;L;;;;;N;LATIN LETTER PIPE;;;;
        // -> ǁ    01C1;LATIN LETTER LATERAL CLICK;Lo;0;L;;;;;N;LATIN LETTER DOUBLE PIPE;;;;
        =/ -> ǂ    01C2;LATIN LETTER ALVEOLAR CLICK;Lo;0;L;;;;;N;LATIN LETTER PIPE DOUBLE BAR;;;;
        !  -> ǃ    01C3;LATIN LETTER RETROFLEX CLICK;Lo;0;L;;;;;N;LATIN LETTER EXCLAMATION MARK;;;;
        '  -> ʼ    02BC;MODIFIER LETTER APOSTROPHE;Lm;0;L;;;;;N;;;;;

In the cases where the ' stands for glottal stop use MODIFIER LETTER APOSTROPHE.
Elision and genitive apostrophes are properly spelled with ’ 2019;RIGHT SINGLE
QUOTATION MARK as in the last nine entries listed below. I'm not sure if some
of the other apostrophes really are elision apostrophes too.

oun                        I        L        !O!ung
nmn                        I        L        !Xóõ
hnh                        I        L        //Ani
gnk                        I        L        //Gana
xeg                        I        E        //Xegwi
gwj                        I        L        /Gwi
xam                        I        E        /Xam
huc                        I        L        =/Hua
aue                        I        L        =/Kx'au//'ein
hgm                        I        L        Hai//om
ktz                        I        L        Ju/'hoan
ngh                        I        L        N/u
                                        
acq                        I        L        Arabic, Ta'izzi-Adeni Spoken
alu                        I        L        'Are'are
mtv                        I        L        Asaro'o
aot                        I        L        A'tong
kud                        I        L        'Auhelawa
bei                        I        L        Bekati'
byd                        I        L        Benyadu'
crt                        I        L        Chorote, Iyojwa'ja
crq                        I        L        Chorote, Iyo'wujwa
dri                        I        L        C'lela
ing                        I        L        Degexit'an
dor                        I        L        Dori'o
dup                        I        L        Duano'
fab                        I        L        Fa D'ambu
fmp                        I        L        Fe'fe'
gqa                        I        L        Ga'anda
gdg                        I        L        Ga'dang
gaq                        I        L        Gata'
bbj                        I        L        Ghomálá'
gmb                        I        L        Gula'alaa
hwc                        I        L        Hawai'i Creole English
hps                        I        L        Hawai'i Pidgin Sign Language
haw        haw                I        L        Hawaiian             [should this not use a letter apostrophe?]
dbj                        I        L        Ida'an
ilu                        I        L        Ili'uun
xkk                        I        L        Kaco'
kzf                        I        L        Kaili, Da'a
blk                        I        L        Karen, Pa'o
ksw                        I        L        Karen, S'gaw
xxk                        I        L        Ke'o
kuk                        I        L        Kepo'
xkc                        I        L        Kho'ini
krr                        I        L        Kru'ng 2        [what is the 2 here? 2? LATIN CAPITAL/SMALL TONE TWO? LATIN LETTER TWO WITH STROKE? ...]
xmp                        I        L        Kuku-Mu'inh
kuy                        I        L        Kuuku-Ya'u
bko                        I        L        Kwa'
wka                        I        E        Kw'adza
kwf                        I        L        Kwara'ae
lbi                        I        L        La'bi
lns                        I        L        Lamnso'
lra                        I        L        Lara'
ljl                        I        L        Li'o
prb                        I        L        Lua'
mhy                        I        L        Ma'anyan
mhi                        I        L        Ma'di
snm                        I        L        Ma'di, Southern
lva                        I        L        Maku'a
slz                        I        L        Ma'ya
yus                        I        L        Maya, Chan Santa Cruz           [should this not use a letter apostrophe?]
yua                        I        L        Maya, Yucatán           [should this not use a letter apostrophe?]
xmy                        I        L        Mayaguduna
emy                        I        E        Mayan, Epigraphic           [should this not use a letter apostrophe?]
mtk                        I        L        Mbe'
muc                        I        L        Mbu'
mym                        I        L        Me'en
mgo                        I        L        Meta'
gbn                        I        L        Mo'da
nae                        I        L        Naka'ela
nnz                        I        L        Nda'nda'
nxg                        I        L        Ngad'a
nea                        I        L        Ngad'a, Eastern
nbm                        I        L        Ngbaka Ma'bo
ncg                        I        L        Nisga'a
num                        I        L        Niuafo'ou
nyp                        I        E        Nyang'i
tyh                        I        L        O'du
lul                        I        L        Olu'bo
oyy                        I        L        Oya'oya
pqa                        I        L        Pa'a
ple                        I        L        Palu'e
phq                        I        L        Phana'
qxq                        I        L        Qashqa'i
apb                        I        L        Sa'a
snv                        I        L        Sa'ban
scq                        I        L        Sa'och
xst                        I        L        Silt'e
ssq                        I        L        So'a
rob                        I        L        Tae'
tln                        I        L        Talondo'
tto                        I        L        Ta'oih, Lower
tth                        I        L        Ta'oih, Upper
tct                        I        L        T'en
tve                        I        L        Te'un
mlu                        I        L        To'abaita
tlz                        I        L        Toala'
ood                        I        L        Tohono O'odham
sda                        I        L        Toraja-Sa'dan
tsl                        I        L        Ts'ün-Lao
ulm                        I        L        Ulumanda'
urk                        I        L        Urak Lawoi'
wag                        I        L        Wa'ema
wmh                        I        L        Waima'a
wih                        I        L        Wik-Me'anha
ame                        I        L        Yanesha'
pto                        I        L        Zo'é
                                        
eot                        I        L        Beti (Côte d'Ivoire)     [elision apostrophe]
crd                        I        L        Coeur d'Alene     [elision apostrophe]
fla                        I        L        Kalispel-Pend d'Oreille     [elision apostrophe]
kfo                        I        L        Koro (Côte d'Ivoire)     [elision apostrophe]
loi                        I        L        Loma (Côte d'Ivoire)     [elision apostrophe]
mre                        I        E        Martha's Vineyard Sign Language     [elision apostrophe]
ngm                        I        L        Ngatik Men's Creole     [elision apostrophe]
plw                        I        L        Palawano, Brooke's Point     [elision apostrophe]
neb                        I        L        Toura (Côte d'Ivoire)     [elision apostrophe]

======================================================

---

From: Peter Constable <[email-masked]>
Date: Wed, 11 Oct 2006 12:18:20 -0700

If anyone would like to review the entries in the draft code table for 639-3 and suggest character changes to get beyond ASCII / Latin-1 limitations, please feel free; I'm sure the RA would welcome the feedback. But don't necessarily expect guarantees that all or any such changes would necessarily be made prior to publication: that is potentially a large amount of feedback to vet and take action on. 

Note that a prior issue for the RA and the JAC to consider is what character set should be allowed in language names used in the 639 standards. If you would like to submit feedback in that regard, it should probably go to the JAC via Michael Everson -- IIRC he is IETF liaison to the JAC.

Peter

-----Original Message-----
From: Kent Karlsson [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 11:52 AM
To: 'John Cowan'; 'Doug Ewell'
Cc: 'LTRU Working Group'
Subject: RE: [Ltru] Click letters

oun                        I        L        !O!ung
nmn                        I        L        !Xóõ
hnh                        I        L        //Ani
gnk                        I        L        //Gana
xeg                        I        E        //Xegwi
gwj                        I        L        /Gwi
xam                        I        E        /Xam
huc                        I        L        =/Hua
aue                        I        L        =/Kx'au//'ein
hgm                        I        L        Hai//om
ktz                        I        L        Ju/'hoan
ngh                        I        L        N/u

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 11 Oct 2006 23:25:24 +0200

Doug Ewell wrote:
 
> There is a demonstrated need to tag things like Middle English and
> Ancient Egyptian, not to mention Esperanto (which would cause another
> problem, as existing constructed languages would be grandfathered in,
> but new ones in 639-3 would be excluded).

Esperanto and Orcish don't play in the same league, that's a good "C",
it couldn't cause a problem _because_ it already made it into 639-2.

Other good "C" not in 639-2 would be a problem, as far as registering
them individually as needed is a problem (in theory it should be easy).

The attempted "grabar" registration was a model, somebody (IIRC Peter)
said it should get its own code, and later sommebody else (IIRC John)
found that it already has a code "axm".  So far the plan was that this
and all other new A, C, E, and H are automatically included in the bulk
4645bis update.

This registration business (like RFC publication) boils down to "filter
nonsense and try to reflect some useful reality".  Some humans do this,
and if it's an open process with experts and appeals etc. we hope that
the outcome is good enough.

If it's a rather cryptic process with very few experts who simply can't
know each and every "orq"-case this outcome might be not good enough, 
and adding a second filter with an open process behind it could help.

Increased bureaucracy is often not helpful, but we have already a way
to register languages in addition to 639-3 with tons of SHOULD NOT to
discourage it.  We could as well add a way to register a proper subset
of 639-3 (A, C, E, H) only on demand.  Maybe it's a bad idea, but it's
not completely impossible.

> how bad we think the spellings might be.

Yes, you can't simply "fix" the clicks, let 639-3 do it when they feel
like it.  It's rare that I say "please use Unicode", it was addressed 
to Peter, not to you... :-)

> the Registry by less than 8 percent

Yes, it's no size issue.  Using all available alpha3 is also okay, the
complete registry would be still below 2 MB.  It's a question of the
vetting, and whether users would need to know the source of an alpha3
in the registry, or only "interesting" types, or if that's irrelevant.

Apparently some including John, Peter, and me feel that it's relevant,
but we still have to figure out how to do it.

> The Language Subtag Reviewer and ietf-languages list can decide that
> a language requested for independent registration isn't "good enough,"
> but if it's in an ISO standard, who are they (or we) to say?

ISO standard, IANA registry, CLDR, ICU, tz database, or RFC, there are
some folks empowered to decide what's in and what's out, and depending
on how good that's organized the results can be good, bad, or ugly.

There always will be errors, and _we_ invented the rules not allowing
to fix errors in the registry.  As soon as "orq" is in it stays in.
And if 639-3 isn't designed for this radical approach it's our job to
get it right.  We did that already for the 3166 country codes.  For all
other 4646 sources we trust that it's unnecessary.  ISO 639-3 will be a
new player, and Peter always convinced me that it will be as good as
the other sources.  

But we have to verify this, and doing it with the April draft is a good
test.  Peter said that they might remove "orq", and that's the purpose
of this test, find nits and issues before they are "stable forever".

> as a macrolanguage goes extinct during our lifetime, it would amaze me.

Me too, it was an explanation why mixing the "scope" and "type" info is
possible even under unlikely conditions.

> Where did we promise that no new fields would ever be added?

By proposing <extlang> with detailed rules before it existed, the 4646
syntax is supposed to work also for 4646bis registries.

> This would also affect Addison's proposal to replace Suppress-Script
> with something new.

Yes, that's why I don't like the zero-one-more-script proposal.  And
why I don't like an additional Langtype field.  And why I don't like 
to use UTF-8, or to replace record-jar by XML.  Always the same reason,
stick to the 4646 registry format, it's okay.

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 11 Oct 2006 23:40:29 +0200

> Go away, I hasten to add, *before* the publication of IS 639-3,
> and therefore before 4645bis.

Thanks, I appreciate it.

Frank

[[ The last time I had anything to do with DIN was in the early
   80's about obscure German sort order rules, and it wasn't me
   who paid for their paper.  "Ask your national standards body"
   is no procedure I'm used to, it sounds like a recipe by you-
   know-who.  If it's about contry codes I'd ask Debbie, not DIN.
]]

---

From: Martin Duerst <[email-masked]>
Date: Thu, 12 Oct 2006 09:56:29 +0900

At 04:18 06/10/12, Peter Constable wrote:

>Note that a prior issue for the RA and the JAC to consider is what 
>character set should be allowed in language names used in the 639 
>standards. If you would like to submit feedback in that regard, it should 
>probably go to the JAC via Michael Everson -- IIRC he is IETF liaison to the JAC.

There is no such record on the relevant page
(http://www.ietf.org/liaisonActivities.html).

Regards,    Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: John Cowan <[email-masked]>
Date: Wed, 11 Oct 2006 22:10:30 -0400

Martin Duerst scripsit:

> >standards. If you would like to submit feedback in that regard, it
> >should probably go to the JAC via Michael Everson -- IIRC he is IETF
> >liaison to the JAC.
> 

That is to say, he is the person who represents IETF concerns on the JAC,
not vice versa.  By the same token, I am the person who represents IETF
concerns to the Lojban community.  No one has to make these roles
official.

-- 
John Cowan                              <[email-masked]>
            http://www.ccil.org/~cowan
                .e'osai ko sarji la lojban.
                Please support Lojban!          http://www.lojban.org

---

From: Ted Hardie <[email-masked]>
Date: Wed, 11 Oct 2006 19:45:47 -0700

>concerns to the Lojban community.  No one has to make these roles

They do need to be made official if you represent the IETF; you may
represent  your experience (including your experience of the IETF) in
any way you like.     It sounds like you meant the second.  "Liaison", though,
has a fairly specific meaning in our discussions of relationships to other bodies,
and it does tend to imply "represent the IETF" and that  implies
"appointed by the IAB".
		regards,
				Ted Hardie

---

From: John Cowan <[email-masked]>
Date: Wed, 11 Oct 2006 22:49:47 -0400

Ted Hardie scripsit:

> They do need to be made official if you represent the IETF; you
> may represent  your experience (including your experience of the
> IETF) in any way you like.     It sounds like you meant the second.
> "Liaison", though, has a fairly specific meaning in our discussions
> of relationships to other bodies, and it does tend to imply "represent
> the IETF" and that  implies "appointed by the IAB".

Fair enough.

-- 
Not to perambulate                 John Cowan <[email-masked]>
    the corridors                  http://www.ccil.org/~cowan
during the hours of repose
    in the boots of ascension.       --Sign in Austrian ski-resort hotel

---

From: John Cowan <[email-masked]>
Date: Wed, 11 Oct 2006 22:59:03 -0400

> and adding a second filter with an open process behind it could help.

The whole point of publishing a draft list was for expert correction,
which it got.  Both Anthony Aristar and I independently determined
that the conlangs I mentioned did not belong in the standard, and
Anthony said their presence in the draft was an oversight.

> but we still have to figure out how to do it.

I'm not sure what this means.  We do know how to do scopes and types;
the issue is whether we want to.

> to fix errors in the registry.  As soon as "orq" is in it stays in.

It's not in yet and it won't be.

> syntax is supposed to work also for 4646bis registries.

We stabilized the syntax of language tags.  We stabilized the record-jar
syntax.  We stabilized certain fields (and not others).  We did not
stabilize the set of fields as a whole.

-- 
John Cowan  <[email-masked]>  http://www.ccil.org/~cowan
        Raffiniert ist der Herrgott, aber boshaft ist er nicht.
                --Albert Einstein

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 12 Oct 2006 05:29:37 +0200

John Cowan wrote:

> By the same token, I am the person who represents IETF concerns to
> the Lojban community.  No one has to make these roles official.

If you _would_ claim to speak on behalf of the IETF there are two
relevant RFCs:  4052 and 4053.  From an IETF POV it is an official
role (at least the incoming liaison statements like Mark's letter on
hehalf of Unicode), there's a tracker, and you can get an account to
manage your liaison statements, etc.  The most important point is
apparently that incoming statements are answered or forwarded to an
appropriate WG (Chair) / area (AD) / IESG / IAB.

http://tools.ietf.org/html/draft-iab-liaison-guidelines is about the
opposite direction (IETF to xyz).  Martin or Randy could appoint you
as "official" IETF LTRU liaison to the Lojban community (if the AD
tolerates it), in theory.  An "official" LTRU liaison to the 639 RA
or JAC (replace proper title) could be an idea:  That liaison (e.g.
Peter) could request an extended guarantee covering 639-3 on behalf
of LTRU, and the liaison from 639 (e.g. you) would answer it, and
then Addison could copy an updated stability guarantee into 4646bis.

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 12 Oct 2006 06:02:27 +0200

> the issue is whether we want to.

It means that this could be noted in a new field, or as " (M)" or " (H)"
etc. at the end of the description, or verbose as " (historic)", or even
in a comment - but normally we reserve comments for any info that's not
a part of the source.

> We stabilized the syntax of language tags.

Yes.

> We stabilized the record-jar syntax.

One hopes.

>  We stabilized certain fields (and not others).

Yes.

> We did not stabilize the set of fields as a whole.

We also didn't mention that new fields might be introduced later.

For the purpose mentioned by Peter - determine if "foo" is the subtag
for language "bar", where "ancient" helps to decide that it's not -
the "ancient" info is relevant, not how it appears in a "bar" record.

For the purpose mentioned by Addison - determine if subtag "foo" is
a macrolanguage - it's the info "macrolanguage", not how it appears.
Checking if subtag "foo" is the target of an extlang-prefix is not
exactly straight forward (but an algorithmic solution).

And for the purpose mentioned by me - check if "foo" is a pure 639-3
subtag - we have no proposal based alone on the LSR.

Frank

---

From: John Cowan <[email-masked]>
Date: Thu, 12 Oct 2006 00:25:32 -0400

> We also didn't mention that new fields might be introduced later.

It's not reasonable to assume that things are immutable if not mentioned
otherwise -- or nothing could ever be changed unless it was decided
back in 1969 that it would be mutable later.

IOW, stability policies have to be explicit.

> subtag - we have no proposal based alone on the LSR.

What is a pure subtag?

-- 
Using RELAX NG compact syntax to        John Cowan <[email-masked]>
develop schemas is one of the simple    http://www.ccil.org/~cowan
pleasures in life....
        --Jeni Tennison                 <[email-masked]>

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 12 Oct 2006 06:40:56 +0200

John Cowan wrote:

> otherwise

The extlangs are mentioned in RFC 4646 but not used, that indicates that
the record types were meant to cover 4646bis later, and from there it's
no unreasonable jump to think that the complete structure was meant to
cover 4646bis.

>> check if "foo" is a pure 639-3 subtag
[...]
> What is a pure subtag?

A pure 639-3 subtag is something where the columns "Part1" and "Part2"
in iso-dis-639-3_20060421.tab are empty (or should be empty after the
next synchronization).

Frank

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 11 Oct 2006 23:16:15 -0700

> http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=PCUnicodeDocs&highlight=639#367db883-a50e5f80

I know that the national body is the normal place for individuals to go 
for Final Draft standards.

In our particular, unique case, we are:

1) trying to update an Internet standard (lowercase "s"), almost 
entirely for the purpose of adding support for ISO 639-3, which will 
certainly be the first, and probably the highest-profile, application to 
use ISO 639-3;

2) joined in this effort by the Project Editor for ISO 639-3; and

3) being reminded (or cajoled) multiple times by the Project Editor to 
check a copy of the FDIS for updated information.

Given all this, instead of each of us trying to figure out whom 
specifically at ANSI (or wherever) we need to contact for a personal 
copy, it seems more logical to me that the Project Editor might offer 
this group a direct link to the FDIS text.

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 11 Oct 2006 23:39:55 -0700

> ASCII fallbacks in the language subtag registry (not even initially).

If you can get the JAC to do this before release, then of course the 
"fixed" spellings will appear in the Registry.  This is really the only 
way the "use the right characters" crowd and the "follow the standard 
exactly" crowd are going to see eye to eye -- by getting the standard to 
use the "right" characters.

> EXCLAMATION MARK vs. LATIN LETTER RETROFLEX CLICK.

That's true for the click letters.  When we fought the Apostrophe Wars, 
the ironic part was that that the "correct" characters looked 
essentially the same as the ASCII fallbacks, but *only if* they were 
available in the font.  This was generally true for U+2019, but not at 
all true for U+02BB; many fonts show a box there.

> are not quite as stable as one would want for the langauge names. 
> Rather one should use language group names (at a suitable level). Nor 
> is it always clear from the country names if one refers to closely 
> related languages, or to languages that are not at all related (though 
> one can sometimes guess).

I'll let Peter address the questions of whether this would even be 
feasible, and whether it would improve anything.

> spelled with the proper letters, not using ASCII fallbacks. The 
> fallback to proper letter mapping appears to be as follows:
>
>         !  -> ǃ    01C3;LATIN LETTER RETROFLEX 
> CLICK;Lo;0;L;;;;;N;LATIN LETTER EXCLAMATION MARK;;;;

My guess is that you are going to have a tough time getting the JAC to 
adopt characters in language names that (a) are in few to no 8-bit 
legacy character sets and (b) have experienced such poor uptake in 
modern fonts.