IETF Logo Mail Archive

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

Mark Andrews <Mark_Andrews@isc.org> Tue, 08 July 2008 05:27 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F10B33A695D; Mon, 7 Jul 2008 22:27:03 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80B7F3A6939 for <ietf@core3.amsl.com>; Mon, 7 Jul 2008 22:27:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.609
X-Spam-Level:
X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUTrWP96Jvfi for <ietf@core3.amsl.com>; Mon, 7 Jul 2008 22:27:01 -0700 (PDT)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) by core3.amsl.com (Postfix) with ESMTP id 4D7F43A68B4 for <ietf@ietf.org>; Mon, 7 Jul 2008 22:27:00 -0700 (PDT)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m685R38n020660; Tue, 8 Jul 2008 15:27:03 +1000 (EST) (envelope-from marka@drugs.dv.isc.org)
Message-Id: <200807080527.m685R38n020660@drugs.dv.isc.org>
To: John C Klensin <john-ietf@jck.com>
From: Mark Andrews <Mark_Andrews@isc.org>
Subject: Re: Update of RFC 2606 based on the recent ICANN changes ?
In-reply-to: Your message of "Tue, 08 Jul 2008 00:35:05 -0400." <7313F090683A8F0E554905CF@p3.JCK.COM>
Date: Tue, 08 Jul 2008 15:27:03 +1000
Cc: Theodore Tso <tytso@MIT.EDU>, Ted Faber <faber@ISI.EDU>, moore@network-heretics.com, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> 
> 
> --On Tuesday, 08 July, 2008 11:47 +1000 Mark Andrews
> <Mark_Andrews@isc.org> wrote:
> 
> > 
> >> The site-dependent interpretation of the name is determined
> >> not by the presence of dot within the name but its absence
> >> from the end.
> > 
> > 	No.  Please go and re-read RFC 921.
> 
> This is the same RFC 921 that 
> 	
> 	* is listed in the RFC Index as "Status: UNKNOWN"

	Unknown doesn't mean irrelevent.
 
> 	* was not even examined in the "requirements" review
> 	that led up to RFC 1123 and is not referenced there.

	RFC 1123 -> RFC 952 -> RFC 921
 	
> 	* primarily talks about an implementation schedule and
> 	transition plan, not about long-term stable
> 	interpretations.

	
> Isn't claiming that as an authority in 2008 a bit of a stretch?

	No.  Old does not mean irrelevent.

> Especially since, as Ted Farber points out, text in 1035 itself
> seems to contradict your reading of that particular section?

	No.  RFC 1035 applies to domain names, not hostnames.
	
> I believe that 952 is almost equally irrelevant wrt this
> argument. YMMD, of course.

	RFC 952 is the latest rfc which defines the syntax of a
	hostname.

> As Keith points out, there are lots and lots of reasons to avoid
> believing that dot-less strings will be interpreted as domain
> names consistently and in the way that users will expect.  Most
> of them have to do with handling of names in applications, which
> tends to get strange in edge cases and stranger when one relies
> too much on having specific contents in resolver configuration
> files.  The mere fact of inconsistent (but valid)
> interpretations in different applications or configurations (or
> even implementations of the same 
> application) may be more than enough reason to avoid these
> things, or at least be very careful about them.  But claiming
> 921 as an authority isn't one of the reasons, IMO.
> 
>      john
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

v2.23.0 | Report a Bug | By Email