Re: lynx-dev dotless IP-address in URLs

[pg]

In a recent note, address@hidden said:

> Date: Mon, 23 Aug 1999 11:30:16 -0700 (PDT)
> >
> >They are illegal URLs used for illegal purposes - I see no reason at
> >all why Lynx should support them.
> 
> I was the previous person who asked about this subject, likely within
> the last year.
> 
> I fully agree that I've only ever seen them in spam.  However why are
> they "illegal" URLs?  Is it specifically said that they are not supported?
> 
> Since nslookup supports that format fine, and that format is given as
> one of the proper methods for showing an IP address, I'm just curious about
> how this is 'illegal', since I'd _expect_ (as in I have no proof) the URL 
> standard to say something along the lines of:
> 
> one valid format of an http URL is:
> 
> http://IP#/blah.html
> 
> where "IP#" is any form of describing an IP address as described in RFC XYZ.
> 
It says something quite the contrary.  From:

   Linkname: (RFC 1738)
        URL: http://www.w3.org/Addressing/rfc1738.txt

3.1. Common Internet Scheme Syntax

        //<user>:<password>@<host>:<port>/<url-path>

    host
        The fully qualified domain name of a network host, or its IP
        address as a set of four decimal digit groups separated by
        ".". Fully qualified domain names take the form as described
        in Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123
        [5]: a sequence of domain labels separated by ".", each domain
        label starting and ending with an alphanumerical character and
        possibly also containing "-" characters. The rightmost domain
        label will never start with a digit, though, which
        syntactically distinguishes all domain names from the IP
        addresses. 

Note that this also disallows not only dotless IP addresses, but the 
common practice of using locally only the lowest level qualifier of a
domain name and trusting the resolver to deal with it.  And while
some RFCs (1123?) may describe more general "host" formats, RFC 1738
here disallows them explicitly.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL