Re: Update of RFC 2606 based on the recent ICANN changes ?

Ted Faber <faber@ISI.EDU> Tue, 08 July 2008 16:14 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id DDD5D3A6A22; Tue, 8 Jul 2008 09:14:23 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 741A73A6810 for <>; Tue, 8 Jul 2008 09:14:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.356
X-Spam-Status: No, score=-3.356 tagged_above=-999 required=5 tests=[AWL=1.243, BAYES_00=-2.599, GB_I_LETTER=-2]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qsS6GBRZJvhA for <>; Tue, 8 Jul 2008 09:14:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6DDFF3A6A61 for <>; Tue, 8 Jul 2008 09:14:21 -0700 (PDT)
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id m68GDZLj009251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Jul 2008 09:13:36 -0700 (PDT)
Received: (from faber@localhost) by (8.14.2/8.14.2/Submit) id m68GDZ5r030828; Tue, 8 Jul 2008 09:13:35 -0700 (PDT) (envelope-from faber)
Date: Tue, 8 Jul 2008 09:13:35 -0700
From: Ted Faber <faber@ISI.EDU>
To: Mark Andrews <>
Subject: Re: Update of RFC 2606 based on the recent ICANN changes ?
Message-ID: <>
References: <> <>
Mime-Version: 1.0
In-Reply-To: <>
User-Agent: Mutt/
X-ISI-4-43-8-MailScanner: Found to be clean
Cc: Theodore Tso <tytso@MIT.EDU>,,
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: multipart/mixed; boundary="===============2040654311=="

On Tue, Jul 08, 2008 at 12:54:16PM +1000, Mark Andrews wrote:
> 	"hk." is not a syntactically valid hostname (RFC 952).
> 	"hk." is not a syntactically valid mail domain.
> 	Periods at the end are not legal.
> 	RFC 1035 has *nothing* to do with defining what is legal
> 	as a hostname.

Fair enough. 

By RFC952 standards "hk" is a perfectly fine hostname.

By RFC1035 standards, if you look it or any other DNS name up using the
DNS resolver, that resolver will treat the name as relative unless it
ends with a dot.   Arguing that hk is an unreliable hostname if you
look it up as a relative pathname is pretty much the same as arguing
that is an unreliable hostname.  Both of them are
subject to the search path without that trailing dot.

So far, the only distinction between the two is that hk is short.

I understand the assumption that getting a collision in the search path
with a 2-letter name is higher than getting one with a 20-letter name.
I believe that the 2-letter collisions are no harder to avoid in
principle than the 20-letter ones, and no harder to create should an
admin want to do so (e.g., to create local aliases).  I think you
believe that search path collisions for short names are inherently
harder to avoid (and might rule out using the trailing dot notation in
applications to avoid them).

Is that basically what we disagree about?

Ted Faber           PGP:
Unexpected attachment on this mail? See
Ietf mailing list