idnits 2.17.1 draft-ietf-urlreg-alternatives-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 31 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 206 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 7, 1998) is 9386 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. Petke 2 WorldCom Advanced Networks 3 August 7, 1998 5 Some Alternatives to draft-ietf-urlreg-procedures-03 7 Status of this Memo 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its areas, 11 and its working groups. Note that other groups may also distribute 12 working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six 15 months and may be updated, replaced, or obsoleted by other documents 16 at any time. It is inappropriate to use Internet-Drafts as 17 reference material or to cite them other than as "work in progress." 19 To view the entire list of current Internet-Drafts, please check the 20 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 21 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 22 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 23 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 25 Distribution of this memo is unlimited. 27 This Internet Draft expires February 7, 1999. 29 Copyright Notice 31 Copyright (C) The Internet Society (1998). All Rights Reserved. 33 Abstract 35 This document defines some alternatives to the registration trees 36 described in draft-ietf-urlreg-procedures-03.txt, hereafter referred 37 to as 'the current registration procedures draft'. 39 1.0 Introduction 41 The current registration procedures draft, 42 draft-ietf-urlreg-procedures-03.txt, specifies three registration 43 trees in which new URL schemes can be registered: The IETF tree, 44 the vendor tree, and the personal tree. 46 This document proposes two possible replacements for the vendor and 47 personal trees. 49 The purpose of this draft is to publish those possible replacements 50 such that attendees at the 42nd IETF meeting can come to the URLREG 51 WG session prepared to discuss them and such that interested parties 52 that cannot be present at the Chicago meeting may learn of the 53 proposals and comment on them via the URLREG discussion list. 55 2.0 A Modified Vendor Tree 57 The current registration procedures draft requires IANA to assign 58 unique names to vendors who wish to register new URL scheme names 59 with "vanity" appeal. The author sees this requirement on IANA as 60 problematic. In essence, it recreates the whole domain name 61 registration situation which has proven to be plagued with legal 62 disputes. 64 A simplified approach to this would be to just use a modified form 65 of the vendor's existing domain name for the unique vendor name. 66 While this approach does not resolve any legal disputes in the 67 domain name arena, it does not create any new one outside of the 68 domain name area. A prerequisite to using a domain name in a URL 69 scheme name is owning the domain name. 71 Yaron Goland's NOREG proposal originally introduced this concept but 72 the author feels that his approach can be simplified to make the 73 scheme names more cosmetically attractive without compromising 74 integrity or future flexibility. 76 The author's proposal is to keep the presence or absence of a period 77 in the scheme name as the distinguishing factor between 78 registrations in the IETF tree and non-IETF trees as specified in 79 sections 2.2.4, 2.3.4, and 2.4.4 of draft-ietf-urlreg-procedures-03. 81 Further, vanity names can be easily achieved by reversing the 82 traditional order of a DNS string. For example, if Microsoft wishes 83 to create a URL scheme for use with it's Office product, one 84 possible vanity name for the scheme would be: 85 "com.microsoft.office:". (Colon added for clarity.) Likewise, a 86 vanity name for WorldCom Advanced Networks could be 87 "net.wcom.fiber:". Other possibilities: 89 edu.osu.cs463.student01: 90 us.oh.columbus.freenet.hadtousetomakefreeequipmentwork: 92 Note that it is the period between the TLD and the domain name that 93 distinguishes these scheme names from scheme names in the IETF tree, 94 not the current known list of TLDs. New TLDs may be created at any 95 time without breaking this mechanism. 97 Advantages of this naming scheme: 99 o Vendors may create and register URL scheme names with as much 100 vanity appeal, compactness, and uniqueness as their current 101 domain name possesses. 103 o Subtrees for each vendor are automatically available and are 104 managed by the vendor themselves. 106 o Mechanical registration process for IANA. 108 Disadvantages of this naming scheme: 110 o Dependence on DNS name strings. 112 3.0 Another Tree Possibility - Numeric OIDs 114 Section 2.0 presents a way to utilize DNS names for vanity names in 115 new URL scheme names. This section presents an alternative to DNS 116 names by utilizing numeric OIDs for scheme names. 118 Consider scheme names in the form of "." 120 where 122 is some string that (1) satisfies the requirement that 123 the first character of an URL scheme name be alphabetic, and 124 (2) distinguishes the scheme name as one that contains an OID; and 126 is simply a numeric OID with dashes separating the 127 field values. 129 Possible examples: 131 OID.2-16-840-1-113779-2-1: 132 oid.2-16-840-1-113779-2-1-100: 133 oiD.2-16-840-1-113779-3: 135 Advantages: 137 o Scheme names are guaranteed to be unique by a naming authority 138 that isn't the IETF or IANA. 140 o Mechanical registration process for IANA. 142 o Scheme names can stay the same even if the owning entity changes 143 it's name or is acquired by another entity. This is a feature 144 inherent in using numbers rather than names but still worth 145 mentioning because in today's world of mergers and spin-offs, who 146 knows what DNS name the owner will have next year. My own 147 company is a prime example. Within the span of less than 12 148 months we were CompuServe (compuserve.com), then CompuServe 149 Network Services (compuserve.net), and now WorldCom Advanced 150 Networks (wcom.net). Throughout it all, we have kept the same 151 OID. Each time we change company name I just have ANSI change 152 the name associated with the OID. Any URL scheme names built out 153 of our OID would have stayed the same. 155 o No trademark, copyright, or other "I claim that name" problems. 157 o Subtrees for each vendor are automatically available and are 158 managed by the vendor themselves. 160 o Easily internationalized. Some DNS names don't translate well 161 into other languages. 163 o No real need to register schemes when you don't have associated 164 documentation to publish. If I encounter a scheme built out of 165 an OID and it's not registered, I can still find the owner. If 166 I'm the owner and how the scheme works is none of anyone else's 167 business, I don't need to register it because registration buys 168 neither myself nor the community anything: I'm already unique 169 and have a unique subtree at my disposal. If someone wants to 170 send comments to me, do it through the contact information listed 171 with the OID registration. If I want to publish information 172 about my scheme, then I'll register with IANA and 173 attach/reference the documentation. People can find me through 174 either my IANA contact information or my OID contact information. 176 Disadvantages: 178 o No "vanity" names for entities. 180 o If the DNS based vanity approach is also used, the string chosen 181 for the OID prefix must be guaranteed to never become a TLD. 183 4.0 Author's Address 185 Rich Petke 186 WorldCom Advanced Networks 187 5000 Britton Road 188 P. O. Box 5000 189 Hilliard, OH 43026-5000 190 USA 192 Phone: +1 614 723 4157 193 Fax: +1 614 723 1333 194 EMail: rpetke@compuserve.net