Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications

Paul Vixie <paul@vix.com> Thu, 20 October 2005 16:12 UTC

From: Paul Vixie <paul@vix.com>
Subject: Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications
Date: Thu, 20 Oct 2005 16:12:01 +0000
Lines: 46
References: <200510201117.j9KBHYb6033105@drugs.dv.isc.org> <500955810D4CE03A82D7FC9C@svartdal.hjemme.alvestrand.no> <a06200701bf7d3958f4b4@[192.168.1.101]> <72E3B614EE413656376A863B@svartdal.hjemme.alvestrand.no> <20051020141307.99E4A11426@sa.vix.com> <209FCC95A2DF6AF7E4B6CF5F@svartdal.hjemme.alvestrand.no>
X-From: owner-namedroppers@ops.ietf.org Thu Oct 20 18:18:41 2005
Return-path: <owner-namedroppers@ops.ietf.org>
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0
To: namedroppers@ops.ietf.org
In-Reply-To: Your message of "Thu, 20 Oct 2005 17:04:31 +0200." <209FCC95A2DF6AF7E4B6CF5F@svartdal.hjemme.alvestrand.no>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
X-Message-ID:
Message-ID: <20140418072057.2560.1854.ARCHIVE@ietfa.amsl.com>

# > when did the ietf community start ruling by law rather than leading by
# > recommendations?  can't we just say "any application or library which
# > does DNS lookups to translate presentation-layer endpoint identifiers
# > into network-layer endpoint identifiers should take care to avoid doing
# > DNS lookups for presentation-layer content which is syntactically valid
# > as an IPv4 or IPv6 host name"?
# 
# Except that we've now created a class of names that are OK to register, and
# OK to populate in the DNS, but some applications will never be able to look
# up.... that's kind of bizarre.

then make a recommendation that IANA not allocate such names as toplevels?

(what people choose to do further down the tree is not up to us to decide.)

# I think the "don't register numeric TLDs" is a recommendation too, in the
# sense that everything the IETF produces for external consumption is. And a
# simpler one.

right.

# > (that's from bind4's gethnamaddr.c file, similar stuff is in bind8/bind9.)
# 
# entirely tangential, but illustrates something, I think....
# 
# this line of code is mostly responsible for the widely held but erroneous
# belief that hta@129.241.1.99 is a valid email address.

worse than that: it's valid for some people some of the time.  the logic in
gethostbyname() was put there because applications could not be depended upon
to say "if it's a valid address, use it, else look it up as a hostname" and
so gethostbyname() became a dual-purpose function.  probably it would've been
better to return an error on the basis of non-RFC952-compliance.  (who knew?)

# hta@[129.241.1.99] is a valid email address. hta@129.241.1.99 isn't.
# Some mailers get it right, some don't.

really?  i know that mailnames used to have to start with non-numeric, but
3com.com asked for a change and got it.  do the current (2821/2822) railroad
diagrams really say that 129.241.1.99 is not a valid mailname?

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>