summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2240.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2240.txt')
-rw-r--r--doc/rfc/rfc2240.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc2240.txt b/doc/rfc/rfc2240.txt
new file mode 100644
index 0000000..db10a65
--- /dev/null
+++ b/doc/rfc/rfc2240.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group O. Vaughan
+Request for Comments: 2240 Vaughan Enterprises
+Category: Informational November 1997
+
+
+ A Legal Basis for Domain Name Allocation
+
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1997). All Rights Reserved.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1
+
+ 2. Overview of the domain space . . . . . . . . . . . . . . . . 2
+
+ 3. Possible solutions to name exhaustion . . . . . . . . . . . 3
+
+ 4. Proposed creation of new SLDs . . . . . . . . . . . . . . . 3
+ 4.1 The world is not flat so why should domains be? . . . . . . 4
+ 4.2 The case for legal names . . . . . . . . . . . . . . . . . 4
+ 4.3 Allocation of legal SLDs . . . . . . . . . . . . . . . . . 4
+ 4.4 Allocation of miscellaneous SLDs . . . . . . . . . . . . . 5
+ 4.5 Identifiers in non-ASCII languages . . . . . . . . . . . . 5
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . 5
+
+ 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
+
+ 7. Authors' Address . . . . . . . . . . . . . . . . . . . . . . 6
+
+ 8. Full Copyright Statement . . . . . . . . . . . . . . . . . . 7
+
+1. Introduction
+
+ The purpose of this memo is to focus discussion on the particular
+ problems with the exhaustion of the top level domain space in the
+ Internet and the possible conflicts that can occur when multiple
+ organisations are vying for the same name. No proposed solutions in
+
+
+
+
+
+Vaughan Informational [Page 1]
+
+RFC 2240 Domain Name Allocation November 1997
+
+
+ this document are intended as standards for the Internet. Rather, it
+ is hoped that a general consensus will emerge as to the appropriate
+ solution to such problems, leading eventually to the adoption of
+ standards.
+
+2. Overview of the domain space
+
+ Presently the domain space is organised as a heirarchical tree-
+ structured namespace with several top level domains (TLDs), and sub-
+ domains beneath them. The initial TLDs allocated and rationale are
+ documented in [1].
+
+ The TLDs are functionally split up into 'generic' top-level domains
+ (gTLDs) and two-letter ISO 3166 country domains for every country in
+ which Internet connectivity is provided. The allocation of sub-
+ domains under these TLDs is entirely up to the registry for that TLD.
+ The registry may decide to allocate further levels of structure or
+ merely allocate domains in a 'flat' manner.
+
+ Example:
+
+ +-----+ +----+ +----+
+ | COM | | UK | | FR |
+ +-----+ +----+ +----+
+ | | | | |
+ +---------+ +----+ +----+ +--------------+ +-----+
+ | VAUGHAN | | AC | | CO | | UNIV-AVIGNON | | AXA |
+ +---------+ +----+ +----+ +--------------+ +-----+
+ | | | | |
+ +------+ +---------+ +----------+ +-----+ +------+
+ | UNIX | | NEWPORT | | CITYDESK | | SOL | | MAIL |
+ +------+ +---------+ +----------+ +-----+ +------+
+ | |
+ +----+ +-----+
+ | NS | | FTP |
+ +----+ +-----+
+
+
+ 1. Flat gTLD 2. Heirarchical country 3. Flat country
+
+ In the example we see that the gTLDs are inherently flat, as
+ organisations are allocated domain names directly under the TLD.
+ With the country domains however, the domain allocation policy can
+ vary widely from country to country, and it does. Some may choose to
+ implement a functional sub-structure mirroring the gTLDs, some may
+ choose to implement a geographical sub-structure, and some may choose
+ to have no sub-structure at all.
+
+
+
+
+Vaughan Informational [Page 2]
+
+RFC 2240 Domain Name Allocation November 1997
+
+
+ In the first case the organisation is clearly a commercial one, as it
+ is allocatged under the "COM" TLD. However, there is no information
+ as to the country the organisation is based in. In the third case,
+ we know that the organisation is based in France (FR), but without
+ studying the actual organisation name we do not know what type of
+ organisation it is. In the second case, we know the country that
+ both organisations are based in (UK), and by following the heirarchy,
+ we can deduce that the first is an academic organisation (AC), and
+ the second is commercial (CO).
+
+ While the system is flexible in not enforcing a strict heirarchy, it
+ can lead to exhaustion of domain names in the generic space and lead
+ to conflicts between organisations who may both have a legitimate
+ claim to have a particular name.
+
+3. Possible solutions to name exhaustion
+
+ With such a flexible system, there are many ways of preventing the
+ name space being exhausted. A solution proposed by [2] is to create
+ more gTLDs to allow organisations with the same name to be registered
+ uniquely under different TLDs (FIRM, STORE, WEB, ARTS, REC, INFO and
+ NOM). However this has several disadvantages as discussed below:
+
+ a) It creates confusion in users mind as to what TLD refers to a
+ particular organisation. For example, MCDONALDS.COM maybe the fast
+ food corporation and MCDONALDS.FIRM maybe a firm of lawyers, but
+ how is the user supposed to know which is which?
+
+ b) To prevent the above confusion, big corporations will simply
+ reserve all the different variations of the name, ie. IBM.COM,
+ IBM.FIRM, IBM.STORE etc. Thus we haven't solved the name
+ exhaustion or conflict problems, in fact we have made it worse.
+
+ c) Names of legitimate trade mark holders or other legally held names
+ can still be acquired by anybody, leading to potential conflicts.
+
+4. Proposed creation of new SLDs
+
+ With the aforementioned problems in mind, it is not a good idea to
+ create new gTLDs which merely overlap the existing ones. As the
+ domain name system is heirarchical it would seem a good idea to
+ expand on the existing structure rather than creating several
+ duplicate structures.
+
+
+
+
+
+
+
+
+Vaughan Informational [Page 3]
+
+RFC 2240 Domain Name Allocation November 1997
+
+
+4.1 The world is not flat so why should domains be?
+
+ With the expansion of the Internet to a truly global medium, the
+ notion that there can only be one commercial entity, one orgnisation,
+ and one network provider etc. with the same name seems impossible.
+ This is the situation that the present system finds itself in. There
+ is a constantly spiralling number of disputes over who 'owns' or '
+ deserves' a certain name, with an increasing number ending in
+ unnecessary and costly legal action. This is not something that the
+ providers of a domain name service should concern themselves with,
+ but yet with the present system, this seems inevitable.
+
+4.2 The case for legal names
+
+ This proposal allows for country domain names that are related to
+ legally registered names in the country that they are based by
+ creating a functional heirarchy beneath the country TLD.
+
+ This proposal does not seek to do away with gTLDs, but rather that a
+ legal name should be sought first and then, if desired, a generic
+ name could be used alongside it. The organisation would then, in case
+ of any disputes, have a legally-held name which no other organisation
+ could have any claim to.
+
+ This proposal has several advantages:
+
+ a) The process of deciding what names belong to which organisation
+ is no longer a function of the domain name registry, but of the
+ company registration authority in the given country. This means
+ that disputes over names cannot arise as all names are unique
+ within the context of the legal company title.
+
+ b) As all names are unique, there should be no exhaustion
+ (deliberately or otherwise) of 'desirable' names by other
+ concerns, as all the owners of legally-held company names will
+ automatically have the right to the relevant domain name.
+
+4.3 Allocation of legal SLDs
+
+ The second level domain identifiers should be created from the
+ existing company indentifiers within the given country. For example:
+
+ LTD.UK for limited companies in the UK
+ PLC.UK for public companies in the UK
+ INC.US for incorpated bodies in the US
+ CORP.US for corporations in the US
+ GMBH.DE for German companies
+
+
+
+
+Vaughan Informational [Page 4]
+
+RFC 2240 Domain Name Allocation November 1997
+
+
+ The registries for the appropriate top-level country domain should
+ create and manage the sub-domains based on the laws for allocating
+ company names in that particular country. Specifically, ALL spaces
+ should be converted to hyphens '-' and other punctuation either
+ disregarded or also converted into hyphens.
+
+ For holders of international trademarks and other international
+ names, the gTLD "INT" can be used in place of the country identifier.
+ For example:
+
+ TM.INT } for international trademarks
+ REG.INT }
+
+4.4 Allocation of miscellaneous SLDs
+
+ In countries that do not have existing sub-structure it is strongly
+ recommended that along with the creation of legal SLDs described
+ here, that other SLDs be created for commercial entities,
+ organisations, and academic entities to reduce remaining conflicts
+ from organisations that are not legally-registered companies.
+
+ For example:
+
+ +------------------+
+ | ISO 3166 country | . . . . . . . . .
+ +------------------+ . .
+ | | | . .
+ +-----+ +-----+ +-----+ +-----+ +-----+
+ | AC/ | | CO/ | | OR/ | | LTD | | INC |
+ | EDU | | COM | | ORG | +-----+ +-----+
+ +-----+ +-----+ +-----+
+
+4.5 Identifiers in non-ASCII languages
+
+ The representation of any domain element is limited to the ASCII
+ character set of alphabetic characters, digits and the hyphen, as
+ described in [3]. The representation of names in languages that use
+ other character sets is limited by that definition or any future
+ update.
+
+5. Security Considerations
+
+ This memo raises no issues relating to network security. However
+ when delegating the subdomains, the registries must ensure that the
+ application contains sufficient evidence of the legal rights to a
+ given name.
+
+
+
+
+
+Vaughan Informational [Page 5]
+
+RFC 2240 Domain Name Allocation November 1997
+
+
+6. References
+
+ [1] Postel J. and J. Reynolds , "Domain Requirements", RFC 920,
+ October 1984.
+
+ [2] "Generic Top Level Domains - Memoranding of Understanding"
+ <URL:http://www.gtld-mou.org/>
+
+ [3] Mockapetris, P., "Domain names - Implementation and
+ Specification", RFC 1035, November 1987.
+
+7. Author's Address
+
+ Owain Vaughan
+ Vaughan Enterprises
+ PO Box 155
+ Newport NP9 6YX
+ UK
+
+ Phone: +44 1633 677849/822164
+ Fax: +44 1633 663706
+ EMail: owain@vaughan.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaughan Informational [Page 6]
+
+RFC 2240 Domain Name Allocation November 1997
+
+
+8. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1997). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaughan Informational [Page 7]
+