Re: [idn] Document Status?

["JFC (Jefsey) Morfin" <jefsey@jefsey.com>]

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 
to help.
jfc