At 18:11 27/08/2005, David Hopwood wrote:
JFC (Jefsey) Morfin wrote:
[...] The DNS root is updated around 60 times a year. It is likely that the
langroot is currently similarly updated with new langtags.
No, that isn't likely at all.
Dear David,
your opposition is perfectly receivable. But it should be documented.
The order of magnitude is the same. I did not note the number of
entries in the IANA file during the last months. This is something
that I will certainly maintain if the registry stabilises. But in the
last months there have been more than six and far less than six
hundred. May be will you work out a list of the registrations to
prove me wrong?
The langtag resolution will be needed for every HTML, XML, email
page being read.
Patent nonsense. In practice the list will be hardcoded into software that
needs it, and will be updated when the software is updated.
Then? the langtag resolution is the translation of the langtag into a
machine understandable information. It will happen every time a
langtag is read, the same as domain name resolution is needed
everytime an URL is called.
This is perfectly sufficient. After all, font or character encoding
support for new scripts and
languages (e.g. support for Unicode version updates) has to be handled in the
same way.
I am afraid you confuse the process and the update of the necessary
information. And you propose in part the solution I propose :-) .
The problem however is not to propose but to survive the users
inadequate usage. If you have been around for some times in
networking you know what I mean.
Languages, scripts, countries, etc. are not domains.
The DNS root tend to be much more stable. What count is not the
number of changes, but their frequency.
- there is no difference between ccTLDs and country codes. We
probably can say that there is one change a year. At least.
- scripts. ISO 15924 currently used supports 100 scripts, real life
is more than 200 stabilised from what I gather.
- languages are 500 in ISO 639-2, 7500 in ISO 639-3 and 20.000 in ISO 639-6
The purpose of the IANA registry is to permit to adapt to reality
(missing languages) and to transition towards ISO new tables. When
you consider that the langtags are supposedly multimode and currently
only support scripts, this means a steady need to adapt to
multimedia. You should probably contact the BSI people to get more
information on language analysis (I suggest you consider the
preparatory work of ISO 639-4, the lack of definition of a language,
a text, a script in a network context, lead to think, ISO will
eventually come with much more flexibility).
Considering 50 to 200 updates a years seems very conservative -
independently from the big structural changes of new ISO codes or the
support of new tables - and completely live aside the
variant/extension issue - whatever the way it will be addressed in
the further planned Drafts.
Now, if there are updates, this means there are needs to use them,
now - not in some years time. Same considerations as other processes.
In a global system new releases are not localised. So either you have
to update one billion softwares or one billion users.
BTW, your position tend to say that one do not need the root server
system. What is an interesting idea.
jfc
PS. The problem is: one way or another one billion users, with
various systems and appliances must get a reasonably maintained
related information which today weight 15 K and is going to grow to
600 K at some future date, with a change from every week to every day
(IMHO much more as people start mastering and adapting a tool
currently not much adapted to cross lingual exchanges). From a single
source (in exclusive case) or from hundreds of specialised sources in
an open approach. This should not be multiplied by all the languages
that will progressively want to support langtags, but will multiply
the need by two or three.For example an Ukrainian will want langtags
in Ukrainian, in Latin and Cyrillic scripts and in most of the case
in ASCII English, probably in Russian, etc. With the variants. etc.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf