GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2240

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2240.txt · Last modified: 1997/11/25 17:43 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki