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
Vint Cerf
Google
1818 Library Street, Suite 400
Reston, VA 20190
202-370-5637
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 "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
>>
>
More information about the Idna-update
mailing list