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

Mark Andrews <Mark_Andrews@isc.org> Wed, 09 July 2008 05:14 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 429303A696D; Tue, 8 Jul 2008 22:14:38 -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 48F2C3A69A8 for <ietf@core3.amsl.com>; Tue, 8 Jul 2008 22:14:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.652
X-Spam-Level:
X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[AWL=-0.053, 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 AwZ1ubJVDa1Z for <ietf@core3.amsl.com>; Tue, 8 Jul 2008 22:14:36 -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 A127B3A6839 for <ietf@ietf.org>; Tue, 8 Jul 2008 22:14:35 -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 m695EeAX082124; Wed, 9 Jul 2008 15:14:40 +1000 (EST) (envelope-from marka@drugs.dv.isc.org)
Message-Id: <200807090514.m695EeAX082124@drugs.dv.isc.org>
To: Joe Touch <touch@ISI.EDU>
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 21:32:58 MST." <48743F7A.3050906@isi.edu>
Date: Wed, 09 Jul 2008 15:14:40 +1000
Cc: Ted Faber <faber@ISI.EDU>, Theodore Tso <tytso@MIT.EDU>, 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

> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
> --------------enigB56BE6D16B38F294AC1B9ED5
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: quoted-printable
> 
> Mark Andrews wrote:
> >>>> It's nonsensical for an application to decide that relative names ar=
> e=20
> >>>> 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.=20
> >=20
> > 	And RFC 1535 got resolvers to try search lists last if there
> > 	was a period in the name.   This removed the need for final
> > 	periods for any legal fully qualified host name.
> 
> First, 1535 is informational, so it doesn't get anyone to do anything=20
> per se. The SHOULD therein is nonbinding.
> 
> Second, that document is very clear about applying to relative names,=20
> not FQDNs.
> 
> Finally, "." is a legal FQDN. So is "a.". The lack of an internal "."=20
> means that the "more stringent mechanism..implemented in BIND 4.9.2"=20
> discussed in 1535 does not apply.
> 
> I.e., 1535 describes an implementation decision to assume that:\
> 	<has internal "."> implies <is a FQDN>
> 
> The converse does not follow, i.e.:
> 	<is a FQDN> does NOT imply <has an internal ".">
> 
> > 	"hk" is not a legal fully qualified host name.
> 
> Agreed. "hk.", however, is.

	No, it is not a legal hostname. 

	RFC 952 explicitly excludes trailing periods.

	"The last character must not be a minus sign or period."

>  >       Demanding that
> > 	applications support final dots to support uses that are outside
> > 	of the original design scope is nonsensical.
> 
> What uses? Specifying that the trailing "." means FQDN is defined in the =
> 
> DNS spec (1034). Apps that interpret names as DNS names need to follow=20
> that spec. Period (pun intended).
>
> Joe
> 
> 
> --------------enigB56BE6D16B38F294AC1B9ED5
> Content-Type: application/pgp-signature; name="signature.asc"
> Content-Description: OpenPGP digital signature
> Content-Disposition: attachment; filename="signature.asc"
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFIdD97E5f5cImnZrsRAkqyAJ9OjjvNGysnfpPL1p3xlQQfcqp1jwCg+eaG
> mTV7pl7RuGUtUoijPzh4xgE=
> =QUeZ
> -----END PGP SIGNATURE-----
> 
> --------------enigB56BE6D16B38F294AC1B9ED5--
-- 
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