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

Erik van der Poel erikv at google.com
Sun Mar 8 04:01:54 CET 2009


I just tried an HTML file containing <a
href=http://0x40AA6220>link</a> in the browsers below (current
vintage, not 1995), on Windows XP, and watched the packets with
Ethereal, looking at the HTTP portion of the packet:

MSIE7 says "Host: 64.170.98.32"
Firefox3 says "Host: 0x40aa6220"
Chrome1 says "Host: 64.170.98.32"
Safari4 can't find the server "0x40aa6220"
Opera9 can't find the server "0x40aa6220"

Note that MSIE, Firefox and Chrome are the only ones that actually
connect to the www.ietf.org Web site in this test. Amusingly, Firefox
lower-cases the hex IP address before putting it into the Host:
header.

The apps that interpret IP addresses in this way also accept octal
(starting with 0) and decimal (starting with 1..9), and they do
interesting things with IP addresses that only have one or two dots:

http://www.opengroup.org/onlinepubs/007908799/xns/inet_addr.html

Note that this has nothing to do with DNS. It's just IPv4 and HTTP.

Erik

On Sat, Mar 7, 2009 at 5:38 PM, 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 -
>
> - Lyman
>
> On Mar 7, 2009, at 7:35 PM, John C Klensin wrote:
>
>>
>>
>> --On Saturday, March 07, 2009 11:01 -0500 Lyman Chapin
>> <lyman at acm.org> wrote:
>>
>>> Martin and Andrew,
>>>
>>> Although it seems that numeric values above 255 would be safe,
>>> some   software looks only at the low-order 8 bits of a number
>>> encoded in a   16-bit (for example) field (ignoring any
>>> high-order bits) when it   "knows" that a numeric value will
>>> always be 255 or less. In that case   only the 8 low-order
>>> bits (10011010) of 666 (...01010011010) would be   recognized.
>>> Entering "666" into such an interface would be equivalent   to
>>> entering "154".
>>
>> Lyman,
>>
>> I'm completely confused and don't know what you are talking
>> about.  If the issue is domain names, expressed the preferred
>> syntax of dot-separated ASCII characters, "666" is as good as
>> "ABC" or "ACM".  If the issue is numeric values, the DNS spec
>> understand only octets and not, e.g., 16 (UTF-16?) or 32
>> (UTF-32/UCS-4) data fields.  The last I looked, it was quite
>> hard to fit a decimal number larger than 255 into an octet.
>>
>> So, what are you saying?
>>
>>     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