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

[Mark Andrews <Mark_Andrews at isc.org>]

> 
> --YD3LsXFS42OYHhNZ
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> On Tue, Jul 08, 2008 at 11:47:15AM +1000, Mark Andrews wrote:
> >=20
> > > The site-dependent interpretation of the name is determined not by the
> > > presence of dot within the name but its absence from the end.
> >=20
> > 	No.  Please go and re-read RFC 921.
> 
> What a charming document.
> 
> I don't see anything in it that indicates a hierarchical name can't
> consist of one level, though I see plenty of examples of 2-level names.
> If you see text in there that I missed, I'm all ears.
> 
> I do see this in RFC 1035, though:
> 
> >When a user needs to type a domain name, the length of each label is
> >omitted and the labels are separated by dots (".").  Since a complete
> >domain name ends with the root label, this leads to a printed form which
> >ends in a dot.  We use this property to distinguish between:
> >
> >   - a character string which represents a complete domain name
> >     (often called "absolute").  For example, "poneria.ISI.EDU."
> >
> >   - a character string that represents the starting labels of a
> >     domain name which is incomplete, and should be completed by
> >     local software using knowledge of the local domain (often
> >     called "relative").  For example, "poneria" used in the
> >     ISI.EDU domain.
> >
> >Relative names are either taken relative to a well known origin, or to a
> >list of domains used as a search list.  Relative names appear mostly at
> >the user interface, where their interpretation varies from
> >implementation to implementation, and in master files, where they are
> >relative toFrom ietf-bounces at ietf.org  Mon Jul  7 19:54:18 2008
Return-Path: <ietf-bounces at ietf.org>
X-Original-To: ietf-web-archive at megatron.ietf.org
Delivered-To: ietfarch-ietf-web-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 24F2D3A6953;
	Mon,  7 Jul 2008 19:54:18 -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 859003A6953
	for <ietf at core3.amsl.com>; Mon,  7 Jul 2008 19:54:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[AWL=-0.011, 
	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 ISaZKMcET0JE for <ietf at core3.amsl.com>;
	Mon,  7 Jul 2008 19:54:16 -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 19EC23A6920
	for <ietf at ietf.org>; Mon,  7 Jul 2008 19:54:15 -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 m682sG2Q007427;
	Tue, 8 Jul 2008 12:54:16 +1000 (EST)
	(envelope-from marka at drugs.dv.isc.org)
Message-Id: <200807080254.m682sG2Q007427 at drugs.dv.isc.org>
To: Ted Faber <faber at ISI.EDU>
From: Mark Andrews <Mark_Andrews at isc.org>
Subject: Re: Update of RFC 2606 based on the recent ICANN changes ? 
In-reply-to: Your message of "Mon, 07 Jul 2008 19:02:28 MST."
	<20080708020228.GC10677 at zod.isi.edu> 
Date: Tue, 08 Jul 2008 12:54:16 +1000
Cc: Theodore Tso <tytso at MIT.EDU>, moore at network-heretics.com, 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces at ietf.org
Errors-To: ietf-bounces at ietf.org


> 
> --YD3LsXFS42OYHhNZ
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> On Tue, Jul 08, 2008 at 11:47:15AM +1000, Mark Andrews wrote:
> >=20
> > > The site-dependent interpretation of the name is determined not by the
> > > presence of dot within the name but its absence from the end.
> >=20
> > 	No.  Please go and re-read RFC 921.
> 
> What a charming document.
> 
> I don't see anything in it that indicates a hierarchical name can't
> consist of one level, though I see plenty of examples of 2-level names.
> If you see text in there that I missed, I'm all ears.
> 
> I do see this in RFC 1035, though:
> 
> >When a user needs to type a domain name, the length of each label is
> >omitted and the labels are separated by dots (".").  Since a complete
> >domain name ends with the root label, this leads to a printed form which
> >ends in a dot.  We use this property to distinguish between:
> >
> >   - a character string which represents a complete domain name
> >     (often called "absolute").  For example, "poneria.ISI.EDU."
> >
> >   - a character string that represents the starting labels of a
> >     domain name which is incomplete, and should be completed by
> >     local software using knowledge of the local domain (often
> >     called "relative").  For example, "poneria" used in the
> >     ISI.EDU domain.
> >
> >Relative names are either taken relative to a well known origin, or to a
> >list of domains used as a search list.  Relative names appear mostly at
> >the user interface, where their interpretation varies from
> >implementation to implementation, and in master files, where they are
> >rel a single origin domain name.  The most common interpretation
> >uses the root "." as either the single origin or as one of the members
> >of the search list, so a multi-label relative name is often one where
> >the trailing dot has been omitted to save typing.
> 
> That sounds a lot to me like "hk." is as global as "hk.com."

	"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.

	Mark

> --=20
> Ted Faber
> http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.=
> asc
> Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#=
> SIG
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf


ative to a single origin domain name.  The most common interpretation
> >uses the root "." as either the single origin or as one of the members
> >of the search list, so a multi-label relative name is often one where
> >the trailing dot has been omitted to save typing.
> 
> That sounds a lot to me like "hk." is as global as "hk.com."

	"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.

	Mark

> --=20
> Ted Faber
> http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.=
> asc
> Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#=
> SIG
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf