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

Bill Manning <bmanning@ISI.EDU> Mon, 30 June 2008 02:46 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 9BBF63A691D; Sun, 29 Jun 2008 19:46:42 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id DCCFE3A691D for <>; Sun, 29 Jun 2008 19:46:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hEf0LDyN+FUg for <>; Sun, 29 Jun 2008 19:46:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5B4723A6864 for <>; Sun, 29 Jun 2008 19:46:40 -0700 (PDT)
Received: from (localhost []) by (8.13.8/8.13.8) with ESMTP id m5U2kF11009984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 29 Jun 2008 19:46:16 -0700 (PDT)
Received: (from bmanning@localhost) by (8.13.8/8.13.8/Submit) id m5U2kF2i009983; Sun, 29 Jun 2008 19:46:15 -0700 (PDT)
Date: Sun, 29 Jun 2008 19:46:15 -0700
From: Bill Manning <bmanning@ISI.EDU>
To: David Conrad <>
Subject: Re: Update of RFC 2606 based on the recent ICANN changes ?
Message-ID: <>
References: <> <> <> <> <> <> <> <>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/
X-ISI-4-43-8-MailScanner: Found to be clean
Cc: SM <>, IETF Discussion <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

> I'm suggesting it would be helpful if there were an RFC directing IANA  
> to establish a registry that contains both labels and rules (e.g, no  
> all-numeric strings, no strings that start with 0x and contain  
> hexadecimal values, the string 'xn--', the 2606 strings, etc.) that  
> specify what cannot be placed into the root zone.  As part of future  
> IANA actions, any time a protocol defines a new TLD (e.g., .local) an  
> entry should be placed into that registry.
> Would there be the downside to this?

	several come to mind...

	heres one.  wrt numeric strings, you have examples of the ambiguity
	in implementations on -how- to process non-base 10 numbers.  but
	it is clear that hex encoding is -not- tossed out.  how 'bout octal?
	or base 36?  are numeric string representations now, after 30 years
	going to be outlawed? if so, on what basis?

	creating a useful RFC that creates a registry and maintains it in a timely
	fashion -in this century- seems a bedtime fable.


Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

Ietf mailing list