A-label definition

[Frank Ellermann]

Mark Andrews wrote:

> If you have a host called 0x7f.0x01.example.com and
> a search list containg example.com the when someone
> attempts to telnet to 0x7f.0x01 it won't go to the
> address in the A record associated with 
> 0x7f.0x01.example.com.  It will instead connect to 
> 127.0.0.1.

Testing this...
telnet 0xD0.0x4D.0xBC.0xA6 80<crlf>
GET / HTTP/1.0<crlf>
<crlf>
<crlf>

Odd, it works, as *not* expected by me.  Also with
Firefox 2 and <http://0xD0.0x4D.0xBC.0xA6/>  
They have no ftp or smtp, but http.  No idea what
it is good for, it could be a joke or a mistake.  

> addr = inet_addr(argv[1]);
> if (addr != INADDR_NONE) {
> r = connect();
> } else {
> he = gethostbyname(argv[1]);

If folks want to support IPv4 given in odd (or old)
formats it is what they want.  But I think a popular 
browser, which won't let me use gopher on interesting
ports claiming that "whois" or "daytime" are insecure, 
could be more restrictive with strange IPv4 formats.
  
> gethostbyname() itself may do a similar thing.

Apparently not, my snippet used a REXX API on top of 
an ordinary library, it didn't return 127.0.0.1 for
the hex. format.

> YMMV  but you need to be aware of what applications
> on various platforms accept as valid IP addreses and
> steer clear of using anything which could be 
> potentially confusing.

Staying as far as possible away from trouble is good,
but I don't consider the Firefox behaviour as feature.
For purposes such as SURBL it could be annoying.  And
it is AFAIK not specified in any RFC.

> 067 was treated as 67 not 55.

Only hardcore C-fans can consider this as a bug... :-)

We should not put idiosyncrasies of specific languages
into an RFC.  Look at say RFC 2821, there is no chance
to get it wrong, it uses an unambiguous format, and if
an application thinks that 067 is 55 it is broken.

All discussed <top-label> variants forbid "digit only",
that also covers "octal" <top-label>s.  For the hex.
pitfall we could decree MUST NOT  "0x" 1*HEXDIG  This
case is anyway already mentioned in an ICANN proposal.

 Frank