Subject: [Ltru] Re: Registry in record-jar format

From: "Doug Ewell" <[email-masked]>
Date: Thu, 24 Mar 2005 22:25:21 -0800

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

> Great, thanks, but we still need the normal RfC (2)822 folding
> for a proper I-D e.g. in line 4068 (107 characters).  The idea
> is to replace a space <SP> by <CrLf><SP>:

Good idea.  I wasn't sure which approach to use for line continuation.
I've gone ahead and adopted this one, without the tab, for the two lines
that extended beyond 80 characters (language 'cu' and grandfathered
'zh-min-nan').  This has now been uploaded.

>> This has no official sanction or consensus
>
> As soon as it's an I-D it's an "official draft registry".

We're not at that point yet.  There's been talk of making the registry
into an I-D, but I thought the most recent idea was to publish the rules
for initially populating it instead.

(BTW, nobody has commented yet on my recipe for populating the language
subtags, so I assume there's nothing dreadfully wrong with it.  I'll do
the other sections in similar fashion, perhaps this weekend.)

> At the moment I'm more worried about the size of the future
> registry for 7000+ languages, IANA is probably forced to split
> it somehow on its Web pages.

I'm not sure why that should be a problem.  Yeah, the file would get
bigger -- about 550,000 bytes bigger in record-jar format, or 340,000
bytes bigger in bar-delimited format, by my estimate -- but does that
cause any real problems?  You can now buy a 512 MB JumpDrive for 40 USD,
or a 200 GB hard drive for 100 USD; surely a registry of 600,000 bytes
isn't the greatest of our worries.  I would think the inconvenience of
dealing with multiple files and keeping them synchronized would be a
greater concern.

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

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

---

From: "Doug Ewell" <[email-masked]>
Date: Thu, 24 Mar 2005 23:08:45 -0800

Peter Constable <petercon at microsoft dot com> wrote:

>> The RFC 3066bis generative syntax is a superset of the RFC 3066
>> generative syntax.  It allows things to be generated that cannot be
>> generated under RFC 3066.
>
> This needs a little clarification:
>
> RFC 3066 has a weak syntax that permits lots of strings; it sanctions
> a small set of those, requiring others to be registered explicitly.
>
> RFC3066bis has a stronger syntax that permits a much more restrictive
> set of strings than does RFC 3066. On the other hand, it sanctions a
> much larger portion of the strings its syntax permits, making the need
> for registration (as well as the possibilities for registration) more
> limited.

All of this is true.

The words "generative" and "generated" were central to what I wrote.
Frank had written:

> For existing RfC 3066 software en-Latn-US is gibberish.

It was clear to me that he was talking about generative tags, not about
the possibility of registering "en-Latn-US".  Speaking only for myself,
I'm not concerned about maintaining compatibility with parsers that
couldn't handle "en-Latn-US" even if it were registered.

-Doug Ewell
 Fullerton, California

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 25 Mar 2005 09:30:53 +0100

Doug Ewell wrote:

 [huge files]
> I'm not sure why that should be a problem.

The IETF has a collection of I-Ds somewhere, it crashed my old
browser.  That's only a problem with *huge* (X)HTML files.  If
somebody wants to know what "yec" is in 3066ter it could be a
pain to download the complete registry.

> You can now buy a 512 MB JumpDrive for 40 USD, or a 200 GB
> hard drive for 100 USD

I'm not planning to buy a new hard drive only to read a IANA
registry with language tags ;-)  I trust that IANA will split
it when necessary on its Web pages, and as you said it's no
problem for a 3066bis without the future ISO 639-3 languages.

                      Bye, Frank

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Fri, 25 Mar 2005 07:16:14 -0500

> problem for a 3066bis without the future ISO 639-3 languages.

I wouldn't trust IANA to do anything without explicit instructions.
Potential structural issues (and recommendations to address them) would be
best described in an "IANA Considerations" section.

-Scott-

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 25 Mar 2005 13:58:00 +0100

Doug,
I extensively use my footer to evangelize about this WG's work (it informs 
people and leave them free to make their mind). I would appreciate (as well 
as anyone else maintaining a file on line of relevance to this work) to 
give the exact wording they wish I add for their file.

>the other sections in similar fashion, perhaps this weekend.)

Could you please make it a clean part that we could include in our Draft?

>dealing with multiple files and keeping them synchronized would be a

The problem as usual is the usage made of it, and the load imposed on IANA 
and private mirrors. I will take an example for you to understand people's 
behavior. There is a small DNS resolver for end users which has no 
permanent cache (its starts when you power-up). The first thing it does 
when you want to use an URL is to call _all_ the root servers (13 calls), 
while average usage may result in one call over may be tens of thousands of 
calls. If for any reason someone finds useful or funny or money making to 
call the file it will result huge traffic and CPU load.

Another point we try to consider is the developing countries and islands 
problems. ADSL US or European or Korean traffic costs nothing. But 600,0000 
at real 500 characters per second or less is 1200 seconds. When you know 
that in some countries one hour of internet equals one day work salary, you 
see the digital divide this represents for some of the really most involved 
searchers.

The real issue is the CRCD (context reference compact disk). This is the CD 
any ISP, Gov, Telco, will have to produce to include all these information 
everyone needs and which are so costly sold by ISO, ITU, terminology, 
programs, standardization organization or not distributed by searchers 
however funded by Gov or Intl budget. And the format/program to get it out 
the CRCD towards real life applications (mail, browsers, blogs, firewalls, 
etc.) trough appropriate OPES.

We try to find money to sponsor a "data in the air" program. All over the 
world Teletex broadcasts 600 bps per second on TV. Some are extensively 
used, some are not. This means that a free daily datajournal of 3 Meg 
maximum is available to everyone (with FEC and with cycles for vital 
information updates - warnings, available beds in hospitals, missing 
children, catastrophe maps [TV is usually the first media which is restored 
and its foot path is better than mobiles and wi-fi], etc. etc.). In this we 
think we could broadcast daily updated news and weekly information. We 
cannot reasonably do a longer cycle, even with small solar batteries, due 
to the possible failures.This means the we can reasonably think of a 10 Meg 
"disk in the air" system (a DIA system can cost as low as $ 200, with a few 
USB ports).

Permitting people to exchange in different languages over real time 
information is of the essence for international assistance for example. So 
languages, terminology, etc. are an important elements. But at the same 
time we need to qualify that information, to keep it as dense as possible, 
to "culturalize it" to that end (because a DoS costs too much - and this is 
why IP is not a proper vehicle, and IPSec is costly). This is where you 
find that ISO 3166 is of importance but it does not address the diaspora, 
the immigration, de cultural, the corporate, the reader/viewers classes, 
etc. This is where you understand that Governments on_the_network are also 
perceived through their e-regalian embodiment of services - and possible 
interference with CRCs.

FYI our DIA effort will be dedicated to IEMS a small team of a WU shop who 
had started an inter-mail systems bridge. Mexico City known a big earth 
break and for hours all the international assistance coordination went 
though one of their customer's mail system to their ITT mailbox. No one 
really praised them, but many lifes and sufferances were spared that day 
because of their small async 300 bps service.

jfc

======================================================
Standardizing Tags for the Identification of Languages should not be a way
to standardize languages and to unify the world under a dominant culture.
======================================================
For your convenience:
RFC 3066: http://www.ietf.org/rfc/rfc3066.txt?number=3066
Draft: 	http://www.ietf.org/internet-drafts/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.
======================================================