home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc2352.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  16.4 KB  |  452 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         O. Vaughan
  8. Request for Comments: 2352                           Vaughan Enterprises
  9. Obsoletes: 2240                                                 May 1998
  10. Category: Informational
  11.  
  12.  
  13.            A Convention For Using Legal Names as Domain Names
  14.  
  15. Status of this Memo
  16.  
  17.    This memo provides information for the Internet community.  It does
  18.    not specify an Internet standard of any kind.  Distribution of this
  19.    memo is unlimited.
  20.  
  21. Copyright Notice
  22.  
  23.    Copyright (C) The Internet Society (1998).  All Rights Reserved.
  24.  
  25. RFC Editor's Note
  26.  
  27.    This RFC is an independent submission that discusses a possible
  28.    convention for allocating domain names based on corporate and other
  29.    names as registered by law.
  30.  
  31.    It appears to depend on corporations changing their domain names from
  32.    their present form to more cumbersome handles, such as changing
  33.    cisco.com to cisco-systems.co.ca.us or ibm.com to international-
  34.    business-machines.co.ny.us, without giving them an incentive to do
  35.    so, such as deprecating the .com and .net gTLDs.  It also appears to
  36.    legislate the structure each national registry applies to its name
  37.    space, something which the document itself asserts is within national
  38.    purview and not for global standardization.
  39.  
  40.    It may not be politically feasible to implement as described.
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Vaughan                      Informational                      [Page 1]
  59.  
  60. RFC 2352   A Convention For Using Legal Names as Domain Names   May 1998
  61.  
  62.  
  63. Table of Contents
  64.  
  65.    1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
  66.  
  67.    2.   Overview of the domain space . . . . . . . . . . . . . . . . 2
  68.  
  69.    3.   Possible solutions to name exhaustion  . . . . . . . . . . . 4
  70.  
  71.    4.   Proposed solution  . . . . . . . . . . . . . . . . . . . . . 4
  72.    4.1   The world is not flat so why should domains be? . . . . . . 4
  73.    4.2   The case for legal names  . . . . . . . . . . . . . . . . . 5
  74.    4.3   Allocation of legal sub-domains . . . . . . . . . . . . . . 5
  75.    4.4   Allocation of miscellaneous sub-domains . . . . . . . . . . 6
  76.    4.5   Identifiers in non-ASCII languages  . . . . . . . . . . . . 6
  77.    4.6   Non-textual identifiers . . . . . . . . . . . . . . . . . . 7
  78.    5.   Security Considerations  . . . . . . . . . . . . . . . . . . 7
  79.  
  80.    6.   References . . . . . . . . . . . . . . . . . . . . . . . . . 7
  81.  
  82.    7.   Authors' Address . . . . . . . . . . . . . . . . . . . . . . 7
  83.  
  84.    8.   Full Copyright Statement . . . . . . . . . . . . . . . . . . 8
  85.  
  86. 1.  Introduction
  87.  
  88.    The purpose of this memo is to focus discussion on the particular
  89.    problems with the exhaustion of the top level domain space in the
  90.    Internet and the possible conflicts that can occur when multiple
  91.    organisations are vying for the same name. The proposed solutions in
  92.    this document are intended as a framework for development, such that
  93.    a general consensus will emerge as to the appropriate solution to the
  94.    problems in each case, leading eventually to the adoption of
  95.    standards.
  96.  
  97. 2.  Overview of the domain space
  98.  
  99.    Presently the domain space is organised as a heirarchical tree-
  100.    structured namespace with several top level domains (TLDs), and sub-
  101.    domains beneath them. The initial TLDs allocated and rationale are
  102.    documented in RFC 920 [1].
  103.  
  104.    The TLDs are functionally split up into 'generic' top-level domains
  105.    (gTLDs) and two-letter ISO 3166 country domains for every country in
  106.    which Internet connectivity is provided. The allocation of sub-
  107.    domains under these TLDs is entirely up to the registry for that TLD.
  108.    The registry may decide to allocate further levels of structure or
  109.    merely allocate domains in a 'flat' manner.
  110.  
  111.  
  112.  
  113.  
  114. Vaughan                      Informational                      [Page 2]
  115.  
  116. RFC 2352   A Convention For Using Legal Names as Domain Names   May 1998
  117.  
  118.  
  119.    Example:
  120.  
  121.            +-----+         +----+                       +----+
  122.            | COM |         | UK |                       | FR |
  123.            +-----+         +----+                       +----+
  124.               |             |  |                         |  |
  125.        +---------+     +----+  +----+     +--------------+  +-----+
  126.        | VAUGHAN |     | AC |  | CO |     | UNIV-AVIGNON |  | AXA |
  127.        +---------+     +----+  +----+     +--------------+  +-----+
  128.           |              |        |              |             |
  129.       +------+    +---------+  +----------+   +-----+      +------+
  130.       | UNIX |    | NEWPORT |  | CITYDESK |   | SOL |      | MAIL |
  131.       +------+    +---------+  +----------+   +-----+      +------+
  132.                        |            |
  133.                     +----+       +-----+
  134.                     | NS |       | FTP |
  135.                     +----+       +-----+
  136.  
  137.  
  138.        1. Flat gTLD     2. Heirarchical country      3. Flat country
  139.  
  140.    In the example we see that the gTLDs are inherently flat, as
  141.    organisations are allocated domain names directly under the TLD.
  142.    With the country domains however, the domain allocation policy can
  143.    vary widely from country to country, and it does. Some may choose to
  144.    implement a functional sub-structure mirroring the gTLDs, some may
  145.    choose to implement a geographical sub-structure, and some may choose
  146.    to have no sub-structure at all.
  147.  
  148.    In the first case the organisation is clearly a commercial one, as it
  149.    is allocatged under the "COM" TLD. However, there is no information
  150.    as to the country the organisation is based in.  In the third case,
  151.    we know that the organisation is based in France (FR), but without
  152.    studying the actual organisation name we do not know what type of
  153.    organisation it is.  In the second case, we know the country that
  154.    both organisations are based in (UK), and by following the heirarchy,
  155.    we can deduce that the first is an academic organisation (AC), and
  156.    the second is commercial (CO).
  157.  
  158.    While the system is flexible in not enforcing a strict heirarchy, it
  159.    can lead to exhaustion of domain names in the generic space and lead
  160.    to conflicts between organisations who may both have a legitimate
  161.    claim to have a particular name.
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Vaughan                      Informational                      [Page 3]
  171.  
  172. RFC 2352   A Convention For Using Legal Names as Domain Names   May 1998
  173.  
  174.  
  175. 3.  Possible solutions to name exhaustion
  176.  
  177.    With such a flexible system, there are many ways of preventing the
  178.    name space being exhausted. A solution proposed by [2] is to create
  179.    more gTLDs to allow organisations with the same name to be registered
  180.    uniquely under different TLDs (FIRM, STORE, WEB, ARTS, REC, INFO and
  181.    NOM). However, this has several disadvantages as discussed below:
  182.  
  183.    a) It creates confusion in users mind as to what TLD refers to a
  184.       particular organisation. For example, MCDONALDS.COM maybe the fast
  185.       food corporation and MCDONALDS.FIRM maybe a firm of lawyers, but
  186.       how is the user supposed to know which is which?
  187.  
  188.    b) To prevent the above confusion, big corporations will simply
  189.       reserve all the different variations of the name, ie. IBM.COM,
  190.       IBM.FIRM, IBM.STORE etc. Thus we haven't solved the name
  191.       exhaustion or conflict problems, in fact we have made it worse.
  192.  
  193.    c) Names of legitimate trade mark holders or other legally held names
  194.       can still be acquired by anybody, leading to potential conflicts.
  195.  
  196.    Another set of possible solutions are discussed by The World
  197.    Intellectual Property Organisation [4] but this only addresses
  198.    dispute resolution when trademarks are used as domain names under
  199.    gTLDs, and not in the full legal context of their origin of
  200.    registration.
  201.  
  202. 4.  Proposed solution
  203.  
  204.    With the aforementioned problems in mind, it is not a good idea to
  205.    create new gTLDs which merely overlap the existing ones. As the
  206.    domain name system is heirarchical it would seem a good idea to
  207.    expand on the existing structure rather than creating several
  208.    duplicate structures.
  209.  
  210. 4.1 The world is not flat so why should domains be?
  211.  
  212.    With the expansion of the Internet to a truly global medium, the
  213.    notion that there can only be one commercial entity, one orgnisation,
  214.    and one network provider etc. with the same name seems impossible.
  215.    This is the situation that the present system finds itself in.  There
  216.    is a constantly spiralling number of disputes over who 'owns' or
  217.    'deserves' a certain name, with an increasing number ending in
  218.    unnecessary and costly legal action. This is not something that the
  219.    providers of a domain name service should concern themselves with,
  220.    but yet with the present system, this seems inevitable.
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Vaughan                      Informational                      [Page 4]
  227.  
  228. RFC 2352   A Convention For Using Legal Names as Domain Names   May 1998
  229.  
  230.  
  231. 4.2 The case for legal names
  232.  
  233.    This proposal allows for country-code-based domain names that are
  234.    related to legally registered names in the country (or locality,
  235.    state or province within that country) that they are based in, by
  236.    creating a functional heirarchy beneath the country TLD.
  237.  
  238.    This proposal does not seek to do away with gTLDs, but rather
  239.    suggests that a legal name should be sought first and then, if
  240.    desired, a generic name could be used alongside it. The organisation
  241.    would then, in case of any disputes, have a legally-held name which
  242.    no other organisation could have any claim to.
  243.  
  244.    This proposal has several advantages:
  245.  
  246.    a) The process of deciding what names belong to which organisation
  247.       is no longer a function of the domain name registry, but of the
  248.       company name or trade mark registration authority in the given
  249.       locality. This means that disputes over names cannot arise as all
  250.       names are unique within the context of the legal name.
  251.  
  252.    b) As all names are unique, there should be no exhaustion
  253.       (deliberately or otherwise) of 'desirable' names by other
  254.       concerns, as all the owners of legally-held names will
  255.       automatically have the right to the relevant domain name.
  256.  
  257. 4.3 Allocation of legal sub-domains
  258.  
  259.       The sub-domain identifiers should be created from the existing
  260.       indentifiers for company names and trade marks within the given
  261.       locality, state, province or country.
  262.  
  263.       The general form of such a sub-domain is:
  264.  
  265.       <legal-token>.<locality-identifier(s)>.<iso3166-country>
  266.  
  267.       For example:
  268.  
  269.       LTD.UK           for limited companies in the UK
  270.       PLC.UK           for public limited companies in the UK
  271.       TM.FR            for trademarks in France
  272.       INC.<state>.US   }
  273.       LTD.<state>.US   } for incorpated bodies in the US
  274.       CO.<state>.US    } (each is equivalent)
  275.       CORP.<state>.US  }
  276.       LLC.<state>.US   for limited liability companies in the US
  277.       GMBH.DE          for German companies
  278.  
  279.  
  280.  
  281.  
  282. Vaughan                      Informational                      [Page 5]
  283.  
  284. RFC 2352   A Convention For Using Legal Names as Domain Names   May 1998
  285.  
  286.  
  287.    The registry for the appropriate upper level country, state, province
  288.    or locality domain should create entries in these sub-domains based
  289.    on the laws for allocating such legal names in that particular
  290.    country, state, province or locality.  Specifically, the full legal
  291.    name should be used, but omitting the legal token (eg. Ltd, Corp,
  292.    etc.) as this will be determined by the choice of upper level domain.
  293.    ALL spaces within the name should be converted to hyphens '-' and
  294.    other punctuation either disregarded or also converted into hyphens.
  295.  
  296.    For holders of international trademarks and other international
  297.    names, the gTLD "INT" can be used in place of the country identifier.
  298.    For example:
  299.  
  300.       TM.INT  } for international trademarks
  301.       REG.INT }
  302.  
  303. 4.4 Allocation of miscellaneous sub-domains
  304.  
  305.    In countries that do not have existing sub-structure it is strongly
  306.    recommended that along with the creation of legal sub-domains
  307.    described here, that other sub-domains be created for commercial
  308.    entities, organisations, and academic entities to reduce remaining
  309.    conflicts from organisations that are not legally-registered.
  310.  
  311.    For example:
  312.                      +------------------+
  313.                   | ISO 3166 country | . . . . . . / / . .
  314.                   +------------------+        .           .
  315.                    |       |        |         .           .
  316.                +-----+  +-----+  +-----+   +-----+    +-------+
  317.                | AC/ |  | CO/ |  | OR/ |   | LTD |    | state |
  318.                | EDU |  | COM |  | ORG |   +-----+    +-------+
  319.                +-----+  +-----+  +-----+                  |
  320.                                                        +-----+
  321.                                                        | INC |
  322.                                                        +-----+
  323.  
  324.  
  325. 4.5 Identifiers in non-ASCII languages
  326.  
  327.    The representation of any domain element is limited to the ASCII
  328.    character set of alphabetic characters, digits and the hyphen, as
  329.    described in RFC 1035 [3]. The representation of names in languages
  330.    that use other character sets is limited by that definition or any
  331.    future update.
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Vaughan                      Informational                      [Page 6]
  339.  
  340. RFC 2352   A Convention For Using Legal Names as Domain Names   May 1998
  341.  
  342.  
  343. 4.6 Non-textual identifiers
  344.  
  345.    The registration of non-textual trade marks such as logos or three
  346.    dimensional shapes under this scheme is beyond the scope of this
  347.    document. It is unlikely that these marks will need to be used in the
  348.    way that domain names are used presently, but their use is not
  349.    explicitly prohibited.
  350.  
  351. 5.  Security Considerations
  352.  
  353.    This memo raises no issues relating to network security.  However,
  354.    when delegating entries in sub-domains, the registries must ensure
  355.    that the application contains sufficient evidence of the legal rights
  356.    to a given name.
  357.  
  358. 6.  References
  359.  
  360.    [1]  Postel J., and J. Reynolds , "Domain Requirements", RFC 920,
  361.         October 1984.
  362.  
  363.    [2]  "Generic Top Level Domains - Memoranding of Understanding",
  364.         <URL:http://www.gtld-mou.org/>
  365.  
  366.    [3]  Mockapetris, P., "Domain names - Implementation and
  367.         Specification", STD 13, RFC 1035, November 1987.
  368.  
  369.    [4]  "Trademarks and Internet Domain Names",
  370.         <URL:http://www.wipo.int/eng/internet/domains/>
  371.  
  372. 7.  Author's Address
  373.  
  374.    Owain Vaughan
  375.    Vaughan Enterprises
  376.    PO Box 155
  377.    Newport NP9 6YX
  378.    UK
  379.  
  380.    Phone: +44 1633 677849/822164
  381.    Fax:   +44 1633 663706
  382.    EMail: owain@vaughan.com
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Vaughan                      Informational                      [Page 7]
  395.  
  396. RFC 2352   A Convention For Using Legal Names as Domain Names   May 1998
  397.  
  398.  
  399. 8.  Full Copyright Statement
  400.  
  401.    Copyright (C) The Internet Society (1998).  All Rights Reserved.
  402.  
  403.    This document and translations of it may be copied and furnished to
  404.    others, and derivative works that comment on or otherwise explain it
  405.    or assist in its implementation may be prepared, copied, published
  406.    and distributed, in whole or in part, without restriction of any
  407.    kind, provided that the above copyright notice and this paragraph are
  408.    included on all such copies and derivative works.  However, this
  409.    document itself may not be modified in any way, such as by removing
  410.    the copyright notice or references to the Internet Society or other
  411.    Internet organizations, except as needed for the purpose of
  412.    developing Internet standards in which case the procedures for
  413.    copyrights defined in the Internet Standards process must be
  414.    followed, or as required to translate it into languages other than
  415.    English.
  416.  
  417.    The limited permissions granted above are perpetual and will not be
  418.    revoked by the Internet Society or its successors or assigns.
  419.  
  420.    This document and the information contained herein is provided on an
  421.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  422.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  423.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  424.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  425.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Vaughan                      Informational                      [Page 8]
  451.  
  452.