Subject: [Ltru] 639-5 (was RE: ISO 639 language code addition rules...)

From: "Kent Karlsson" <[email-masked]>
Date: Sun, 1 Jun 2008 13:42:55 +0200

Doug Ewell wrote:
> I know some WG members will argue that collection codes are Evil, in 
> which case I would respond that perhaps we need to think beyond Web 
> servers and spell-checkers.  Our intent is for language tags to be 
> useful for a wide variety of applications, and as far as I know --  
> despite the horror stories -- collection codes haven't caused major 
> tagging problems since 2001 (publication date of RFC 3066, 
> which first allowed them).

I assume that for -5 there is a rule that the codes are in the same
"namespace" as 639-3 codes. In that case, I would not at all mind
including the "new" -5 code elements (but I'm a bit hesitant to
exclude some of them based on a not-sure-to-be-correct coverage
analysis). I also don't mind making collection/family codes inclusive,
i.e. exclude the "(other)", as Peter mentioned. 

But I would like some firmer recording in the LSR of the fact that a
code is a collection/family code (rather than relying on "languages"
or "(family)" being part of the name, or just referring back to 639-5).
Something like "Type: language collection" or similar. Pushing this a
bit, macrolanguages should similarly be explicitly recorded as such
(rather than just implicitly), by something like "Type: macrolanguage"
instead of just "Type: language". I know there is a way of inferring
this information, but it is better to be explicit, and not need to
infer that information or refer back to the -3 registry. IIUC, this
would leave "Type: language" for individual languages only.

I'm not suggesting any formal restrictions on the use of language
collection/family codes, beyond the informal warning we have already.
I'm sure some of the (non-new) collection codes have been used to
language tag documents in languages not covered by the LSR yet
(but will be, once LTRU II finishes...) with an individual language
code.

	/kent k

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

---

From: Leif Halvard Silli <[email-masked]>
Date: Sun, 01 Jun 2008 14:01:05 +0200

Kent Karlsson 2008-06-01 13.42:

>> servers and spell-checkers.  [...]

+1 for including collection codes.

> [...] I also don't mind making collection/family codes inclusive,

+1 for inclusive collection/family codes

> would leave "Type: language" for individual languages only.

+1 one for "Type: macrolanguage" and "Type: language collection".

Being explicist is good. For example, the "no" code cannot be used 
for spell-checking unless you assume that it means either "nn" or 
"nb".

> collection/family codes, 

And not on macrolanguage codes either.

> beyond the informal warning we have already.

+1 for not having any formal restrictions.
-- 
leif halvard silli
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: Peter Constable <[email-masked]>
Date: Sun, 1 Jun 2008 05:39:05 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Kent Karlsson

> would leave "Type: language" for individual languages only.

If this sounds a bit familiar, we did discuss this back in ancient times -- Nov 2006. The 639-3 code tables were first getting checked out, and Mark Davis commented on what he thought should be included or excluded in the LSTR. The scope attribute (which is the one you're mentioning) is one that Mark thought wasn't needed since it could be derived. John Cowan concurred. Randy mentioned feature creep in relation to some other info, but didn't make a clear link between that comment and the scope attribute. Doug made mixed comments: he agreed that scope was derivable hence not needed, but also suggested adding _collection_ to Type information. But then we got sidetracked onto Swiss German. I' haven't seen if we ever decided against that or just forgot about it.

Peter

---

From: "Kent Karlsson" <[email-masked]>
Date: Sun, 1 Jun 2008 21:38:49 +0200

Phillips, Addison wrote:
> 
> I generally agree with the idea that having some of this 
> ancillary information in the registry would be useful. 
> However, the 'Type' field isn't the way to do this. The 
> 'Type' field indicates what kind of subtag it is.
> 
> Instead, I would suggest that we include some more 
> meta-information in specific fields in the registry. For 
> example, we could have a 'Source' field to indicate where a 
> record came from and an Attribute field for derived 
> attributes. Here's what our record collection might contain:
> 
> Type: language | extlang | script | region | variant | grandfathered | redundant

Well, I still hope that the extlang stuff is not really coming back...

> Subtag | Tag: <value>
> Added: <date>
> Deprecated: <date>
> Prefix: <value>
> Suppress-Script: <value>
> Description: <text>
> Source: ISO639-1 | ISO639-2 | ISO639-3 | ISO639-5 | ISO3166-1 | ISO15924 | registration

ISO639-2 would be retargeted (per "Type: language" subtag) as either ISO639-3
or ISO639-5 now, would they not? Given that, IIUC, the codes in ISO 639-2 by
necessity are also registered as ISO 639-3 or ISO 639-5 codes, and LTRU II are
retargeting from ISO 639-2 to ISO 639-3 and (hopefully also) ISO 639-5.

UNM49 (or similar "source code") should be there too, should it not?

> Attribute: macrolanguage | collection | ...

Maybe "Kind: individual | macrolanguage | collection" (required for "Type:
language", not allowed for other "Type"s. I would not recommend anything
similar for, say, region codes. Nit: And move it up to just after "Type". 

		/kent k

---

From: John Cowan <[email-masked]>
Date: Sun, 1 Jun 2008 15:29:19 -0400

> for spell-checking unless you assume that it means either "nn" or 

The same is true of "en" and "de".

-- 
Where the wombat has walked,            John Cowan <[email-masked]>
it will inevitably walk again.          http://www.ccil.org/~cowan
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: Leif Halvard Silli <[email-masked]>
Date: Sun, 01 Jun 2008 21:58:23 +0200

> The same is true of "en" and "de".

You mean that you cannot use "en" to spellcheck "de" unless you 
assume that "en" means "de".

However, with 'no' there is a very likely risk that someone thinks 
that 'no' is spesific enough. And that, or similar risks, exist 
for all macrolanguages.

The same is not true of "en" and "de".
-- 
leif halvard silli
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: John Cowan <[email-masked]>
Date: Sun, 1 Jun 2008 14:23:33 -0400

Doug Ewell scripsit:

> Arrggh.  I hate all this cherry-picking, even though it seems to be our 
> only path to internal agreement: no extlangs except for 'zh-*' (and 
> maybe 'sgn-*' and 'ar-*', we can't decide), no more ISO 639-1 codes even 
> if ISO assigns them, add ISO 639-5 codes except for these five.

I should point out that these six are a subset of the ones that 639-5
calls out as possibly problematic.  The other three they footnote have
to do with a dispute about whether "Caucasian" is a genetic grouping
or not, but we don't care about whether collections are genetic, areal,
name-based, or what.

> I should add the one where we add ISO 3166 exceptionally reserved codes 
> except 'UK', which is actually an exception to an exception.  At least 
> that one is based on a rule we already have about not adding exact 
> duplicates at registration time; it applies the rule to RFC 4645bis 
> publication time as well.  Still, it is yet another exception from the 
> ISO standards.

What would be the point of having a separate standard from ISO if we didn't
deviate from it from time to time?  :-)

-- 
John Cowan              [email-masked]          http://www.ccil.org/~cowan
Most people are much more ignorant about language than they are about
[other subjects], but they reckon that because they can talk and read and
write, their opinions about talking and reading and writing are as well
informed as anybody's.  And since I have DNA, I'm entitled to carry on at
length about genetics without bothering to learn anything about it.  Not.
                        --Mark Liberman
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Phillips, Addison" <[email-masked]>
Date: Sun, 1 Jun 2008 11:10:04 -0700

>
> I think the idea was, all ISO 639-3 encompassed languages should be
> added to the LSR with a "Macrolanguage" field, but only those with
> a
> macrolanguage mapping to 'zho' (and did we decide about 'ara'?)
> should
> be extlangs.  This should be clarified.

I presented this as an idea for resolving the impasse we seem to face, but it hasn't been ratified anywhere as yet. I think it garnered some support, but await the co-chairs recognition of it as a rough consensus item.

Addison

---

From: John Cowan <[email-masked]>
Date: Sun, 1 Jun 2008 15:27:23 -0400

Doug Ewell scripsit:

> If we want to exclude things, I would rather create a rule that says, 
> for example, "collection codes are excluded if they have only one member 
> which is already encoded as an individual language," as opposed to just 
> excluding it ad hoc.  That way people can debate the rule, not the 
> expertise of the WG members.

I'm okay with that as a PR measure (along with "if their members are already
coded as a macrolanguage"), but as I carefully said, there is no *official*
list of which languages are in what collections.  Ethnologue serves as a
guideline, but it is not directly part of 639.

-- 
John Cowan  [email-masked]   http://ccil.org/~cowan
Promises become binding when there is a meeting of the minds and consideration
is exchanged. So it was at King's Bench in common law England; so it was
under the common law in the American colonies; so it was through more than
two centuries of jurisprudence in this country; and so it is today.
       --Specht v. Netscape
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 1 Jun 2008 12:02:56 -0600

John Cowan <cowan at ccil dot org> wrote:

>>    Codes that have a defined
>>    "macrolanguage" mapping at the time of their registration MUST
>>    be entered into the registry as records of type 'extlang' with a
>>    'Prefix' field containing the appropriate prefix tag. They MUST
>>    also include a "Macrolanguage" field in their record. All other
>>    records are of type 'language'.</t>
>
> Presumably "a macrolanguage mapping to "zho" or "sgn".

I think the idea was, all ISO 639-3 encompassed languages should be 
added to the LSR with a "Macrolanguage" field, but only those with a 
macrolanguage mapping to 'zho' (and did we decide about 'ara'?) should 
be extlangs.  This should be clarified.

> And to this add:
>
> <t>Any other codes assigned by ISO 639-5 that do not conflict with 
> existing three-letter primary or extended language subtags and which 
> do not have ISO 639-1 two-letter codes assigned are entered into the 
> IANA registry as new records of type 'language'. Subtags assigned 
> according to this rule will be language collections.

+1.  I guess it will be clear to readers that the last sentence is 
informative only.

--
Doug Ewell  *  Arvada, 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  ˆ

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 1 Jun 2008 12:49:50 -0600

"Phillips, Addison" <addison at amazon dot com> wrote:

> I support 'sgn'... I also note that it was in draft-09 (draft-10 
> removed extlang), so I'm having to deal with it as a previous 
> consensus item.

We just need to be clear that 'sgn' as a prefix for extlangs would be 
our own doing, and would not be based on 'sgn' being an ISO 639-3 
macrolanguage, since it is not one.

---

From: "Phillips, Addison" <[email-masked]>
Date: Sun, 1 Jun 2008 11:28:00 -0700

I support 'sgn'... I also note that it was in draft-09 (draft-10 removed extlang), so I'm having to deal with it as a previous consensus item.

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

> -----Original Message-----
> From: John Cowan [mailto:[email-masked]]
> Sent: Sunday, June 01, 2008 11:21 AM
> To: Phillips, Addison
> Cc: Doug Ewell; LTRU Working Group; John Cowan
> Subject: Re: [Ltru] ISO 639 language code addition rules...
>
> Phillips, Addison scripsit:
>
> > I presented this as an idea for resolving the impasse we seem to
> face,
> > but it hasn't been ratified anywhere as yet. I think it garnered
> > some support, but await the co-chairs recognition of it as a
> rough
> > consensus item.
>
> Among the people who are willing to compromise at all, I think
> there is
> strong support for 'zh', weak support for 'sgn' (maybe only from
> me),
> and no support for 'ar' (you mentioned it as a hypothetical).
>
> --
> An observable characteristic is not necessarily         John Cowan
> a functional requirement.  --John Hudson
> [email-masked]

---

From: John Cowan <[email-masked]>
Date: Sun, 1 Jun 2008 14:20:49 -0400

Phillips, Addison scripsit:

> I presented this as an idea for resolving the impasse we seem to face,
> some support, but await the co-chairs recognition of it as a rough
> consensus item.

Among the people who are willing to compromise at all, I think there is
strong support for 'zh', weak support for 'sgn' (maybe only from me),
and no support for 'ar' (you mentioned it as a hypothetical).

-- 
An observable characteristic is not necessarily         John Cowan
a functional requirement.  --John Hudson                [email-masked]
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: John Cowan <[email-masked]>
Date: Sun, 1 Jun 2008 15:08:32 -0400

Peter Constable scripsit:

> Between 639-5 and 639-3, it looks like 639-2 would be redundant for
> our purposes.

Almost.  The four special code elements 'mis', 'mul', 'und', and 'zxx'
are in -2 but not -5 or -3, and in principle new code elements of this
type could be added to -2.  So we can't completely exclude adding subtags
from -2.

-- 
John Cowan    [email-masked]    http://ccil.org/~cowan
        Sound change operates regularly to produce irregularities;
        analogy operates irregularly to produce regularities.
                --E.H. Sturtevant, ca. 1945, probably at Yale
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 1 Jun 2008 11:52:38 -0600

John Cowan <cowan at ccil dot org> wrote:

>> Should we consider incorporating the 639-5 code elements into 
>> draft-4645bis?
>
> I think we should do so, despite 639-5 being technically off-charter.

Heck, we've spent a great deal of the past two years going off-charter. 
This is at least more closely related to charter work than some things 
we've done.

> There are no exact definitions of either the old 639-2 or the new 
> language collections, but if we identify them with their obvious 
> counterparts from the Ethnologue, I think these six cases require 
> special consideration:

I am reminded that back in late 2004, when the ietf-languages group had 
already worked on 3066bis (as an individual submission) for over a year 
and it went to IETF Last Call, we were harshly criticized for 
cherry-picking ISO country codes.  (The main focus at the time was on 
interpreting 'CS' as Czechoslovakia versus Serbia and Montenegro; we 
didn't have the Date A/B thing worked out yet.)  We were criticized for 
appearing to take over the role of ISO MAs and RAs, second-guessing 
which ISO codes should and should not exist and what they should mean. 
It would be a real shame if this happened again.

Since this WG is under the threat of being shut down -- I know Randy 
probably intends it more as a motivator than a threat, but the effect is 
the same -- I understand we need to work out compromises, and quickly. 
I just hope we are prepared to defend our decisions when we finally go 
to IETF LC and reviewers ask why we know better than this or that RA.

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 1 Jun 2008 13:18:43 -0600

John Cowan <cowan at ccil dot org> wrote:

>> I should add the one where we add ISO 3166 exceptionally reserved 
>> codes except 'UK', which is actually an exception to an exception. 
>> At least that one is based on a rule we already have about not adding 
>> exact duplicates at registration time; it applies the rule to RFC 
>> 4645bis publication time as well.  Still, it is yet another exception 
>> from the ISO standards.
>
> What would be the point of having a separate standard from ISO if we 
> didn't deviate from it from time to time?  :-)

Smiley noted, but to me this is the difference:

We can cherry-pick from ISO standards all we like (ISO 3166-1 even says 
this; the 639 family may too) but we must not assign different meanings 
to existing codes, and we must not assign new codes in a non-private-use 
space, and -- the important part here -- we SHOULD be able to justify 
why we have chosen the subset we have chosen.  (By "we", I mean not only 
that the WG can justify it to IETF, but also that ietf-languages can 
justify it to users on an ongoing basis.)

In the case of ISO 3166-1, we include exceptionally reserved code 
elements in our application because we perceive a need to encode those 
entities.  That is something we need to be able to justify (and I trust 
others on this list will make their case for 'EU'), and we are also 
supposed to notify ISO 3166/MA of our intent (I assume someone has 
already done that).  But, we have a rule that prohibits exact 
duplicates, and so we can use that to justify sub-exclusion of 'UK'. 
Fine: we can defend this when people ask us to.

In the case of language subtags, whether it has to do with extlangs or 
excluding certain ISO code elements or deprecating things in the 
Registry that aren't withdrawn from the standard (as was suggested for 
'mis' et al.), we should similarly be able to defend our decisions when 
people ask.  I'm concerned that when we exclude certain ISO codes, and 
reviewers ask us to explain why we did so, and our response is that we 
can't point to a rule but that "they don't make sense in language tags" 
or "they don't work well," that might not sit well.  We will be asked 
why we know better than the ISO TC and SC that developed the standard.

---

From: John Cowan <[email-masked]>
Date: Sun, 1 Jun 2008 15:11:54 -0400

Kent Karlsson scripsit:

> "namespace" as 639-3 codes. 

That is true.

> Something like "Type: language collection" or similar.

+1

> Pushing this a

I think that's just an invitation to error: it violates the DRY rule.

-- 
"The serene chaos that is Courage, and the phenomenon   [email-masked]
of Unopened Consciousness have been known to the        John Cowan
Great World eons longer than Extaboulism."
"Why is that?" the woman inquired.
"Because I just made that word up", the Master said wisely.
        --Kehlog Albran, The Profit             http://www.ccil.org/~cowan
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Phillips, Addison" <[email-masked]>
Date: Sun, 1 Jun 2008 09:37:16 -0700

I generally agree with the idea that having some of this ancillary information in the registry would be useful. However, the 'Type' field isn't the way to do this. The 'Type' field indicates what kind of subtag it is.

Instead, I would suggest that we include some more meta-information in specific fields in the registry. For example, we could have a 'Source' field to indicate where a record came from and an Attribute field for derived attributes. Here's what our record collection might contain:

Comments: <text>

Thoughts?

Addison

Addison Phillips

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Kent Karlsson
> Sent: Sunday, June 01, 2008 4:43 AM
> To: 'LTRU Working Group'
> Subject: [Ltru] 639-5 (was RE: ISO 639 language code addition
> rules...)
>
> Doug Ewell wrote:

---

From: John Cowan <[email-masked]>
Date: Sun, 1 Jun 2008 15:04:16 -0400

> macrolanguage, since it is not one.

Indeed.  In fact, I'm in favor of zh- and sgn- precisely because they
have backward-compatibility precedents.

-- 
Man has no body distinct from his soul,              John Cowan
for that called body is a portion of the soul        [email-masked]
discerned by the five senses,                        http://www.ccil.org/~cowan
the chief inlets of the soul in this age.  --William Blake
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: Leif Halvard Silli <[email-masked]>
Date: Sun, 01 Jun 2008 22:19:30 +0200

Kent Karlsson 2008-06-01 21.38:

>> ancillary information  [snip]

I'll just not that I have not received Addison's message except as 
part of Kent's reply.
-- 
leif halvard silli
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Phillips, Addison" <[email-masked]>
Date: Sun, 1 Jun 2008 13:22:22 -0700

> Well, I still hope that the extlang stuff is not really coming

Yes, but this seems increasingly remote. However, I think it possible that my suggestion be adopted.

> retargeting from ISO 639-2 to ISO 639-3 and (hopefully also) ISO

Agreed.

> UNM49 (or similar "source code") should be there too, should it not?

An oversight on my part. I also forgot to include the Preferred-Value field.

> similar for, say, region codes. Nit: And move it up to just after

I used 'Attribute' as a generic thing we could add more of in the future.

Best Regards,

Addison

---

From: John Cowan <[email-masked]>
Date: Sun, 1 Jun 2008 16:23:19 -0400

> assume that "en" means "de".

Of course not.  I mean that "en" is insufficiently specific to
spell-check: you need at least "en-us", "en-ca", "en-gb", "en-au",
and possibly others.

Likewise, "de-ch" has different spelling from other kinds of "de".

> that 'no' is spesific enough. And that, or similar risks, exist 

And for all pluricentric languages whether macro- or not.

-- 
John Cowan   <[email-masked]>   http://www.ccil.org/~cowan
One time I called in to the central system and started working on a big
thick 'sed' and 'awk' heavy duty data bashing script.  One of the geologists
came by, looked over my shoulder and said 'Oh, that happens to me too.
Try hanging up and phoning in again.'  --Beverly Erlebacher
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Phillips, Addison" <[email-masked]>
Date: Sun, 1 Jun 2008 13:43:48 -0700

> assume that "en" means "de".

No: he means that you cannot spellcheck "en" until you know if it is "en-US", "en-GB", "en-CA", etc. Similarly, there are German differences.

> that 'no' is spesific enough. And that, or similar risks, exist

That or similar risks exist for many, many languages. It is not at all inherent to macrolanguages. It isn't even necessarily a feature of macrolanguages.

> The same is not true of "en" and "de".

Which of these is spelled correctly: jail, gaol? How about: tire, tyre? Or: color, colour?

Addison

---

From: "Phillips, Addison" <[email-masked]>
Date: Sun, 1 Jun 2008 13:44:48 -0700

> Indeed.  In fact, I'm in favor of zh- and sgn- precisely because
> they have backward-compatibility precedents.

Hence the compromise. I think the backward-compatibility case is far more compelling than the macrolanguage case.

Addison

---

From: Leif Halvard Silli <[email-masked]>
Date: Sun, 01 Jun 2008 23:04:22 +0200

> And for all pluricentric languages whether macro- or not.

One could claim that whether "whichever" tag is enough, depends of 
the available tags. (We have for instance had many spelling 
reforms both for Bokmål and Nynorsk, but have no tags for this.)

However, was this only an argument against my argument?

Or was it an argument against adding a field in the registry which 
tells whether the tag represents a macrolanguage, a collection or 
an individual language?
-- 
leif halvard silli
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: Leif Halvard Silli <[email-masked]>
Date: Sun, 01 Jun 2008 23:06:46 +0200

Phillips, Addison 2008-06-01 22.43:

>> You mean that you cannot use "en" to spellcheck "de" unless
>> you assume that "en" means "de".
> 
> No: he means that you cannot spellcheck "en" until you know if
> it is "en-US", "en-GB", "en-CA", etc. Similarly, there are
> German differences.

Here you give me the correct interpretation of his letter.

[ snip ]

> tire, tyre? Or: color, colour?

Here you answer me, as if I had the correct interpretation of his 
letter.
-- 
leif halvard silli
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: Leif Halvard Silli <[email-masked]>
Date: Sun, 01 Jun 2008 23:26:30 +0200

> I think that's just an invitation to error: it violates the DRY rule.

Don't Repeat Yourself. However, if as Addisin proposed, this info 
should go into a separate Attribute field, then I can't see how 
the Macrolanguage attribute/information can be skipped.
-- 
leif halvard sili
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: John Cowan <[email-masked]>
Date: Sun, 1 Jun 2008 17:53:10 -0400

> reforms both for Bokmål and Nynorsk, but have no tags for this.)

Quite so.  If someone feels the need for them, they can be registered.

> However, was this only an argument against my argument?

Yes.

> tells whether the tag represents a macrolanguage, a collection or 

It was not.

-- 
John Cowan  [email-masked]   http://ccil.org/~cowan
"The exception proves the rule."  Dimbulbs think: "Your counterexample proves
my theory."  Latin students think "'Probat' means 'tests': the exception puts
the rule to the proof."  But legal historians know it means "Evidence for an
exception is evidence of the existence of a rule in cases not excepted from."
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: Peter Constable <[email-masked]>
Date: Sun, 1 Jun 2008 18:17:29 -0700

> type could be added to -2.  So we can't completely exclude adding
> subtags from -2.

They are in -3, actually, and I'd expect any added specials to be in both.

(The text of -3 is a bit inconsistent re this and could be improved.)

Peter

---

From: Martin Hosken <[email-masked]>
Date: Mon, 2 Jun 2008 08:22:41 +0700

Dear Addison,

> I used 'Attribute' as a generic thing we could add more of in the future.

Attributes tend to be key value pairs. If there is no key, then that information should be implicit in the field name.

Adding key value pairs would extend the syntax somewhat for minimal immediate gain, so I suggest having a specific field.

Yours,
Martin

---

From: Peter Constable <[email-masked]>
Date: Sun, 1 Jun 2008 18:24:48 -0700

> Phillips, Addison

> removed extlang), so I'm having to deal with it as a previous consensus
> item.

There was a previous consensus. I we go back to an extlang model, we should *not* revisit that decision, IMO.

Peter

---

From: Martin Duerst <[email-masked]>
Date: Mon, 02 Jun 2008 16:54:17 +0900

At 04:27 08/06/01, Peter Constable wrote:

>If it's an addition to 639-1, then either it will already have been in 
>639-2, or it is being added to both simultaneously, and it would get 
>announced together. It if is a new addition to 639-3, then likely it is not 
>something that would make it into 639-1. In general, I expect new additions 
>to 639-1 to be pretty rare.
>
>I've suggested before that we could decide that we will never again 
>register something from 639-1. That would eliminate these concerns entirely.

I agree about the probability of further registrations in 639-1.
But my guess is that if anybody manages to get a 'new' language
registered is 639-1, they will have a big interest to be able
to use this two-letter code on the Internet.

Actually, I think the main reason for new 639-1 registrations
will not be discoveries of new languages with big populations
of speakers, but politically motivated splits and changes such
as the Kroatian/Serbian case. I don't think it is possible to
call such cases absurd. Even if we don't see such a case on
the horizon, things can change quite quickly when they change.
So I don't want to rule out further 639-1 registrations.

Regards,    Martin.

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

---

From: Martin Duerst <[email-masked]>
Date: Mon, 02 Jun 2008 18:16:23 +0900

>and no support for 'ar' (you mentioned it as a hypothetical).

Just to make sure this is not overlooked, I supported 'ar' in a different
thread.

Regards,    Martin.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 2 Jun 2008 10:29:43 +0200

On Sun, Jun 01, 2008 at 12:00:08AM +0100,
 Debbie Garside <[email-masked]> wrote 
 a message of 80 lines which said:

> ISO 639-5 was published on the 15/05/2008

Where can we download it?
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Phillips, Addison" <[email-masked]>
Date: Mon, 2 Jun 2008 07:29:31 -0700

> to use this two-letter code on the Internet.

The big problem is to get a language code that isn't already a three-letter code.

> So I don't want to rule out further 639-1 registrations.

That's a very good point: "never" being, on average, a very long time.

Addison

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 2 Jun 2008 09:48:15 -0700

Hi -

As mailing list admin...

> From: "Leif Halvard Silli" <[email-masked]>
> To: "Kent Karlsson" <[email-masked]>
> Cc: "'LTRU Working Group'" <[email-masked]>
> Sent: Sunday, June 01, 2008 1:19 PM
> Subject: [Ltru] Mailinglist issue (was: 639-5 (was RE: ISO 639 language code addition rules...)
>

I don't know why that would have happened.  The message made
it to the archive (http://www.ietf.org/mail-archive/web/ltru/current/msg10688.html)
as well as to my own inbox vie tha mailing list.

Randy

---

From: "Debbie Garside" <[email-masked]>
Date: Mon, 2 Jun 2008 18:16:06 +0100

I have spoken with the Editor of ISO 639-5 and am reliably informed that the
MA (Library of Congress) will be making the file publicly available for free
download in the very near future.  The standard was only published a couple
of weeks ago and ISO had hoped that the Standard as Database initiative
would be up and running before publication of ISO 639-5 - in the event it is
not quite in place. I will let you know as soon as this becomes available.

In the meantime, I have supplied Doug with the tables from the BSI copy of
the standard for inclusion within the LSR - assuming the WG agrees.

Best regards

Debbie

> From: Stephane Bortzmeyer [mailto:[email-masked]]
> Sent: 02 June 2008 09:30
> To: Debbie Garside
> Cc: 'Doug Ewell'; 'LTRU Working Group'
> Subject: Re: ISO 639 language code addition rules...
>
> On Sun, Jun 01, 2008 at 12:00:08AM +0100,  Debbie Garside
> <[email-masked]> wrote  a message of 80 lines which said:
>

---

From: "Phillips, Addison" <[email-masked]>
Date: Mon, 2 Jun 2008 10:26:23 -0700

Hi, (editor hat on)

Assuming we do this, I need to create a reference for it in the draft. Could someone please provide me with:

- the official name of Part 5

- a pointer to the name, address, phone, URL, etc. of the MA or RA

Thanks,

Addison

Addison Phillips

> Behalf Of Debbie Garside
> Sent: Monday, June 02, 2008 10:16 AM
> To: 'Stephane Bortzmeyer'
> Cc: 'LTRU Working Group'; 'Doug Ewell'

---

From: "Debbie Garside" <[email-masked]>
Date: Mon, 2 Jun 2008 18:44:44 +0100

The MA/RA is Library of Congress - same as ISO 639-2.

The official name is:

Codes for the representation of names of
languages —
Part 5: Alpha-3 code for language families and groups

et en Français pour Stephane...

Codes pour la représentation des noms
de langue —
Partie 5: Code alpha-3 pour les familles de langues et groupes de langues

Best regards

Debbie

> From: Phillips, Addison [mailto:[email-masked]]
> Sent: 02 June 2008 18:26
> To: [email-masked]; 'Stephane Bortzmeyer'
> Subject: RE: [Ltru] ISO 639 language code addition rules...
>
> Hi, (editor hat on)
>
> Assuming we do this, I need to create a reference for it in
> the draft. Could someone please provide me with:
>
> > From: [email-masked] [mailto:[email-masked]]
> On Behalf
> > Of Debbie Garside
> > I have spoken with the Editor of ISO 639-5 and am reliably informed
> > that the MA (Library of Congress) will be making the file publicly
> > available for free download in the very near future.  The
> standard was
> > only published a couple of weeks ago and ISO had hoped that the
> > Standard as Database initiative would be up and running before
> > publication of ISO 639-5 - in the event it is not quite in place. I
> > will let you know as soon as this becomes available.
> >
> > In the meantime, I have supplied Doug with the tables from the BSI
> > copy of the standard for inclusion within the LSR - assuming the WG
> > agrees.
> >
> > Best regards
> >
> > Debbie
> >

---

From: "Phillips, Addison" <[email-masked]>
Date: Mon, 2 Jun 2008 10:46:05 -0700

Thanks,

Addison

Addison Phillips

> From: Debbie Garside [mailto:[email-masked]]
> Sent: Monday, June 02, 2008 10:45 AM
> To: Phillips, Addison; 'Stephane Bortzmeyer'
> > > > <[email-masked]> wrote  a message of 80 lines
> which
> > > said:
> > > >

---

From: "Mark Davis" <[email-masked]>
Date: Mon, 2 Jun 2008 11:35:32 -0700

In general, I think adding 639-5 codes would be a good idea, as long as the
list will be publicly available by the time we release. I'm however a bit
concerned by the issues raised by John, of codes that have the same
denotation as 639-3 codes; we need to resolve that before we can have a full
consensus. (We have to discuss this, but my preference for John's cases
would be rather than excluding the codes, to deprecate&prefer the others.)
On the part of the two-letter primary language subtags, I think our best
approach would just disallow them. While it would be very unlikely that this
would ever happen, it is very simple for us to prevent any instabilities
that might occur.

Mark

On Mon, Jun 2, 2008 at 10:26 AM, Phillips, Addison <[email-masked]>
wrote:

> > that the
> > copy of

-- 
Mark

---

From: Leif Halvard Silli <[email-masked]>
Date: Mon, 02 Jun 2008 21:58:40 +0200

> as well as to my own inbox vie tha mailing list.

Later on, I received that message, and a whole bunch of other. 
There are, however, some problems with this list. This is not the 
first time messages have been delayed for some users. And also, it 
has been made clear that the mailinglist software is removing some 
bits of the Content-Type field, namely information about whether 
the message was sent with forma=flowed etc - which again causes 
bad user experiences when replying to those messages for many 
within this group.
-- 
leif halvard silli
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: John Cowan <[email-masked]>
Date: Mon, 2 Jun 2008 16:19:20 -0400

> would be rather than excluding the codes, to deprecate&prefer the others.)

I don't understand the purpose of this.  When we added the 639-2 codes,
we did not add 'eng' as a pre-deprecated subtag with a Preferred-Value of
'en'.  If we have good reason to exclude something, we should exclude it.

> would ever happen, it is very simple for us to prevent any instabilities

639-1 should stay in, because we might have another politically motivated
split where the successor languages are individually important enough
to get 639-1 codes.

-- 
After fixing the Y2K bug in an application:     John Cowan
        WELCOME TO <censored>                   [email-masked]
        DATE: MONDAK, JANUARK 1, 1900           http://www.ccil.org/~cowan
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Mark Davis" <[email-masked]>
Date: Mon, 2 Jun 2008 13:56:42 -0700

> 'en'.  If we have good reason to exclude something, we should exclude it.

It is not so black and white. The advantage of adding something as
deprecated is that we have a formal relation between it and the
preferred-value. That helps in cases where people have expected that
everything in a particular set (eg 639-5) would work.

I wouldn't actually mind having "eng" in and deprecated to "en"; we end up
having to do that in software anyway because it occurs sufficiently often.

> split where the successor languages are individually important enough

That is possible, and now that I think about it the above logic would point
in that direction. I guess the only restriction we'd have to make is that it
cannot be introduced *after* an equivalent three-letter code.

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 2 Jun 2008 14:30:44 -0700

Hi -

As list admin...

> To: "Randy Presuhn" <[email-masked]>
> Sent: Monday, June 02, 2008 12:58 PM
> Subject: Re: [Ltru] Mailinglist issue
...
> bad user experiences when replying to those messages for many 

For such problems, which are entirely out of the hands of us list admins,
please refer to [email-masked].  Include *COMPLETE* headers,
after of course looking at those headers to verify that any outrageous
delays are happening within the ietf.org or amsl.com domains, and
not somewhere "out there".

My recommendations to all list subscribers:
   (1) DO NOT reply to posters or cc: individuals - just use the
         mailing list address.  This will significantly reduce the amount
         of out-of-order stuff people receive, and makes the discussion
         *much* easier to follow.
   (2) DO NOT use format=flowed.  In my experience, it doesn't work
         well anyway.

Randy

---

From: John Cowan <[email-masked]>
Date: Mon, 2 Jun 2008 18:43:31 -0400

> cannot be introduced *after* an equivalent three-letter code.

2.2.1 of RFC 4646 already says that.

-- 
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
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 3 Jun 2008 14:11:46 +0200

On Mon, Jun 02, 2008 at 02:30:44PM -0700,
 Randy Presuhn <[email-masked]> wrote 

> please refer to [email-masked].  Include *COMPLETE* headers,

Done,  [rt.amsl.com #7755] "Content-type attributes dropped
on the LTRU mailing list"

>    (2) DO NOT use format=flowed.  In my experience, it doesn't work

I strongly disagree. First, I've never seen such problems anywhere
and, second, this is the only solution to have free-flow text in plain
text. I do not want to use HTML, or to limit to the size of the old
VT100 terminal.
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: 'Stephane Bortzmeyer' <[email-masked]>
Date: Tue, 3 Jun 2008 14:09:49 +0200

On Mon, Jun 02, 2008 at 06:44:44PM +0100,
 Debbie Garside <[email-masked]> wrote 

> The MA/RA is Library of Congress - same as ISO 639-2.

Thanks for the info but their Web site still has zero information
about ISO 639-5 except the FAQ
<http://www.loc.gov/standards/iso639-2/faq.html> which says that ISO
639-5 is still under development.
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: Peter Constable <[email-masked]>
Date: Tue, 3 Jun 2008 06:58:09 -0700

> 'Stephane Bortzmeyer'

> 639-5 is still under development.

I can confirm that LOC has been designated as RA, the lack of info on their set as yet notwithstanding.

Peter

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 6 Jun 2008 20:41:13 +0200

On Tue, Jun 03, 2008 at 02:11:46PM +0200,
 Stephane Bortzmeyer <[email-masked]> wrote 
 a message of 21 lines which said:

> Done, [rt.amsl.com #7755] "Content-type attributes dropped on the
> LTRU mailing list"

AMSL reports that the format=flowed bug is fixed. We'll be able to
read Doug Ewell's messages again :-)
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 6 Jun 2008 11:48:35 -0700

Hi -

Thanks for the update on the [email-masked] mailing list.
I'm sure the folks who like "format=flowed" will appreciate
the news.

Randy

> From: "James M Galvin via RT" <[email-masked]>
> To: <OtherRecipients of rt.amsl.com Ticket #7749 :>
> Cc: <[email-masked]>
> Sent: Friday, June 06, 2008 9:02 AM
> Subject: [rt.amsl.com #7749] Mailinglist issue 
>
> On Mon Jun 02 15:39:36 2008, [email-masked] wrote:
> 
> >   1. Mailinglist software deletes "format=flowed" from the
> >      content-transfer header field of messages which are
> >      sent to the mailinglist.
> 
> It turns out that Mailman had a known bug.  I was able to find a
> documented bug with patch, which Glen has now installed.
> 
> >   2. Messages have been delayed.
> 
> We have not taken any action with respect to this issue, except that I
> have subscribed to the mailing list and will make a point of observing
> delivery times of messages for a few days.
> 
> My suggestion at the moment is to chalk this up to the vagaries of
> email, or perhaps an isolated incident or two.  I'm sure you can
> appreciate that unless we can identify a consistent pattern or a
> systemic issue it's hard to take any action.
> 
> I'm going to consider this ticket closed for now.  If you do continue to
> see delay problems please do report it to [email-masked].  If it
> continues to happen I'm sure we'll figure out what is going on eventually.
> 
> Thanks,
> 
> Jim
>