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
