rfc2352.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 452 行 · 第 1/2 页

Network Working Group                                         O. Vaughan
Request for Comments: 2352                           Vaughan Enterprises
Obsoletes: 2240                                                 May 1998
Category: Informational


           A Convention For Using Legal Names as Domain Names

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 (1998).  All Rights Reserved.

RFC Editor's Note

   This RFC is an independent submission that discusses a possible
   convention for allocating domain names based on corporate and other
   names as registered by law.

   It appears to depend on corporations changing their domain names from
   their present form to more cumbersome handles, such as changing
   cisco.com to cisco-systems.co.ca.us or ibm.com to international-
   business-machines.co.ny.us, without giving them an incentive to do
   so, such as deprecating the .com and .net gTLDs.  It also appears to
   legislate the structure each national registry applies to its name
   space, something which the document itself asserts is within national
   purview and not for global standardization.

   It may not be politically feasible to implement as described.

















Vaughan                      Informational                      [Page 1]

RFC 2352   A Convention For Using Legal Names as Domain Names   May 1998


Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2

   2.   Overview of the domain space . . . . . . . . . . . . . . . . 2

   3.   Possible solutions to name exhaustion  . . . . . . . . . . . 4

   4.   Proposed solution  . . . . . . . . . . . . . . . . . . . . . 4
   4.1   The world is not flat so why should domains be? . . . . . . 4
   4.2   The case for legal names  . . . . . . . . . . . . . . . . . 5
   4.3   Allocation of legal sub-domains . . . . . . . . . . . . . . 5
   4.4   Allocation of miscellaneous sub-domains . . . . . . . . . . 6
   4.5   Identifiers in non-ASCII languages  . . . . . . . . . . . . 6
   4.6   Non-textual identifiers . . . . . . . . . . . . . . . . . . 7
   5.   Security Considerations  . . . . . . . . . . . . . . . . . . 7

   6.   References . . . . . . . . . . . . . . . . . . . . . . . . . 7

   7.   Authors' Address . . . . . . . . . . . . . . . . . . . . . . 7

   8.   Full Copyright Statement . . . . . . . . . . . . . . . . . . 8

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. The proposed solutions in
   this document are intended as a framework for development, such that
   a general consensus will emerge as to the appropriate solution to the
   problems in each case, 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 RFC 920 [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.




Vaughan                      Informational                      [Page 2]

RFC 2352   A Convention For Using Legal Names as Domain Names   May 1998


   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.

   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.








Vaughan                      Informational                      [Page 3]

RFC 2352   A Convention For Using Legal Names as Domain Names   May 1998


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.

   Another set of possible solutions are discussed by The World
   Intellectual Property Organisation [4] but this only addresses
   dispute resolution when trademarks are used as domain names under
   gTLDs, and not in the full legal context of their origin of
   registration.

4.  Proposed solution

   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.

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.





Vaughan                      Informational                      [Page 4]