Domain Names
draft-lewis-domain-names-02

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Last updated 2016-01-28
Stream (None)
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Independent Submission                                        E. Lewis
Internet-Draft                                                   ICANN
Expires: July 30, 2016                          Date: January 30, 2016
Intended Status: unknown

                            Domain Names
                    draft-lewis-domain-names-02.txt

Abstract

This document states a definition of Domain Name beyond the use of
the term within the Domain Name System.  The document includes a
survey of the diverse ways Domain Names have been interpreted within
various protocols over time.  The purpose of this is to give a solid
foundation for work on Domain Names across all protocols making use
of Domain Names.

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF).  Note that other groups may also distribute
working documents as Internet-Drafts.  The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on July 30, 2016.

Copyright Notice

Copyright (c) 2016 IETF Trust and the persons identified as the
document authors.  All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document.  Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.  Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

0.  NOTE TO RFC EDITOR AND REVIEWERS  . . . . . . . . . . . . . .   1
1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   1
2.  Reaching a definition of a Domain Name  . . . . . . . . . . .   1
3.  Subtypes of Domain Names  . . . . . . . . . . . . . . . . . .   1
4.  Interoperability Considerations   . . . . . . . . . . . . . .   1
5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   1
6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   1
7.  Security Considerations . . . . . . . . . . . . . . . . . . .   1
8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   1
9.  Authors' Addresses  . . . . . . . . . . . . . . . . . . . . .   1

0.  NOTE TO RFC EDITOR AND REVIEWERS

A suitable venue for discussion of this document is the dnsop working
group.  Private comments may also be directed at the editor.

This document will be presented to the Dispatch WG as it relates
to the use of identifiers across protocols, despite perceptions
that the DNS defines Domain Names.

This section (and sub-sections) **probably** should be removed
prior to publication.  

0.1 Backstory

Editorial note - I'm not sure whether 0.1 and 0.2 will remain in
the document.  Despite the "probably should" above.

Why bother to define Domain Names now, three decades after the
earliest mentions in RFC documents?  There are many examples of
names as identifiers in existence, a lot of running code.  There is
a large industry built on management of names as well, a lot of
financial investment made.  Would not a definition appearing now be
merely an academic exercise or worse, a disruption to what seems to
be a reliable system?

The tipping point related to addressing the lack of a definition is
the call to apply a special meaning to certain Domain Names, with
special meaning "not managed via the DNS."  The DNS, whose history
and explanation follow, has been created to manage Domain Names and
over time evolved to become the defining force behind Domain Names.
The emergence of other name management systems, in the sense of
"permissionless innovation", have called into question whether DNS
is the defining force for Domain Names.

There are good reasons to call this into question.  The DNS
definition makes some simplifyng assumptions about Domain Names,
carving out some functionality that the newer name management systems
wish to explore.  To foster this innovation, better definitions,
boundaries and even an architectural review of Domain Names is
benefical.

The beneficiaries of such work include both the developers of
software that makes use of names and identifiers.  A single piece of
code code be used in different nameing environments if the code can
determine how to process a name.  With code reusable across different
environments, another beneficiary are those exploring new means of
Show full document text