Re: Services and top-level DNS names (was: Re: Update of RFC 2606

John C Klensin <> Tue, 08 July 2008 05:49 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id D0BFC3A689A; Mon, 7 Jul 2008 22:49:24 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1DD5D3A689A for <>; Mon, 7 Jul 2008 22:49:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.393
X-Spam-Status: No, score=-2.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uxXXmBQE41KF for <>; Mon, 7 Jul 2008 22:49:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 16F183A67D9 for <>; Mon, 7 Jul 2008 22:49:23 -0700 (PDT)
Received: from [] (helo=p3.JCK.COM) by with esmtp (Exim 4.34) id 1KG64r-00039V-EG; Tue, 08 Jul 2008 01:49:25 -0400
Date: Tue, 08 Jul 2008 01:49:24 -0400
From: John C Klensin <>
To: Bill Manning <bmanning@ISI.EDU>
Subject: Re: Services and top-level DNS names (was: Re: Update of RFC 2606
Message-ID: <A886A120D781BDBC027B4BFF@p3.JCK.COM>
In-Reply-To: <>
References: <> <41C0AA5BE72A51344F410D1E@p3.JCK.COM> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Mark Andrews <>,
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

--On Monday, 07 July, 2008 12:08 -0700 Bill Manning
<bmanning@ISI.EDU> wrote:

> 	John, do you beleive that DNS host semantics/encoding that
> form the bulk 	of the IDN work (stringprep, puny-code,
> are applicable -only- in 	the context of zone file generation
> or are they also applicable in  	configuration and acess
> control for DNS?

I think I don't understand the question.   RFC 3490 tries to
make a distinction between IDNA-aware and IDNA-unaware
applications and domain name "slots".  The intent is, more or
less, to permit a punycode-encoded string with the prefix (which
the IDNA2008 drafts call an "A-label") to appear nearly anywhere
in the DNS but to expect conversion to and/or from native
characters only in contexts where IDNA is explicitly applied.
Even in zone files, IDNA is generally applicable only to labels
and not to data fields.

> 	path/alias expansion/evaluation will be interesting if "." is
> not what 	7bit ASCII thinks of as "."

RFC 3490 lists a series of other characters that are to be
treated as label-separating dots if encountered in an IDNA
context.  That model causes a number of interesting problems in
contexts where one has to recognize a string as a domain name,
and possibly process it, without knowing anything about IDNA.
The problems show up in situations as simple as conversions
between label-dot-label-dot-label format and length-label list
format, making it very important whether one identifies an FQDN
as containing IDNA labels or converts it to length-label form
first.  IDNA2008 (see the IDNABIS WG and its documents and
mailing list) does away with all of this as part of a general
plan to do a lot less mapping of characters into other
characters.  So, for the proposed newer version the only
label-separating dot permitted in the protocol is the character
you know as 7bit ASCII "." (U+002E in Unicode-speak).

Does that answer whatever the question was intended to be?


Ietf mailing list