Subject: Re: [dns-dir] draft-liman-tld-names-00

From: Thomas Narten <[email-masked]>
Date: Wed, 07 Oct 2009 17:55:24 -0400

OK, back to this one...

Given where we are (ICANN meeting in 3 weeks), given the risks of
lifting stones covering large ratholes (spare me!), I am now convinced
that we should have a document that *very* narrowly just makes it
clear that IDN TLDs are OK.

Looking at the draft:

> Abstract
> 
>    RFC 1123 is ambiguous regarding the specification for top level
>    domain (TLD) labels used in the domain name system.  This document
>    clarifies the specification, and aligns it with current praxis,
>    including the use of Internationalized Domain Name (IDN) Labels in
>    TLD names.

How about

     The precise syntax allowed in top-level domain name labels has
     been the subject to some debate.  RFC 1123, for example, states
     that top-level domain names must be "alphabetic". This document
     updates the definition of allowable top-level domain names in
     order to support internationalized domain names (IDNs), as
     encoded by the IDNA protocols. This document focusses narrowly on
     the issue of IDNs and does not make any other changes or
     clarifications to existing domain name syntax rules.

> 
> 1.  Introduction and Background
> 
>    RFC 1123 [RFC1123] is ambiguous regarding the specification for top
>    level domain (TLD) labels used in the domain name system.  There are
>    different interpretations which leads to problems when deciding on
>    new TLD names.  One important aspect of this is the wish to use
>    internationalized domain name (IDN, RFC 3490 et. al.  [RFC3490])
>    labels in top level domains to facilitate use of local scripts.
> 
>    This document strives to make a new and clear definition of which
>    character sequences are allowed in TLD labels.
> 
>    This document is a proposal and a work in progress.

How about:

     The precise syntax allowed in top-level domain name labels has
     been the subject to some debate.  RFC 1123, for example, states
     that top-level domain names must be "alphabetic", which is
     interpreted as excluding the hyphen (or dash) character. This
     document updates the definition of allowable top-level domain
     names to support internationalized domain names, as encoded by
     the IDNA protocols [RFCXXX]. In particular, this document
     clarifies that ascii TLDs beginning with "xn--", as encoded by
     IDNA, are permissible as DNS TLD names. This document focusses
     narrowly on the issue of allowable ascii lables encoded by the
     IDNA protocols and does not (and is not intended to) make any
     other changes or clarifications to existing domain name syntax
     rules.

> 1.1.  Terminology
> 
>    The terminology used in this document is as defined in RFC 0952
>    [RFC0952] and RFC 1035 [RFC1035].
> 
> 1.2.  Requirements Language
> 
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in RFC 2119 [RFC2119].

> 2.  Technical specification for Top Level Domain Labels

Better:

2.   Background

>    RFC 952 [RFC0952] gives the specification for names that may be used
>    for host names on the Internet.  It is updated by RFC 1123 [RFC1123],
>    which relaxes the specification somewhat.  It is somewhat unclear
>    wheter the relaxation is per label or per entire host name.

How about:

     RFC 952 states (among other things) that a host name is;

	... a text string up to 24 characters drawn from the alphabet
	(A-Z), digits (0-9), minus sign (-), and period (.).  Note
	that periods are only allowed when they serve to delimit
	components of "domain style names". (See RFC-921, "Domain Name
	System Implementation Schedule", for background).  No blank or
	space characters are permitted as part of a name. No
	distinction is made between upper and lower case.  The first
	character must be an alpha character.  The last character must
	not be a minus sign or period.

     RFC 1123 [RFC1123] reaffirms this definition, making two
     additional changes to the syntax:

           The syntax of a legal Internet host name was specified in
	   RFC-952 [DNS:4].  One aspect of host name syntax is hereby
	   changed: the restriction on the first character is relaxed
	   to allow either a letter or a digit.  Host software MUST
	   support this more liberal syntax.

     and

           However, a valid host name can never have the
           dotted-decimal form #.#.#.#, since at least the
           highest-level component label will be alphabetic.

      This last sentence implies that IDNs as encoded by IDNA (which
      begin with a "xn--" prefix) are not allowed as TLDs.

      This document explicitly updates the above rules to allow TLD
      ascii labels that result from the encoding of IDNs via IDNA.

Do we need more than the above? Should we just say "xn--" is allowed?
I'm wary of trying to define an ABNF in this document... People may
start arguing....
      
> 3.  Other Limitations on Top Level Domain Labels
> 
>    It is carefully noted that the above specification is not the only
>    limiting factor on TLD labels.  There may be other entities than the
>    IETF that have influence over TLD names, and which may decide to
>    restrict the names further.  The above technical specification is
>    just one limiting factor.

Better:

    It should be noted that there are many issues that must be
    considered in making any changes to current restrictions on DNS
    labels, especially at the top level. DNS software is widely
    deployed, and some of that software contains embedded assumptions
    that may not hold if DNS names are used at the top level that
    differ from the older rules. For example, when TLDs longer than 3
    characters became available (e.g., .info, .museum, etc.), some
    deployed systems did not process such DNS names properly. This
    document does not take the position that no problems will result
    when IDN TLDs are created, but does recognize that relaxing the
    syntax of allowed TLDs is necessary in order to allow deployment
    of IDNs to happen.

> 
> 4.  IANA Considerations
> 
>    This memo changes the specifications for TLD names registered by the
>    IANA, and the IANA is requested to change its registration process to
>    use the above specification.

> 5.  Security Considerations
> 
>    This document does not introduce any new security issues.

Not necessarily true. Maybe someone will truncat TLDs during lookups,
names will resolve incorrectly, and bad things can happen... Yeah, not
a huge risk, perhaps, but we should say something.

>    It may introduce stability issues where names registered under this
>    new specification may interoperate badly with old software written to
>    enforce a strict interpretation of the old specification.  However,
>    it is belived that such software is scarce on the Internet, and since
>    TLD names that do not adhere to a strict interpretation of the old
>    specification are already used (including IDNs) without apparent
>    problems, it is believed that this change of the specicification will
>    not create major stability problems on the Internet.

Does the above make sense? Do others think this is reasonable?

In any case, we need to get this one moving...

Thomas

---

From: Lars-Johan Liman <[email-masked]>
Date: Thu, 08 Oct 2009 18:35:43 +0100

> OK, back to this one...

I'm at the RIPE meeting. I'll try to take a look at this thread ASAP,
but it may be a few hours. Also patchy connectivity. :-(

				Cheers,
				  /Liman