RFC 2352

A Convention For Using Legal Names as Domain Names

📅 published May 1998, from ietf

Okay bestie, this one is by O. Vaughan from Vaughan Enterprises, dated May 1998. It's marked Informational (so it's not a standard, just a proposal to think about) and it obsoletes RFC 2240 🎀

Status of this Memo ✨

This memo gives information to the Internet community. It is not an Internet standard of any kind, and it can be distributed without limits 🌸

Copyright (C) The Internet Society (1998). All Rights Reserved.

RFC Editor's Note 🙈

This is an independent submission, so it's not an official standards-track thing. It talks about a possible way to give out domain names based on corporate and other names that are registered by law.

Real talk: this idea seems to need companies to swap their familiar domains for much longer handles, like changing cisco.com to cisco-systems.co.ca.us or ibm.com to international-business-machines.co.ny.us. Nobody gets a reason to do that unless something changes, like phasing out the .com and .net gTLDs. It also seems to dictate how each national registry organises its own namespace, which the document itself says is up to each country and not for global standards to decide 😬

The Editor's Note also says it may not be politically feasible to put this into practice 💀

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 ✨

This memo is all about getting people talking. The big problems it's looking at are the top level domain space running out of names, and the fights that happen when lots of organisations want the same name. The solutions in here are meant as a starting framework 🦋 The hope is that everyone eventually agrees on the best fix for each problem, and that this leads to real standards down the road.

2. Overview of the domain space 🌈

Right now the domain space is a hierarchical, tree-shaped namespace with several top level domains (TLDs) and sub-domains hanging off them. The original TLDs and the reasoning behind them are written up in RFC 920 [1].

The TLDs split into two groups: generic top-level domains (gTLDs), and two-letter ISO 3166 country domains for every country that has Internet connectivity. Who gets sub-domains under a TLD is completely up to that TLD's registry. A registry can add more levels of structure, or it can just hand out domains in a flat way 💅

Here's an 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

So in the example, gTLDs are naturally flat, because organisations get names right under the TLD. Country domains are a different story. Their allocation policy can differ wildly from one country to the next, and it really does. Some countries copy the gTLD functional structure underneath, some go geographical, and some have no structure at all 🍓

In the first case, the organisation is obviously commercial, since it sits under "COM". But there's no clue about what country it's in. In the third case we know it's based in France (FR), but without looking at the organisation's actual name we can't tell what kind of organisation it is. In the second case we know both organisations are in the UK, and by following the hierarchy we can work out that the first one is academic (AC) and the second one is commercial (CO) 🧠

The system is flexible because it doesn't force one strict hierarchy, but that same flexibility can use up names in the generic space and cause fights between organisations that both have a fair claim to the same name 😭

3. Possible solutions to name exhaustion 💜

With a system that flexible, there are lots of ways the name space could get used up. One idea from [2] is to add more gTLDs, so organisations with the same name can be registered separately under different TLDs (FIRM, STORE, WEB, ARTS, REC, INFO and NOM). The catch is that this has some real downsides, which are covered below:

a) It confuses users about which TLD goes with which organisation. For example, MCDONALDS.COM might be the fast food corporation while MCDONALDS.FIRM might be a law firm, and how is anyone supposed to tell them apart? 🍔

b) To stop that confusion, big corporations will just reserve every variation of their name, like IBM.COM, IBM.FIRM, IBM.STORE and so on. So we haven't fixed name exhaustion or conflicts. We've honestly made them worse 😩

c) Names that legitimate trademark holders or other legally held names rely on can still be grabbed by anybody, which leads to possible conflicts.

Another group of possible solutions is discussed by The World Intellectual Property Organisation [4], but that only deals with disputes when trademarks are used as domain names under gTLDs. It doesn't look at the full legal context where the names came from and were registered.

4. Proposed solution 🎀

With those problems in mind, creating new gTLDs that just overlap the existing ones is not a good idea. Since the domain name system is hierarchical, it makes more sense to build on the existing structure instead of making several duplicate ones 👑

4.1. The world is not flat so why should domains be? 🌍

The Internet has become a truly global medium, so the idea that only one commercial entity, one organisation, and one network provider can have a given name seems impossible now. That's where the current system is stuck. Disputes over who "owns" or "deserves" a certain name keep piling up, and more and more of them end in expensive legal action. A domain name service provider shouldn't have to deal with this, but under the current system it seems unavoidable 😤

This proposal allows country-code-based domain names that match legally registered names in the country (or in the locality, state or province within that country) where the organisation is based. It does this by creating a functional hierarchy underneath the country TLD.

It doesn't try to get rid of gTLDs. Instead it suggests that an organisation should first look for its legal name, and then, if it wants, add a generic name alongside it. That way, if a dispute ever happens, the organisation has a legally held name that no other organisation could claim 💖

This proposal has a few advantages:

a) Deciding which names belong to which organisation stops being the domain name registry's job, and becomes the job of the company name or trademark registration authority in that locality. That means disputes over names shouldn't come up, because every name is unique within its legal context 🫶

b) Since all names are unique, nobody should be able to exhaust (on purpose or by accident) the "desirable" names. Every owner of a legally held name will automatically have the right to the matching domain name 🦋

The sub-domain identifiers should be built from the existing identifiers for company names and trademarks in the given locality, state, province or country.

The general form of such a sub-domain is:

<legal-token>.<locality-identifier(s)>.<iso3166-country>

For example:

LTD.UK           for limited companies in the UK
PLC.UK           for public limited companies in the UK
TM.FR            for trademarks in France
INC.<state>.US   }
LTD.<state>.US   } for incorpated bodies in the US
CO.<state>.US    } (each is equivalent)
CORP.<state>.US  }
LLC.<state>.US   for limited liability companies in the US
GMBH.DE          for German companies

The registry for the right upper level country, state, province or locality domain should create entries in these sub-domains based on that place's laws for allocating legal names. Specifically, the full legal name should be used, but the legal token (eg. Ltd, Corp, etc.) gets left out, since the choice of upper level domain already determines it. ALL spaces within the name should be converted to hyphens '-', and other punctuation should either be disregarded or also turned into hyphens ✨

For holders of international trademarks and other international names, the gTLD "INT" can stand in for the country identifier. For example:

TM.INT  } for international trademarks
REG.INT }

4.4 Allocation of miscellaneous sub-domains 💅

okay so in countries that don't already have any sub-structure, it is strongly recommended that they create other sub-domains alongside the legal ones 🎀. These are for commercial entities, organisations, and academic entities, and they cut down on clashes from organisations that aren't legally registered. 🫶

For example:

                 +------------------+
              | ISO 3166 country | . . . . . . / / . .
              +------------------+        .           .
               |       |        |         .           .
           +-----+  +-----+  +-----+   +-----+    +-------+
           | AC/ |  | CO/ |  | OR/ |   | LTD |    | state |
           | EDU |  | COM |  | ORG |   +-----+    +-------+
           +-----+  +-----+  +-----+                  |
                                                   +-----+
                                                   | INC |
                                                   +-----+

4.5 Identifiers in non-ASCII languages 🌸

bestie, this one's a little strict 😭 Every domain element has to stick to the ASCII set: letters, digits, and the hyphen, as laid out in RFC 1035 [3]. Names written in languages that use other character sets are bound by that same rule, or by whatever future update comes along. 🧚

4.6 Non-textual identifiers 🦋

Logos and three-dimensional shapes registered as non-textual trade marks are outside what this document covers. honestly these probably won't get used the way domain names are used today 🙈 They aren't banned, though, so they're not explicitly prohibited. ✨

5. Security Considerations 🔥

Okay, this part is serious, so listen up 💀 This memo doesn't raise any issues for network security. BUT when registries delegate entries in sub-domains, they must make sure the application has enough evidence of the legal rights to the name being requested. No shortcuts, periodt. 👑

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", STD 13, RFC 1035, November 1987.

[4] "Trademarks and Internet Domain Names", <URL:http://www.wipo.int/eng/internet/domains/>

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

Copyright (C) The Internet Society (1998). 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. 💜

📦 where this page comes from