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

[Keith Moore <moore at network-heretics.com>]

> > > It's nonsensical for an application to decide that relative names are 
> > > unacceptable, but to require users to input names as relative.
> >
> > it's nonsensical for you to unilaterally declare that such names are 
> > relative, when well over two decades of practice indicates otherwise.
>
> I didn't declare it; 1034 did. 

Yes - but you're the one declaring that 1034 trumps decades of later 
work.  Normally the assumption would be that work can be revised as bugs 
are found or conditions change over time, and that things that had 
achieved IETF consensus since 1034 was published would be considered at 
least equal, and often superior, to earlier work.

I don't think 1034 was handed down from a mountain on stone tablets.

I believe it always was inevitable that different apps would use DNS (or 
any shared naming facility) in slightly different ways.  Yes this is 
somewhat confusing, but DNS (like the rest of the Internet) has been 
stretched far beyond its original design goals or scale.  For instance, 
we don't interpret DNS names as hostnames any more - because in the 
modern world the concept of "host name" is irrelevant in the vast 
majority of cFrom ietf-bounces at ietf.org  Tue Jul  8 13:50:04 2008
Return-Path: <ietf-bounces at ietf.org>
X-Original-To: ietf-archive at megatron.ietf.org
Delivered-To: ietfarch-ietf-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id E1F6228C31B;
	Tue,  8 Jul 2008 13:50:03 -0700 (PDT)
X-Original-To: ietf at core3.amsl.com
Delivered-To: ietf at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id BCAB928C31B
	for <ietf at core3.amsl.com>; Tue,  8 Jul 2008 13:50:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.724
X-Spam-Level: 
X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5
	tests=[AWL=-0.125, 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 lawkk9iz53el for <ietf at core3.amsl.com>;
	Tue,  8 Jul 2008 13:50:02 -0700 (PDT)
Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131])
	by core3.amsl.com (Postfix) with ESMTP id DF18428C2C6
	for <ietf at ietf.org>; Tue,  8 Jul 2008 13:50:01 -0700 (PDT)
Received: from lust.indecency.org (mail.fiveman.com [72.242.14.234] (may be
	forged)) by m1.imap-partners.net (MOS 3.8.4-GA)
	with ESMTP id AWI95720 (AUTH admin at network-heretics.com)
	for ietf at ietf.org; Tue, 8 Jul 2008 13:50:08 -0700 (PDT)
Message-ID: <4873D2FF.7090607 at network-heretics.com>
Date: Tue, 08 Jul 2008 16:50:07 -0400
From: Keith Moore <moore at network-heretics.com>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: Joe Touch <touch at ISI.EDU>
Subject: Re: Update of RFC 2606 based on the recent ICANN changes ?
References: <20080708020228.GC10677 at zod.isi.edu>	<200807080254.m682sG2Q007427 at drugs.dv.isc.org>	<20080708161335.GB2519 at zod.isi.edu>	<4873948A.2040904 at network-heretics.com>
	<4873AE46.6010906 at isi.edu>	<4873B2C0.1020008 at network-heretics.com>
	<4873B353.20302 at isi.edu> <4873B5F8.1060702 at network-heretics.com>
	<4873B846.5070803 at isi.edu> <4873B993.9040705 at network-heretics.com>
	<4873C6FE.2000601 at isi.edu> <4873CC8F.3010601 at network-heretics.com>
	<4873CEDF.2080904 at isi.edu>
In-Reply-To: <4873CEDF.2080904 at isi.edu>
Cc: Ted Faber <faber at ISI.EDU>, Mark Andrews <Mark_Andrews at isc.org>,
	Theodore Tso <tytso at MIT.EDU>, ietf at ietf.org
X-BeenThere: ietf at 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 at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ietf-bounces at ietf.org
Errors-To: ietf-bounces at ietf.org

> > > It's nonsensical for an application to decide that relative names are 
> > > unacceptable, but to require users to input names as relative.
> >
> > it's nonsensical for you to unilaterally declare that such names are 
> > relative, when well over two decades of practice indicates otherwise.
>
> I didn't declare it; 1034 did. 

Yes - but you're the one declaring that 1034 trumps decades of later 
work.  Normally the assumption would be that work can be revised as bugs 
are found or conditions change over time, and that things that had 
achieved IETF consensus since 1034 was published would be considered at 
least equal, and often superior, to earlier work.

I don't think 1034 was handed down from a mountain on stone tablets.

I believe it always was inevitable that different apps would use DNS (or 
any shared naming facility) in slightly different ways.  Yes this is 
somewhat confusing, but DNS (like the rest of the Internet) has been 
stretched far beyond its original design goals or scale.  For instance, 
we don't interpret DNS names as hostnames any more - because in the 
modern world the concept of "host name" is irrelevant in the vast 
majority of cases.

Aases.

And maybe this provides an illustration of how difficult it is for us to 
use service protocols consistently from one application to another (it's 
not hard to find other examples).  But such difficulty is real and it 
reflects genuine differences in requirements from one app to the next. 
Arguably 1034 didn't even address the needs of apps existing at that 
time (email being one of those apps), much less apps that came later.

Keith
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf


nd maybe this provides an illustration of how difficult it is for us to 
use service protocols consistently from one application to another (it's 
not hard to find other examples).  But such difficulty is real and it 
reflects genuine differences in requirements from one app to the next. 
Arguably 1034 didn't even address the needs of apps existing at that 
time (email being one of those apps), much less apps that came later.

Keith
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf