Subject: [Ltru] Re: Update to proposed registry

From: "Doug Ewell" <[email-masked]>
Date: Sun, 13 Mar 2005 14:52:00 -0800

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

> Would it make sense to make this into a working group i-d?
> When (re-)populating a registry, it seems like it would be nice
> to be able to give IANA something that had been under WG change
> control, without having to incorporate it all in the registry
> document.

I agree that it should be under some sort of change control.  My
change-history page is intended only as a starting point toward something
more official.

I don't think I agree that it should be an I-D, since it is not intended
to become an RFC.

> On the other hand, the format of the entries would be hard to
> reconcile with the constraints on i-ds.  Many of the lines exceed
> 72 characters.

The longest line is 140 characters (plus CR/LF), thanks to that
ridiculously long description for "zh-min-nan".  The proposed draft
registry (PDR) is consistent with the layout defined in Section 3.1, which
certainly makes it inconsistent with formats that insist on 72 characters.

> In any case, if the updated registry would contain
> information that cannot be derived algorithmically from the current
> registry contents, we *somehow* would have to provide that information
> to IANA, whether in the registry document itself or in a new companion
> document.  Ideas?

We do.  At least 98% of the PDR can be derived algorithmically from the
core ISO standards, their history pages, and the current registry -- you
would need all of these -- but there might be some surprises that need
explanation.  Perhaps it should be a new Appendix D to
draft-ietf-ltru-registry, rather than a new companion document.

Later:

> I think it would make sense to move this material into the IANA
> considerations section as a separate subsection, with a title
> something like "Initialization of the Registry".

Something like that.

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

> I tried to convince IANA that i-klingon should be marked as
> "deprecated, use tlh", but so far that had no effect.  Maybe
> using the generic registry update Web form was a bad idea (?)

The PDR has the following entries:

language | tlh | Klingon; tlhIngan-Hol | 2004-07-06 | |

grandfathered | i-klingon | Klingon | 1999-05-26 | tlh | # deprecated
2004-02-24

The grandfathered tag "i-klingon" has a canonical value of "tlh", which
does what you want.

> Maybe something like this is possible with xml2rfc:
>
> Column 1 goes to the scetion title, it would be redundant in
> the I-D lines.  One section "region", one "language", etc.
>
> Columns 2 and 4 (subtag and date) always exist, that could be
> the first line of each entry.  Column 5 (canonical value) also
> fits into the first line.  Column 3 and 6 could go into the
> second line for each entry.  Some style of list in xml2rfc
> could probably handle this.  That strategy would work for the
> worst case (longest line) grandfathered | zh-min-nan | etc.

If we are going to shoehorn the registry into an RFC-compatible format, we
will need to revise Section 3.1 substantially.  The primary intent of the
format was to be machine-readable, rather than laid out attractively for
humans (cf. the current registry).

I'm in favor of WG accountability and control over the registry, but
against trying to turn it into an RFC.  An RFC can't be changed once it's
published, which is exactly what we don't want to happen with the
registry.

-Doug Ewell
 Fullerton, California
 http://users.adelphia.net/~dewell/

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

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Sun, 13 Mar 2005 19:57:57 -0500

> I'm in favor of WG accountability and control over the 
> registry, but against trying to turn it into an RFC.  An RFC 
> can't be changed once it's published, which is exactly what 
> we don't want to happen with the registry.

Don't confuse the contents of a registry with the contents of an RFC.  An
I-D/RFC can be used to tell IANA how to create a registry, how the entries
are formatted, and how new entries are approved.  It can also be used to
populate initial values. The contents of the registry itself can change over
time, though, and the initial RFC doesn't have to change to make that
happen.

The IETF likes to use RFCs or other stable standards specifications to
populate IANA-maintained registries for tracking and community review
purposes.  RFCs can be obsoleted if need be.  The thing to consider is just
how often the contents of the registry will need to be changed.

-Scott-

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 14 Mar 2005 02:10:14 +0100

Doug Ewell wrote:

> i-klingon | Klingon | 1999-05-26 | tlh | # deprecated 2004-02-24

Yes, you have it, but IANA still has the old entry.  This could
be a hen and egg issue.  I've got a confirmation for the update
request, maybe they'll fix it after the IETF meeting, I'll ask
them again in about two weeks.  It's "obvious" (after somebody
told me where to find "tlh").

You still have "i-default" without canonical "und", and I still
don't see the difference between "i-default" and "und".  Both
are dummies.  If they are different I'd like some explanations
in the draft.  So far I only understand "avoid UND like hell"
(2.3 clause 4), but "i-default" is not much better, or is it ?

> If we are going to shoehorn the registry into an 
> RFC-compatible format

It's only an I-D limitation, the later registry itself can be
in the form proposed in the draft.  Published by IANA in any
form they like.  You can see the somewhat dubious results for
the "header registry", compare it with the complete input in
draft-klyne-hdrreg-mail-05

<http://www.ietf.org/internet-drafts/draft-klyne-hdrreg-mail-05.txt>

I really wonder what happens when the IETF expires this draft,
all the good work lost unless somebody offers a public copy ?

> The primary intent of the format was to be machine-readable,
> rather than laid out attractively for humans

Yes, that's fine, if IANA gets the idea.  The existing charset
registry could be a model for a more IANA-friendly format, also
working in a separate I-D or in 3066bis IANA considerations:
<http://www.iana.org/assignments/character-sets>

For your purposes you would probably split what you have in six
files:  languages, scripts, regions, variants, grandfathered,
redundant.  Each part has its own source(s), e.g. ISO 639 for
the languages.  Each entry could consist of up to five lines,
terminated by an empty line:

Name: in
Description: Indonesian
Date: 2004-07-06
Canonical: id
Comment: # deprecated 1989

Or something like this format all in one file, then you'd say:

Language: in
Description: Indonesian
Date: 2004-07-06
Canonical: id
Comment: # deprecated 1989

Even if that's a bad idea you could apparently delete all "# " 
in the column for comments, or is this a feature ?

                            Bye, Frank

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 13 Mar 2005 17:33:41 -0800

Hi -

(co-chair hat off)

> From: "Scott Hollenbeck" <[email-masked]>
> To: "'Doug Ewell'" <[email-masked]>; <[email-masked]>
> Sent: Sunday, March 13, 2005 4:57 PM
> Subject: RE: [Ltru] Re: Update to proposed registry
...
> how often the contents of the registry will need to be changed.
...

Also, just putting something into an i-d does not necessarily put it
on the path to publication as an RFC.

Though I like some aspects of the abstract idea of having the initial contents
of the registry in an internet-draft (rather than a web page somewhere)
because it fits in with the way IANA likes to work, I worry when discussion
turns to changing the format of registry entries simply in order to
accommodate the constraints on posting the information in the form of
an internet-draft, unless there would be other, substantial benefits from
those format changes.

In any case, I think that using i-ds or RFCs as the *update* mechanism
after the registry has been initialized would be far too heavy-weight.

I think we have several alternatives available for initializing the registry:
   1) pointer to external file/web site (current proposal in -registry-00.txt
   2) reference to WG internet-draft handed to IANA
   3) reference to WG RFC containing initial contents
   4) embed initialization data into appendix of registry document

Did I miss some?  My biggest concern about 2-4 is that the quirks
of i-d posting and rfc publication  formats would require us to spend
time on aspects of registry entries that we might otherwise not
have to spend.

Randy

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 13 Mar 2005 17:50:30 -0800

Scott Hollenbeck <sah at 428cobrajet dot net> wrote:

> Don't confuse the contents of a registry with the contents of an RFC.
> An I-D/RFC can be used to tell IANA how to create a registry, how the
> entries are formatted, and how new entries are approved.  It can also
> be used to populate initial values. The contents of the registry
> itself can change over time, though, and the initial RFC doesn't have
> to change to make that happen.

The current draft does all of these except the last (populating the
initial values).  Appendix C proposes that the WG chair will present a
proposed registry for Last Call, and describes how it is put together
(more or less), but doesn't specify how it is managed before then.

The draft *could* be revised to include the entire proposed registry.
I'm not saying it *should*, and in fact I thought I remembered someone
arguing months ago on ietf-languages that an RFC was no place for a code
list.  (That may have been just their opinion, of course.)

> purposes.  RFCs can be obsoleted if need be.  The thing to consider is
> just how often the contents of the registry will need to be changed.

The registry will need to be updated:

(a) to register a new subtag to reflect a new ISO 639, 3166, or 15924
code;
(b) to register a new variant (or extlang) subtag;
(c) to reflect the approval of an extension RFC (is this true?);
(d) to change a description in a way compatible with Section 3.2;
(e) to add new values to the "recommended prefix" field;
(f) to reclassify a grandfathered tag as redundant, per Section 3.2;
(g) to change any comment.

My first attempt at the registry was on 2004-07-06.  Since then, there
have been 22 revisions, but most were reflections of the evolving nature
of the draft.  By my count, there have been 9 changes that would have
taken place if RFC 3066bis were live and stable.  This extrapolates to
about one change per month.

-Doug Ewell
 Fullerton, California

---

From: John Cowan <[email-masked]>
Date: Sun, 13 Mar 2005 21:29:42 -0500

Frank Ellermann scripsit:

> in the draft.  

i-default means "the language readable to the most people", typically
English with the hard bits left out.  und means "language has not
yet been determined", and should be used only when a language MUST
be specified and no information is available.

-- 
If you have ever wondered if you are in hell,         John Cowan
it has been said, then you are on a well-traveled     http://www.ccil.org/~cowan
road of spiritual inquiry.  If you are absolutely   http://www.reutershealth.com
sure you are in hell, however, then you must be         [email-masked]
on the Cross Bronx Expressway.          --Alan Feuer, NYTimes, 2002-09-20

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 14 Mar 2005 04:07:42 +0100

John Cowan wrote:
 
> i-default means "the language readable to the most people",
> typically English

Yes, but if I use English in an implementation, for whatever
reason, then why not say "en" in an enforced language tag ?
In cases where "en" makes no sense I could still use "und".

In other words, why not add this beast to chapter 2.3 (4)
in the next draft ?  The registry could reflect this with a
comment "NOT RECOMMENDED" for "und", or "NOT RECOMMENDED,
consider 'en' or 'und'" for "i-default".  If somebody still
insists on "i-default" he got at least a fair warning.  Bye.

---

From: John Cowan <[email-masked]>
Date: Sun, 13 Mar 2005 22:58:34 -0500

> reason, then why not say "en" in an enforced language tag ?

RFC 2277 says in Section 4.5, Default Language:

   When human-readable text must be presented in a context where the
   sender has no knowledge of the recipient's language preferences (such
   as login failures or E-mailed warnings, or prior to language
   negotiation), text SHOULD be presented in Default Language.

   Default Language is assigned the tag "i-default" according to the
   procedures of RFC 1766. It is not a specific language, but rather
   identifies the condition where the language preferences of the user
   cannot be established.

   Messages in Default Language MUST be understandable by an English-
   speaking person, since English is the language which, worldwide, the
   greatest number of people will be able to get adequate help in
   interpreting when working with computers.

   Note that negotiating English is NOT the same as Default Language;
   Default Language is an emergency measure in otherwise unmanageable
   situations.

   In many cases, using only English text is reasonable; in some cases,
   the English text may be augumented by text in other languages.

> In cases where "en" makes no sense I could still use "und".

"Und" is consistent, e.g., with the text being in Comanche when the tagger
doesn't know that.  Neither "en" nor "i-default" is consistent with that.

-- 
The Unicode Standard does not encode            John Cowan
idiosyncratic, personal, novel, or private      http://www.ccil.org/~cowan
use characters, nor does it encode logos        http://www.reutershealth.com
or graphics.                                    [email-masked]

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 14 Mar 2005 06:29:02 +0100

John Cowan wrote:

 [BCP 18]
>| In many cases, using only English text is reasonable; in
>| some cases, the English text may be augumented by text in
>| other languages.

 [i-default vs. und] 
> "Und" is consistent, e.g., with the text being in Comanche
> when the tagger doesn't know that.  Neither "en" nor
> "i-default" is consistent with that.

Okay, maybe I've got it finally:  "und" stands for "I have no
clue, it could be Greek".  For "i-default" I'd know what it is,
it's something that makes sense at least for an "en"-audience.
  
But it's not really "en", otherwise I could say so in the tag.
And it's less than "mul", because it would always include "en"
where "mul" could be anything.

Maybe it's only an error number / sound / icon, or some words
making sense in more than only English (stop / verboten / ...).

Is that the idea ?  A pointer to BCP 18 in the comment column
for i-default could help.  Or IANA should keep the existing
i-files with the grandfathered details.  IANA should also keep
the details for all future registered variants, if they don't
fit in the comments column of the future registry.  Bye, Frank

---

From: John Cowan <[email-masked]>
Date: Mon, 14 Mar 2005 00:52:04 -0500

Frank Ellermann scripsit:

> clue, it could be Greek".

Yes, and the only reason to use it is when you MUST tag.  If tagging
is optional, then omitting a tag is better than using "und".

> For "i-default" I'd know what it is,

Correct.

> making sense in more than only English (stop / verboten / ...).

Indeed.  I note that STOP appears on many road signs even in
non-anglophone countries, e.g.

> fit in the comments column of the future registry.  Bye, Frank

A good idea.

-- 
How they ever reached any  conclusion at all    [email-masked]>
is starkly unknowable to the human mind.        http://www.reutershealth.com
        --"Backstage Lensman", Randall Garrett  http://www.ccil.org/~cowan

---

From: Martin Duerst <[email-masked]>
Date: Mon, 14 Mar 2005 14:57:44 +0900

>draft-ietf-ltru-registry, rather than a new companion document.

If we are already at 98%, how much more effort would it be to
reach 100%? If it is reasonably easy to reach 100%, I think we
should try to reach it. This would change the initial registry
from "a separate document approved by the WG and handed over
by the chairs to IANA (or whatever other process details we choose)"
to essentially be approved by the IESG based on IETF consensus.
We could still actually hand over the actual document to the IANA,
but anybody could veryfy that it's just an embodiment of what the
registry draft/rfc says.

Regards,   Martin.

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 14 Mar 2005 16:02:00 +0100

I note this quoted RFC 2277 paragraph is inconsistent on the "English" issue.

At 04:58 14/03/2005, John Cowan wrote:
>    speaking person,

This is consistent with current international and industry practice which 
is the use of Basic English that obviously every English person will 
understand.

>    since English is the language which, worldwide, the

This  is uncorrect. My Franglish shows it. The language the greatest number 
of persons working with computers will be able to interpret is Basic 
English. As far as I remember from long ago Boeing Basic English uses 800 
terms and Airbus 400. Oxford or Harvard English will be of no use to 
programers or users.

A common example is "depress the A key" is perfect ununderstable English to 
a user. "Hit the A key" is.

I note that (at least a decade ago) DoD RFPs required text documentations 
to match grade tests. A kid of a given grade was to be able to understand 
the text: a program made available by various US Agencies and private firms 
permited to run the test.

There should be a way to describe these different English langagues.

>    the English text may be augumented by text in other languages.

I suggest that an RFC considers the definition of a IANA Basic English and 
of an international code consistency. For example, I note that "xn" (the 
header of ACE labels produced by punycode) is the standard European code 
for "danger" and a promotion for XN Inc. the leading insurrance company for 
expatriated persons. It is also commonly understood as "Christians" and in 
some readings as "xenophobe", different understandings which are not 
appropriate with the signaling of an international transcoding of a local 
language.

Such an RFC could also address the issue of the language Icons in an ISO 
7000 consistent way.
jfc

=====================================================
For your convenience:
Draft: 		http://www.inter-locale.com/ID/draft-ietf-ltru-registry-00.txt
Charter: 	http://ietf.org/html.charters/ltru-charter.html
gmane: 	http://dir.gmane.org/gmane.ietf.ltru
If you were Bcced for information and not familliar with the IETF process:
http://www.ietf.org/rfc/rfc2026.txt
http://www.ietf.org/rfc/rfc2418.txt
http://www.ietf.org/rfc/rfc3934.txt
http://www.ietf.org/rfc/rfc3669.txt
http://www.ietf.org/rfc/rfc3160.txt
http://www.ietf.org/internet-drafts/draft-hoffman-taobis-02.txt
=====================================================
Jon Postel (RFC 1591): "The IANA is not in the business of deciding
what is and what is not a country. The selection of the ISO 3166 list
  as a basis for country code top-level domain names was made with
  the knowledge that ISO has a procedure for determining which
entities should be and should not be on that list."
=====================================================
Brian Carpenter (RFC 1958/3.2): "If there are several ways of doing the
same thing, choose one. If a previous design, in the Internet context
or elsewhere, has successfully solved the same problem, choose the
same solution unless there is a good technical reason not to.
Duplication of the same protocol functionality should be avoided as far as
possible, without of course using this argument to reject improvements."
=====================================================
It seems that what works for countries and ISO 3166 since 1978 should
apply to languages and to ISO 693.
=====================================================