Subject: [dns-dir] 5th draft… was Re: Comments on draft (was: Re: Browser IDN display policy etc.)

From: Olaf Kolkman <[email-masked]>
Date: Wed, 25 Jan 2012 11:18:21 +0100

[I am putting the DNS directorate in the loop, the introduction is for them]

Colleagues,

This is the fifth and hopefully final draft of a statement developed with input from IAB's i18n and iana-strategy program. It is about to be sent to the IAB with a recommendation for approval.

The note should be self-explanatory. But, shortly, its intend is to communicate that other considerations than purely DNS protocol considerations exists when deciding which labels to allow.

During the directory dinner in Taipei we discussed the aspect of numbers that might be interpreted by some implementations as IP addresses and this statement calls out that some research is needed in that area even when we want to provide the most liberal interpretation of the general requirements.

Anyhow, I am sharing this with you all since I wouldn't want you to be caught by surprise and although feedback from the directorate is certainly no requirement, there is a small window of opportunity if you would want to provided feedback.

--Olaf

5th DRAFT

                         IAB statement on
 "The interpretation of rules in the ICANN gTLD Applicants Guidebook."

= Introduction

The IAB observes that the ICANN gTLD Applicants Guidebook (version
2012-01-11) contains a section with requirements for Internationalized
Domain Names (IDNs) in section 1.3. This section contains the
following requirement:

    "The prefix and string together must conform to all
     requirements for a label that can be stored in the DNS
     including conformance to the LDH (host name) rule
     described in RFC 1034, RFC 1123, and elsewhere."

The IAB maintains the following interpretation of that requirement.

Top-Level and Second-Level Domain (TLD and SLD) labels in the Domain
Name System (DNS) [RFC1034] [RFC1035] are not required by the DNS
protocols to adhere to any syntax beyond that for any other DNS label:
e.g. any binary string whatever can be used at any point in the DNS
[RFC2181]. However there are good engineering reasons, some of them
embedded into application protocols, for providing the more restricted
Letter-Digit-Hyphen(LDH) syntax.

While to a substantial degree policy matters related to the DNS lie
with ICANN, a base syntax constraint for SLD and TLD labels, with its
roots in protocol engineering and operations, is a natural product of
the IETF and has been an IAB responsibility since its early
existence. Such syntax definitions form a baseline upon which other
DNS policy can be layered.

One of the documents that the guidebook explicitly referred to is
RFC1123. In conversations with subject matter specialists we have
observed different interpretations about the normative nature of one
of the specific TLD requirements set by that document ('will be
alphabetic' see discussion below). However, that specific RFC 1123
requirement reflects policy choices set by the IAB in pre-ICANN times
that were informed by the application-layer considerations relating
to human factors.

= Technical Detail

[RFC1034] provides the definition of a preferred name syntax in
section 3.5 with the following motivation:

  "However, when assigning a domain name for an object, the prudent
   user will select a name which satisfies both the rules of the
   domain system and any existing rules for the object, whether these
   rules are published or implied by existing programs."

The document then continues with an example referring to names as used
by the Internet Mail application and the rules for the old HOSTS.TXT
file (see [RFC952] for context). The section finishes with the exact
specification of the LDH in Abstract Syntax notation.

[RFC1123] reaffirms this definition, but makes one change 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.'  [Section 2.1]

In addition, the DISCUSSION section of Section 2.1 says:

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

Neither [RFC0952] nor [RFC1123] explicitly states the reasons for
these restrictions. But, prudent engineering so that human factors,
such as confusion, cause minimal problems are an important
consideration. For instance, [RFC1123] suggest that one of the reasons
was to prevent confusion between dotted-decimal IPv4 addresses and
host domain names.

That decision has been interpreted as normative and is known to have
found its way in specifications, implementations, or both. For
instance [RFC1738], in its description of the "host" part of a Uniform
Resource Locator, declares:

 'The rightmost domain label will never start with a digit, though,
  which syntactically distinguishes all domain names from the IP
  addresses.'  [Section 3.1]

Summarizing, the restriction that 'the highest-level component label
will be alphabetic' has been assumed in some deployed software,
and therefore changes to the rules should be undertaken with caution.

The strictest interpretation of 'will be alphabetic' would exclude
valid A-Labels in the root and should be expanded to permit the xn--
type labels. We are aware of at least one work in progress
[draft-liman-tld-names] that is trying to provide such an expanded
specification.

We assert that the following requirements apply to any such
specification:

   1.  TLD labels that do not allow IPv4 and IPv6 address literals to
       be clearly distinguishable from DNS names, both in wire and
       presentation format, MUST NOT be permitted. (This is the most
       liberal requirement.)

   2.  Internationalised strings encoded according to the IDNA2008
       specification [RFC5891] [RFC5892] MUST be permitted in general,
       but the set of Unicode characters which are permissible in TLD
       U-Labels MAY be constrained in order to satisfy other
       requirements. (The most conservative interpretation of this
       constraint is the "only alphabetic requirement".)

   3.  Existing TLD labels at the time this document is published MUST
       be permitted.

   4.  The syntax definition SHOULD be compatible with existing
       assumptions by application developers and users, to the extent
       that those assumptions can be determined.

Indeed, when translating the RFC1123 requirement to a specification,
pure technical as well as human factors (requirement 4) need to be
taken into account in the engineering. The resulting specification is
likely to end up between two extreme interpretations: The first takes
the most conservative interpretation and translates that specification
to the IDN context, and the second takes the most liberal boundary,
which only defines the known technical limitations (ignoring the human
factors).

The most conservative interpretation of the constrains set by RFC1123
is that a TLD is 'alphabetic' only. The specification of this
interpretation in the context to IDNA would not allow numbers, symbols
such as punctuation marks, or diactrics  in both A and U-Label with
the notable exception of the 'xn--' construct in A-Labels. 

The most liberal interpretation of RFC1123 would be a specification
whereby requirement 4 does not introduce limitations that are not
already set by the other 3 requirements. Such specification would
define the input vallues in such a way that the final label cannot
contain an element that can be interpreted as part of an IP
address. Examples of those are labels consisting of strings that
represent integers between expressed in decimal, octal, or hexadecimal
but also U-labels that are likely to be interpreted as numbers by OS
or application libraries when entered in the user interface.

To provide the specification for the most liberal interpretation,
research is needed as to how user input is eventually interpreted as
purely numeric and a possible IP address in legacy network stacks and
applications.

A final specification is likely to end up between these two extremes
as it also takes human factors and implementation issues from
requirement 4 into account. For example, combining Unicode characters
from the general letter category with the general mark category
(specifically the 'Mark, spacing combined' category [UNICODE61]) might
cause script dependencies in rendering libraries which creates
complexities that might eventually result in increased likelihood of
confusion among strings that would not be confused if rendered
correctly. It is not a given that these problems will happen but is
currently a subject of study among implementers and subject matter
specialists.

While a detailed specification is pending we recommend DNS registries,
ICANN in particular, follow the most conservative approach with
respect to the constraints set by other requirements i.e. issues like
usability, confusability, stability etc. The most conservative
approach is that one set by the 'will be alphabetic' text in RFC1123
translated to internationalized context:

   1.  the DNS-Label is a valid IDNA-valid string according to [RFC5890];

   2.  the derived property value of all code points, as defined by
       [RFC5890], is PVALID;

   3.  the general category of all code points, is one of {Ll, Lo, Lm}.
       [UNICODE61]

Although this conservative constraint doesn't prevent useful mnemonics
it is clear that not including the Mn and Mc general capacities limits
the possibility of full expression for certain South Eastern Asian
scripts. However, introducing labels that can cause interoperability
issues and/or set false expectations from users of the Internet will be
more damaging than following a conservative approach; The Internet
does not have an 'undo' button.

Summarizing

For the restrictions on TLD labels the ICANN GTLd guidebook makes a
reference to RFCs that contain technical policy choices that have not
been translated to internationalized versions. Research on existing
implementations, user-, and applications interfaces is needed before a
detailed specification can be developed. Absence such specification
the IAB strongly recommends a conservative approach in allowing new
TLD delegations.

The IAB, January XXX, 2012.

References

   [draft-liman-tld-names]: L-J. Liman and J. Abley "Top Level Domain
             Name Specification",
             http://tools.ietf.org/html/draft-liman-tld-names-06
             (work in progress, last checked Jan 24, 2012)

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
              and Support", STD 3, RFC 1123, October 1989.

   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
              Specification", RFC 2181, July 1997.

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, August 2010.

   [RFC5891]  Klensin, J., "Internationalized Domain Names in
              Applications (IDNA): Protocol", RFC 5891, August 2010.

   [RFC5892]  Faltstrom, P., "The Unicode Code Points and
              Internationalized Domain Names for Applications (IDNA)",
              RFC 5892, August 2010.

   [Unicode60]  The Unicode Consortium.  The Unicode Standard, Version
                6.0.0, defined by: "The Unicode Standard, Version
                6.0.0", (Mountain View, CA: The Unicode Consortium,
                2011. ISBN 978-1-936213-01-6).
                <http://www.unicode.org/versions/Unicode6.0.0/>.

________________________________________________________ 

Olaf M. Kolkman                        NLnet Labs
http://www.nlnetlabs.nl/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 25 Jan 2012 08:27:41 -0700

> and therefore changes to the rules should be undertaken with caution.

The phrase "changes to the rules should be undertaken with caution"
might be read as "we should make changes to the rules, but do so
carefully". I suggest: "caution should be exercised when contemplating
any changes to the rules" (or somesuch).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/