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

[Alireza Saleh]

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 "http://64.170.98.32" (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
>