[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
INTERNET-DRAFT                                                 R. Petke
<draft-ietf-urlreg-alternatives-00.txt>      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 "<oid-prefix>.<numeric-oid>"

   where

   <oid-prefix> 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

   <numeric-oid> 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