Subject: [Ltru] Unresolved issues for draft-4645bis

From: "Doug Ewell" <[email-masked]>
Date: Wed, 3 Jan 2007 11:16:44 -0800

Now that the holidays are over and many people have returned from e-mail 
hiatus, I'd really like to see the following issues resolved:

1.  Decide how the new Registry, as initialized by RFC 4645bis, should 
handle inverted names:

    a.  Use only the uninverted names from ISO 639-3
    b.  Use only the inverted names from ISO 639-3
    c.  Use all names from ISO 639-3
    d.  Some other possibility

2.  Decide, based on which option above is chosen, whether any 
corresponding changes need to be made in the region subtags, some of 
which have a single Description in inverted form.

2.  Determine whether everyone is satisfied with the current wording in 
draft-4646bis-02, Section 3.1.4 about the first of multiple 
"Description" fields corresponding to the ISO 639-3 Reference Name, or 
whether there is still a desire for a discrete "Reference-Name" field.

These issues MUST all be resolved before I can prepare a new 
draft-4645bis-01.  The deadline for this draft to go to IETF Last 
Call -- not just WG Last Call -- is 29 days away, so we should resolve 
them soon.  I ask the co-chairs to help gauge the hum of the WG.

--
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: Addison Phillips <[email-masked]>
Date: Wed, 03 Jan 2007 12:27:03 -0800

>    d.  Some other possibility

I think (c) is the most reasonable solution. Why should we get into the 
business of choosing and editing the names at initial registration? The 
more we dabble with this, the more I favor following ISO 639.

> which have a single Description in inverted form.

... which choice obviates this problem.

> whether there is still a desire for a discrete "Reference-Name" field.

I think "Reference-Name" as a field is a bad idea. I'm happy to make the 
first name that appears in a Description field "turn out" to be the 
Reference Name. In which case, I think it should *exactly* match the 
reference name, (un)inversions and all.

I think that this should also be extended to all ISO based records, not 
just language/extlangs. (I think this is mostly the case anyway.)

> draft-4645bis-01.  The deadline for this draft to go to IETF Last Call 
> -- not just WG Last Call -- is 29 days away, so we should resolve them 
> soon.  I ask the co-chairs to help gauge the hum of the WG.

Why MUST all of these be resolved first? It's a draft. There are still 
many integers available after "-01". It's unfortunate that we won't have 
everything resolved, but it would give us something to look at if you 
pick one of the options and make the draft look that way.

WRT the charter deadline, note that we rely on ISO 639-3 being published 
before *any* Last Calls can take place. I note that, at least this 
morning, ISO lists 639-3:2007 as status "60.00" (which is "International 
Standard under publication", the last step before publication).

Addison

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 3 Jan 2007 12:54:25 -0800

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

> I think (c) is the most reasonable solution. Why should we get into 
> the business of choosing and editing the names at initial 
> registration? The more we dabble with this, the more I favor following 
> ISO 639.

Great, and I do not disagree (although that does require a change to the 
first paragraph of draft-4646bis-02, Section 3.1.4).  What do others 
think?

BTW, for those who are deciding, there are approximately 1,400 inverted 
forms in ISO/FDIS 639-3.  The overall size impact of adding these to the 
Registry is not great.

> I think "Reference-Name" as a field is a bad idea. I'm happy to make 
> the first name that appears in a Description field "turn out" to be 
> the Reference Name. In which case, I think it should *exactly* match 
> the reference name, (un)inversions and all.

Great, and I do not disagree.  What do others think?

> I think that this should also be extended to all ISO based records, 
> not just language/extlangs. (I think this is mostly the case anyway.)

ISO 15924 puts alternative names in parentheses, in a comma-separated 
list:

    Han (Hanzi, Kanji, Hanja)

These are currently copied verbatim into the Registry, with no 
post-processing.  If we are going to change that, we should decide now.

ISO 3166, or at least the freely available list of names on their Web 
site, provides no alternative forms.  Neither does UN M.49, although it 
should be pointed out that UNSD does not appear to treat M.49 as a 
"standard" in the formal ISO sense.

> many integers available after "-01". It's unfortunate that we won't 
> have everything resolved, but it would give us something to look at if 
> you pick one of the options and make the draft look that way.

I'll quote from my post of December 15:

"On several occasions, I've been asked to simply pick one of these 
options, write the draft, and wait for feedback.  The reason I haven't 
done this is that it's not just about writing the draft.  RFC 4645bis --  
like RFC 4645 but on a much larger scale -- requires the generations of 
hundreds of pages of data that reflect the decisions specified in the 
prose.  Because of the size of this project, I would greatly prefer to 
write a program to generate the new Registry data from the ISO 639-3 
files and the existing Registry, rather than attempting to do it by 
hand.  Changing a decision like this would require modifying the program 
and validating the results before submitting a new draft.  The cost of 
submitting a draft that is out of touch with the WG is high."

The supply of integers doesn't matter to me; repeatedly rewriting my 
program to generate the output does.

---

From: John Cowan <[email-masked]>
Date: Wed, 3 Jan 2007 17:36:56 -0500

> first paragraph of draft-4646bis-02, Section 3.1.4).  What do others 

I reluctantly agree.  The names are a mess, and we might as well capture
all that we can, as it may help somebody.

> Great, and I do not disagree.  What do others think?

In the ISO 639 world, only the entries in 639-3 have a reference name.
In particular, the language-collection codes of 639-2 are not replicated
in 639-3 and have no reference names.  I don't care how you sort the
fields, but I am very much against giving guarantees about the order of
Description fields in 4646bis.  You'd have to say "The first Description
field is the reference name provided by the standard, if it provides
one at all."  Since we do not document which subtags come from which
standards, this is of very little use.

>    Han (Hanzi, Kanji, Hanja)

We should break these up.  They are definitely alternative names.

> "standard" in the formal ISO sense.

Neither of these provide anything comparable to a reference name: the names
are simply customary, with no legal force.  (The long names, which may have
legal force in some countries, are not provided freely.)

-- 
A: "Spiro conjectures Ex-Lax."                  John Cowan
Q: "What does Pat Nixon frost her cakes with?"  [email-masked]
  --"Jeopardy" for generative semanticists      http://www.ccil.org/~cowan

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 3 Jan 2007 14:52:01 -0800

> standards, this is of very little use.

You've made it quite clear that it is of little use to you. It is of great
use to us, and little cost to you.

> We should break these up.  They are definitely alternative names.

yes

> legal force in some countries, are not provided freely.)

We have collected alternative names that are used by the World Bank and
others. It might be worth adding, but that topic is orthogonal to the one at
hand.

--

-- 
Mark

---

From: John Cowan <[email-masked]>
Date: Wed, 3 Jan 2007 18:19:34 -0500

Mark Davis scripsit:

> >You'd have to say "The first Description

Not what I meant.

What can you do with the standards language above?  It's equivalent 
to "The first name MAY be the reference name; second and later names
MUST NOT be the reference name."  What good is that?

You can't count on getting a reference name from the registry because there
may not be one.

> others. It might be worth adding, but that topic is orthogonal to the one at

-1

There is an unbounded amount of encyclopedic information we could add to the
registry.  Going outside the domain of the source standards, where do you stop?

-- 
John Cowan  [email-masked]  http://www.ccil.org/~cowan
Thor Heyerdahl recounts his attempt to prove Rudyard Kipling's theory
that the mongoose first came to India on a raft from Polynesia.
        --blurb for Rikki-Kon-Tiki-Tavi

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 3 Jan 2007 17:28:55 -0800

John Cowan <cowan at ccil dot org> wrote:

> In particular, the language-collection codes of 639-2 are not 
> replicated in 639-3 and have no reference names.  I don't care how you 
> sort the fields, but I am very much against giving guarantees about 
> the order of Description fields in 4646bis.  You'd have to say "The 
> first Description field is the reference name provided by the 
> standard, if it provides one at all."  Since we do not document which 
> subtags come from which standards, this is of very little use.

This is pretty much what draft-4646bis-02 says:

"For fields of type 'language' or 'extlang', the first 'Description' 
field appearing in the Registry corresponds to the Reference Name 
assigned by ISO 639-3."

It makes no claims about any other type of subtag, which is as it should 
be.  The only flaw, as John said, is that the claim is made for language 
collections not included in 639-3.  Whether there is a geniune problem 
here is left as an exercise.

In the debate over the Reference-Name field, I suggested that (a) the 
new field should be omitted when there was only one Description, (b) 
this would leave it ambiguous whether an ISO reference name actually 
existed, and (c) this is likely not a problem.  Perhaps the same is true 
here.

> We should break these up.  They are definitely alternative names.

And Mark agreed.

Naturally, this can't be simple: ISO 15924 uses parentheses for 
explanatory content as well as for alternative names.  I guess we should 
split out the following:

Devanagari (Nagari)
Deseret (Mormon)
Ethiopic (Ge&#x2BB;ez)
Ethiopic (Ge'ez)
Hangul (Hang&#x16D;l, Hangeul)
Han (Hanzi, Kanji, Hanja)
Hanunoo (Hanun&#xF3;o)
Indus (Harappan)
Lepcha (R&#xF3;ng)
Myanmar (Burmese)
Ol Chiki (Ol Cemet', Ol, Santali)
Shavian (Shaw)
Tifinagh (Berber)

and leave the following alone:

Cyrillic (Old Church Slavonic variant)
Khutsuri (Asomtavruli and Nuskhuri)
Georgian (Mkhedruli)
Han (Simplified variant)
Han (Traditional variant)
(alias for Hiragana + Katakana)
Old Italic (Etruscan, Oscan, etc.)
Japanese (alias for Han + Hiragana + Katakana)
Latin (Fraktur variant)
Latin (Gaelic variant)
Syriac (Estrangelo variant)
Syriac (Western variant)
Syriac (Eastern variant)

but others may disagree, and I need to know what to go with.

---

From: Martin Duerst <[email-masked]>
Date: Fri, 05 Jan 2007 17:04:27 +0900

Hello Doug,

At 10:28 07/01/04, Doug Ewell wrote:
>> In the ISO 639 world, only the entries in 639-3 have a reference name. In particular, the language-collection codes of 639-2 are not replicated in 639-3 and have no reference names.  I don't care how you sort the fields, but I am very much against giving guarantees about the order of Description fields in 4646bis.  You'd have to say "The first Description field is the reference name provided by the standard, if it provides one at all."  Since we do not document which subtags come from which standards, this is of very little use.
>
>"For fields of type 'language' or 'extlang', the first 'Description' field appearing in the Registry corresponds to the Reference Name assigned by ISO 639-3."
>
>It makes no claims about any other type of subtag, which is as it should be.  The only flaw, as John said, is that the claim is made for language collections not included in 639-3.  Whether there is a geniune problem here is left as an exercise.

I think it would be good if your draft could be slightly more
precise, i.e. say

"For fields of type 'language' or 'extlang', the first 'Description' field appearing in the Registry corresponds to the Reference Name assigned by ISO 639-3 if this entry exists in ISO 639-3."

(or some such)

>Naturally, this can't be simple: ISO 15924 uses parentheses for explanatory content as well as for alternative names.  I guess we should split out the following:

>(alias for Hiragana + Katakana)

Why doesn't this read
Kana (alias for Hiragana + Katakana) ?

Regards,    Martin.

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

---

From: "Doug Ewell" <[email-masked]>
Date: Fri, 5 Jan 2007 07:05:23 -0800

Martin Duerst <duerst at it dot aoyama dot ac dot jp> wrote:

> I think it would be good if your draft could be slightly more precise, 
> i.e. say
>
> assigned by ISO 639-3 if this entry exists in ISO 639-3."
>
> (or some such)

This is wording for draft-4646bis (Addison and Mark's draft), not 
draft-4645bis (mine).  But I agree with Martin's suggestion.

> Kana (alias for Hiragana + Katakana) ?

Because it's taken directly from ISO 15924.

---

From: John Cowan <[email-masked]>
Date: Fri, 5 Jan 2007 11:32:57 -0500

> Because it's taken directly from ISO 15924.

I have just asked ISO 15924/RA to change this.

-- 
All Gaul is divided into three parts: the part          John Cowan
that cooks with lard and goose fat, the part            http://ccil.org/~cowan
that cooks with olive oil, and the part that            [email-masked]
cooks with butter. -- David Chessler

---

From: "Kent Karlsson" <[email-masked]>
Date: Sat, 6 Jan 2007 00:10:26 +0100

> Kana (alias for Hiragana + Katakana) ?

Which would not be much better. There is no defined notion of "+"-ing
language names/codes, nor is there a defined notion of aliasing between
language codes. (Which has bugged me from the first time I saw it..)

"Kana (mix of Hiragana and Katakana)" would be suitably precise, and
avoids the (here) troublesome notions of "+"-ing and aliasing.

		/kent k

---

From: "Doug Ewell" <[email-masked]>
Date: Fri, 5 Jan 2007 22:38:58 -0800

Kent Karlsson <kent dot karlsson14 at comhem dot se> wrote:

>> Why doesn't this read Kana (alias for Hiragana + Katakana) ?
>
> language names/codes, nor is there a defined notion of aliasing 
> between language codes. (Which has bugged me from the first time I saw 
> it..)

I think the concept of mixing two scripts into a single writing system, 
which is the standard M.O. for Japanese (and to a much lesser extent 
Korean), is more clearly defined than mixing two languages.  Granted, es 
posible to have a mezcla of English y español in a single frase (and 
some people really do talk that way), but this is left to each 
application of language tags (such as Accept-Language) to handle in its 
own way.

As for aliases, (1) this is not something that any of the ISO standards 
provide as a regular feature, only for the two Japanese script cases; 
and (2) the Registry does support a form of aliases through deprecated 
subtags.  You can, for instance, use "ji" instead of "yi" for Yiddish, 
or "BU" instead of "MM" for Myanmar, though you are not encouraged to do 
so.

---

From: "Kent Karlsson" <[email-masked]>
Date: Sat, 6 Jan 2007 13:25:09 +0100

> > between language codes. (Which has bugged me from the first 

I actually meant to write 'script' rather than 'language' here, of course.

...
> Korean), is more clearly defined than mixing two languages.  

> provide as a regular feature, only for the two Japanese script cases; 

Well, it does not define any kind of aliasing.  I interpret 'alias' as
something rather formal. 15924 *informally* uses the word 'alias'
in one (now two) place(s). And what it "aliases" *to* is not something
that can be formally expressed in ISO 15924 codes; there is no way
of saying "Hira+Kata" (joining two or more codes to one, keeping the
individual codes as subexpressions) as a formal code in ISO 15924.
So I'd rather see that one does not use 'alias' for these, nor "+".

> or "BU" instead of "MM" for Myanmar, though you are not 
> encouraged to do so.

Or rather, 'encouraged not to do so' ("deprecated"). So they aren't
quite 'aliases' either, 'aliases' would be on a more equal footing.

The Registry does not have a notion of '+'-ing script codes
or similar, so aliasing still cannot be applied in the cases of Hrkt
and Jpan.

		/kent k

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 6 Jan 2007 09:07:16 -0800

> I actually meant to write 'script' rather than 'language' here, of 

OK, that does make the rest of your post a bit more meaningful.  You are 
talking about representing a mixture of Latin and Cyrillic scripts, not 
Swedish and Russian languages.

>> As for aliases, (1) this is not something that any of the ISO 
>> standards provide as a regular feature, only for the two Japanese 
>> script cases;
>
> something rather formal. 15924 *informally* uses the word 'alias' in 
> one (now two) place(s). And what it "aliases" *to* is not something 
> that can be formally expressed in ISO 15924 codes; there is no way of 
> saying "Hira+Kata" (joining two or more codes to one, keeping the 
> individual codes as subexpressions) as a formal code in ISO 15924. So 
> I'd rather see that one does not use 'alias' for these, nor "+".

Let me see if I understand.  When you talk about "aliases" as a feature 
you feel is important and missing in the ISO standards and in RFC 4646, 
are you talking about:

(a) having one code element to represent a combination of others, as 
"Hrkt" represents the union of "Hira" and "Kana"?

(b) having two code elements that represent the same (single) entity, 
sort of like "BU" and "MM" but without either one being deprecated?

(c) both (a) and (b) above?

(d) something else?

> The Registry does not have a notion of '+'-ing script codes or 
> similar, so aliasing still cannot be applied in the cases of Hrkt and 
> Jpan.

It's not the Registry, but rather the underlying RFC 4646, that 
disallows a construction like "jp-Hani+Hira+Kana".

---

From: "Kent Karlsson" <[email-masked]>
Date: Sat, 6 Jan 2007 20:58:27 +0100

Doug Ewell wrote
> you feel is important and missing in the ISO standards and in 

I did not say that. I just said that it is not there, and hence cannot be
referred to. Just a statement of that fact, not saying that the concept
is missing (as different from just not being there). (The 'property value
aliases' in 15924 are, while true aliases, out  of scope for the LST
registry, since they do not fullfill the syntactic (4-letter) requirement.)
I.e. I'm NOT suggesting an introduction of an alias concept for 4-letter
script codes.

> (d) something else?

Only that 
  Hrkt 412 (alias for Hiragana + Katakana) (alias pour hiragana + katakana) 
and 
  Jpan 413 Japanese (alias for Han + Hiragana + Katakana)
	japonais (alias pour han + hiragana + katakana) 
should be changed so as to NOT refer to "alias" nor to "+".

I would suggest to use
  Hrkt 412 Kana (mix of Hiragana and Katakana) (mélange de hiragana et katakana) 
and 
  Jpan 413 Japanese (alias for Han, Hiragana, and Katakana)
	japonais (mélange de han, hiragana et katakana) 
respectively (for 15924 and by implication the similar text for LST).

> disallows a construction like "jp-Hani+Hira+Kana".

Indeed. Though such a thing may be useful, I'm ***not at all*** pushing for
introducing it. Just that one should not refer to a construct that is not there.
(Again NOT saying that it is 'missing', as opposed to 'not there'.)

		/kent k

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 6 Jan 2007 17:37:51 -0800

Kent Karlsson <kent dot karlsson14 at comhem dot se> wrote:

> I did not say that. I just said that it is not there, and hence cannot 
> be referred to. Just a statement of that fact, not saying that the 
> concept is missing (as different from just not being there).  (The 
> 'property value aliases' in 15924 are, while true aliases, out  of 
> scope for the LST registry, since they do not fullfill the syntactic 
> (4-letter) requirement.) I.e. I'm NOT suggesting an introduction of an 
> alias concept for 4-letter script codes.

I understand now.  This is a question of changing the descriptions in 
ISO 15924 so they do not use the word "alias" or the symbol "+" (though 
I don't see why the plus sign is a problem).  My apologies for the 
misunderstanding.