[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] Document Status?
On 14:53 01/09/02, vinton g. cerf said:
One working definition of internationalization is that the
encoding/expression is "understood" by speakers of all languages. There is
global agreement, I believe, that block Latin characters can be used by
anyone in any country to express the name of a destination country in a
postal address. So for example "UNITED STATES" or "FRANCE" or "AUSTRALIA",
"JAPAN", "VIETNAM" are all considered acceptable in every country. This
agreement allows, for example, that the destination address, except for
the name of the country, can be rendered in a language local to the target
country and does not have to be understood by the postal service in the
originating country. Consequently, someone sending a letter from the US to
a recipient in Vietnam can write the destination address in Vietnamese and
the US postal service need only understand the characters "VIETNAM" at the
bottom of the destination address.
Absolutely correct. This is what is used as a default international set by
common sense, postal agreements and EDI. You may note that this is also
the way international mnemonics work (JFK, CDG, LAX, ... and ISO 3166 2/3
letters we use in ccTLDs, or as X.121 DNICs or telephone numbers, etc.).
They usually are organized in a way O, I, 0 and 1 cannot be confused. As
you note it, they are often used in printed uppercases.
This means that we are using a 28 character set (0-9, A Z, dot and dash).
In adding column, slash, comma/crosshatch and star we may have a 32 touch
pad for future telephone sets?
That reasoning in line with EDI, common language, etc. makes the current
domain names the international default.
Multilingualization is more focused on what is sometimes called
"localization" - that is, the characters used in rendering a local
language can be used (e.g. for domain names or for filling out forms etc)
and these renderings need not be universally understood.
Absolutely correct. The "local" wording - which may differ with different
dialects or ways of writing - can also be used with that mechanic to
consistently fill forms. The same namepreparation used in IDNA will most
probably be used for brainware consistency everywhere: we cannot start
learning and using different schemes when entering a domain name in an URL
and in a database field, then why to use a library for a field and a
different one for the next one. This RFC specifies an universal "internet
name" multiingualization stable mechanism with most probably a lo of
variations in their massaging.
This definitional distinction helps (me anyway) to appreciate that the
creation of multilingual domain names may not necessarily contribute to
universal ability to use the resulting strings because it may be difficult
to impossible to render or enter arbitrary character sets at the user
interface to a local service. We have collectively probably created some
confusion for ourselves by using the term "internationalized domain names"
to cover both concepts. It strikes me that the IDNA documents are more
aimed at localization/multilingualization than internationalization, using
the "definition" in the first paragraph above.
This is why we should correct the wording now, while we still can do it.
The idea of a universal open solution should be appealing enough to help
people understand this more global approach. It would also be a good
occasion to clean a complex commercial and political situation, permitting
to simplify the implementation process in having a broader support?
We could say that a "multilingual internet name is a multi label string
which can be internationalized into an ASCII label string and
remultilingualized into a local string of commonly accepted identical
meaning by the concerned linguists, IP jurisprudence etc...". Because
languages change and have dialects. Only the International transcoding is
our only stability: the more people use it in their own applications, the
broader are our chances that it becomes a consensus. This is what we have