Last Call: language root file system

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-04.txt

The proposed RFC 3066 bis Draft under current review actually creates a "LTS" (language tag system) having similarities with the old Host.txt system.

It is made of:
- a standard track description calling for tag resolution libraries like http://www-306.ibm.com/software/globalization/icu/index.jsp .
- a registry, managed by ietf-languages@xxxxxxxxxxxxx
- a root file: its initial version is given by the Draft above (under LC) to be hosted by the IANA servers.

The terse Draft version of the "langroot" is of 80,430 chars (for information the current size of the DNS root is 63,858 today). Zipped it is 11.413 chars while the DNS root is 17.320. The DNS root is updated around 60 times a year. It is likely that the langroot is currently similarly updated with new langtags. These files are therefore today of equivalent magnitude.

However, there will be a sharp increase next year when all the ISO 639-3 language codes are added, if ISO accepts it, as its authors thinks, by the end of the year. We will have an increase from 500 languages to 7450. When ISO 639-6 is accepted further on, there will be 20.000 languages subtags more. Then we may have additional regional tags (for example ISO 3166-2, E.164, X.121 or UN-zones, etc.) which may multiply the size by two or three.

The need for the users to obtain an updated langroot information is equivalent to the DNS root (see below) with the following differences: - there is no intermediary service like ISP nameservers: the users will directly call the langroot servers (hence my comparison with host.txt)
- there is to date no cache solution, nor TTL considered yet.
- the number of calls to the registry data (not necessarily to the langroot server) by the users is superior to the DNS. The DNS supports less than 50% of the Internet calls. The langtag resolution will be needed for every HTML, XML, email page being read.

There is no possibility to know how developers will address the langtag resolution need. But the foreseen evolution of the IANA registry and the needs of the market plead in favor of an XML or an ASN.1 solution. The clearing-house related architecture is not clear at this stage, as the proposed Draft does not discuss this point. This is left to the IANA (hence my interest to know about the exact timing). The draught-back is that if a versatile and fast solution is available programers will tend to use it real time. This means a system comparable to the DNS root, with a root file which may be 40 to 50 times larger, called upon 100 to 500 times more often (I know that 97.5% of the DNS root calls are illegitimate, that the langroot will not have the same historic and will take time to grow, what will certainly drastically initially reduce that last figure; but on the long range this figure stands).

The problems are the analysis of this system (its real need, its alternative, its architecture), of its cost. Today the IANA servers are not used in real time dynamic operations. Even if the user cache their 12.000 to 600.000 k zip file when they boot, or accept an update every week or month, we are in the logic of an anti-virus update. The IANA system can certainly support it in using an AKAMAI like solution, but we are entering a commercial approach. Is that what we want?

The proposition I made is to use IETF Drafts. This means that the current Draft would be made a permanent solution, with a Draft updated every month (this would probably provide a shorter delay than the IANA and stay under the full control of a dedicated IETF WG). The Internet community is used to rely on the RFC Editor, no one accesses it real time, and the new ISOC/IASA organisation provides a reliable and trusted structure. It would mean that updates would be provided once a month, possibly in a diff way or rsync to ISP and from ISP to users.

This also means that the "Draft as a default not as an exclusive" solution I propose, will permit a simple integration of specialised schemes: in addition or instead of using the Monthly WG Draft data, the libraries will use the data from the scheme they want to use. This approach is no cost, off the shelves, proven, immediate, and no conflict as totally open and distributed.

NB: a comment could be that the IANA could provide a simple ASCII jar file, some other service could distribute (like in my proposition). This is what we can actually expect. If my "Draft as a default not as an exclusive" proposition was not accepted, it would mean that this other service would be de facto market exclusive of the exclusive file. It would then probably be financed in selling related services and informations: this would build a commercial core for the Multilingual Internet.

jfc


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]