draft-liman-tld-names-00.txt and bidi

Vint Cerf vint at google.com
Sun Mar 8 13:36:11 CET 2009

Thanks for that reminder, Alireza - it is important to remember that  
WWW is not the only application on the Internet.

It seems to me that IDNA is properly bound to DNS lookups and  
registrations.  The purpose is to deal with matching of input to  
existing registrations.
The display function is a very different and potentially idiosyncratic  
thing. One way to interpret your suggestion is to consider an IDN  
display system but it seems to me that this is quite distinct from the  
problem IDNA is trying to solve (what can be an IDN and how do I  
register it and look it up?)


Vint Cerf
1818 Library Street, Suite 400
Reston, VA 20190
vint at google.com

On Mar 8, 2009, at 5:43 AM, Alireza Saleh wrote:

> Hi,
> Just  would like to mention  that IDNA is not about HTTP, there are  
> many other protocols that deserve IDN.  I think that finding a  
> global solution that can satisfy all protocol clients is impossible  
> and the group should expect some backward incompatible issues
> from the clients as we accepted some of them  within the protocol  
> itself.
> I think one of the options would be making IDNA act only as a  
> validation tool  which decides whether the entered label should be  
> displayed in U-label or A-label. this validation can be done both at  
> look up and registration level.
> Maybe, the resolver can report the client about the successful/ 
> unsuccessful IDNA checks , this can be done by something like 'ad'  
> flag in DNSSEC.
> Alireza
> John C Klensin wrote:
>> --On Saturday, March 07, 2009 20:38 -0500 Lyman Chapin
>> <lyman at acm.org> wrote:
>>> John,
>>> If you type "http://320.170.98.32" into an old version of
>>> Internet Explorer (if I remember correctly, Windows 95
>>> vintage), you'll get to the main IETF web page as surely as if
>>> you had typed "" (or "http://www.ietf.org"
>>> for that matter). This is just an artifact of the way in which
>>> software interfaces interpret what users enter, not an
>>> observation about the DNS or the encoding of data fields -
>> Well, exactly.  I'd go a step further and suggest that it
>> illustrates one of  the problem that can occur when software
>> interprets something as an address that couldn't possibly be an
>> address and then tries to treat it that way.  And that is an
>> example why I'm opposed to any model that would consider "666"
>> as a valid TLD because it couldn't possibly be an element of an
>> IPv4 address.  If something construes it as "an address" because
>> it is numeric, two separate bad things happen: (1) It will
>> either be rejected completely because the code finds out that it
>> isn't a valid address, or the code will start truncating,
>> dropping bits, or doing modular arithmetic to treat it as an
>> address, possibly resulting in an unintentional and false hit.
>> And (2) it will never be looked up as a domain name in spite of
>> the fact that it cannot be an address.
>> It is not, in any event, a DNS problem, although ICANN could
>> certain make it one.
>>    john
>> _______________________________________________
>> Idna-update mailing list
>> Idna-update at alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/idna-update

More information about the Idna-update mailing list