Re: [idn] Report from the ACE design team

[Paul Hoffman / IMC <phoffman@imc.org>]

At 10:20 AM -0400 6/27/01, Marc Blanchet wrote:
>At/À 20:18 2001-06-26 -0700, Kenneth Whistler you wrote/vous écriviez:
>>Soobok Lee wrote:
>>
>>>  I believe long natural sentence/phrase domains escape your arguments.
>>>
>>>  In CJK, "What is the nearest macdonald hamberger shop from 
>>>here?".(kr|cn|jp|tw)
>>
>>??
>>
>>Why would someone want to type in:
>>
>>"konomawariniwaichibanchikaimakudonarudohambaaganomisewadokodeshooka.co.jp"
>
>
>Sorry Ken, but your argument of long-names-will-not-be-used does not 
>stand. In the .com zone file, there is _already_ some labels which 
>are 63 characters long.

There is a difference between novelty names and names that will 
really be used. Your point about 63-character names is an excellent 
example of this. All names that are 63 characters (and probably all 
names longer than 30 characters) are probably for novelty use. If 127 
characters were allowed, someone would surely register them as well. 
Why don't we change the DNS to handle these as well?

So far, the only argument that has been brought up for Han names >15 
characters is that some companies would want to have a registration 
for their official names, but they would probably use a shorter, 
easier-to-use name in daily use. The proposals to use more difficult 
ACEs to accomodate companies (and probably some people) to put their 
whole name in a single name part ignore two important points:

- Regardless of the ACE we chose, some companies will not be able to 
encode their whole name in a single name part. We have to draw the 
line somewhere, and someone will always be aggrieved.

- All of the companies in question could easily encode their name in 
two adjacent name parts. Thus, no one is prevented from registering 
their full name.

As for the people who say "there are many sentences that won't fit 
into the ACE encoding", that is certainly true. It is just as true 
for the current 63-octet limit in ASCII. Sentences are not names, and 
we should ignore them when trying to come up with a good encoding 
scheme for names.

--Paul Hoffman, Director
--Internet Mail Consortium