INTERNET-DRAFT R. Petke WorldCom Advanced Networks August 7, 1998 Some Alternatives to draft-ietf-urlreg-procedures-03 Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. This Internet Draft expires February 7, 1999. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract This document defines some alternatives to the registration trees described in draft-ietf-urlreg-procedures-03.txt, hereafter referred to as 'the current registration procedures draft'. 1.0 Introduction The current registration procedures draft, draft-ietf-urlreg-procedures-03.txt, specifies three registration trees in which new URL schemes can be registered: The IETF tree, the vendor tree, and the personal tree. This document proposes two possible replacements for the vendor and personal trees. The purpose of this draft is to publish those possible replacements such that attendees at the 42nd IETF meeting can come to the URLREG WG session prepared to discuss them and such that interested parties that cannot be present at the Chicago meeting may learn of the proposals and comment on them via the URLREG discussion list. 2.0 A Modified Vendor Tree The current registration procedures draft requires IANA to assign unique names to vendors who wish to register new URL scheme names with "vanity" appeal. The author sees this requirement on IANA as problematic. In essence, it recreates the whole domain name registration situation which has proven to be plagued with legal disputes. A simplified approach to this would be to just use a modified form of the vendor's existing domain name for the unique vendor name. While this approach does not resolve any legal disputes in the domain name arena, it does not create any new one outside of the domain name area. A prerequisite to using a domain name in a URL scheme name is owning the domain name. Yaron Goland's NOREG proposal originally introduced this concept but the author feels that his approach can be simplified to make the scheme names more cosmetically attractive without compromising integrity or future flexibility. The author's proposal is to keep the presence or absence of a period in the scheme name as the distinguishing factor between registrations in the IETF tree and non-IETF trees as specified in sections 2.2.4, 2.3.4, and 2.4.4 of draft-ietf-urlreg-procedures-03. Further, vanity names can be easily achieved by reversing the traditional order of a DNS string. For example, if Microsoft wishes to create a URL scheme for use with it's Office product, one possible vanity name for the scheme would be: "com.microsoft.office:". (Colon added for clarity.) Likewise, a vanity name for WorldCom Advanced Networks could be "net.wcom.fiber:". Other possibilities: edu.osu.cs463.student01: us.oh.columbus.freenet.hadtousetomakefreeequipmentwork: Note that it is the period between the TLD and the domain name that distinguishes these scheme names from scheme names in the IETF tree, not the current known list of TLDs. New TLDs may be created at any time without breaking this mechanism. Advantages of this naming scheme: o Vendors may create and register URL scheme names with as much vanity appeal, compactness, and uniqueness as their current domain name possesses. o Subtrees for each vendor are automatically available and are managed by the vendor themselves. o Mechanical registration process for IANA. Disadvantages of this naming scheme: o Dependence on DNS name strings. 3.0 Another Tree Possibility - Numeric OIDs Section 2.0 presents a way to utilize DNS names for vanity names in new URL scheme names. This section presents an alternative to DNS names by utilizing numeric OIDs for scheme names. Consider scheme names in the form of "." where is some string that (1) satisfies the requirement that the first character of an URL scheme name be alphabetic, and (2) distinguishes the scheme name as one that contains an OID; and is simply a numeric OID with dashes separating the field values. Possible examples: OID.2-16-840-1-113779-2-1: oid.2-16-840-1-113779-2-1-100: oiD.2-16-840-1-113779-3: Advantages: o Scheme names are guaranteed to be unique by a naming authority that isn't the IETF or IANA. o Mechanical registration process for IANA. o Scheme names can stay the same even if the owning entity changes it's name or is acquired by another entity. This is a feature inherent in using numbers rather than names but still worth mentioning because in today's world of mergers and spin-offs, who knows what DNS name the owner will have next year. My own company is a prime example. Within the span of less than 12 months we were CompuServe (compuserve.com), then CompuServe Network Services (compuserve.net), and now WorldCom Advanced Networks (wcom.net). Throughout it all, we have kept the same OID. Each time we change company name I just have ANSI change the name associated with the OID. Any URL scheme names built out of our OID would have stayed the same. o No trademark, copyright, or other "I claim that name" problems. o Subtrees for each vendor are automatically available and are managed by the vendor themselves. o Easily internationalized. Some DNS names don't translate well into other languages. o No real need to register schemes when you don't have associated documentation to publish. If I encounter a scheme built out of an OID and it's not registered, I can still find the owner. If I'm the owner and how the scheme works is none of anyone else's business, I don't need to register it because registration buys neither myself nor the community anything: I'm already unique and have a unique subtree at my disposal. If someone wants to send comments to me, do it through the contact information listed with the OID registration. If I want to publish information about my scheme, then I'll register with IANA and attach/reference the documentation. People can find me through either my IANA contact information or my OID contact information. Disadvantages: o No "vanity" names for entities. o If the DNS based vanity approach is also used, the string chosen for the OID prefix must be guaranteed to never become a TLD. 4.0 Author's Address Rich Petke WorldCom Advanced Networks 5000 Britton Road P. O. Box 5000 Hilliard, OH 43026-5000 USA Phone: +1 614 723 4157 Fax: +1 614 723 1333 EMail: rpetke@compuserve.net