Message-Id: <6.1.2.0.2.20050325113421.02838710@mail.jefsey.com>
Date: Fri, 25 Mar 2005 13:58:00 +0100
To: "Doug Ewell" <dewell@adelphia.net>,
	"LTRU Working Group" <ltru@ietf.org>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Subject: Re: [Ltru] Re: Registry in record-jar format
In-Reply-To: <009701c53103$6c2eda80$030aa8c0@DEWELL>
References: <20050323071700.BRCV2128.mta1.adelphia.net@megatron.ietf.org>
	<009701c53103$6c2eda80$030aa8c0@DEWELL>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: 
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

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.

At 07:25 /03/2005, Doug E well wrote:
>(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.)

Could you please make it a clean part that we could include in our Draft?

> > 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.

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.
======================================================


_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru