[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01                                                         
Network Working Group                                          D. Thaler
Internet-Draft                                                 Microsoft
Intended status: Informational                          October 17, 2013
Expires: April 20, 2014


  Guidelines and Registration Procedures for New URI Schemes: Problem
                               Statement
                 draft-thaler-uri-scheme-reg-ps-01.txt

Abstract

   This document describes some problems with the existing guidelines
   and procedures, as documented in RFC 4395, for new URI schemes.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on April 20, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://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.





Thaler                   Expires April 20, 2014                 [Page 1]


Internet-Draft      New URI Schemes Problem Statement       October 2013


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Problems  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Current registration process doesn't scale well . . . . .   4
     2.2.  Lack of incentive to register . . . . . . . . . . . . . .   5
     2.3.  Current private scheme guidance causes conflicts  . . . .   5
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   5.  Informative References  . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   RFC 4395 [RFC4395] provides guidelines and recommendations for the
   definition of Uniform Resource Identifier (URI) schemes.  It defines
   procedures and guidelines for four types of URI schemes:

   a.  Permanent, which [RFC4395] requires for all IETF Standards-Track
       schemes, and which has strict requirements.

   b.  Provisional, which has a lower barrier.

   c.  Historical, which is for schemes no longer in use and hence
       generally does not apply to "new" URI schemes.

   d.  Private, meaning not registered with IANA.

   As explained in Section 1 of [RFC4395], the purpose of an IANA-
   maintained registry is to:

   1.  provide a central point of discovery for established URI scheme
       names, and easy location of their defining documents;

   2.  discourage use of the same URI scheme name for different
       purposes;

   3.  help those proposing new URI scheme names to discern established
       trends and conventions, and avoid names that might be confused
       with existing ones;

   4.  encourage registration by setting a low barrier for provisional
       registrations.

   However, the guidance in [RFC4395] is, in many cases that are now
   common, ambiguous or insufficient to accomplish the stated purposes.
   This document discusses a number of such problems.  In doing so, we
   note that an effort was started to update the guidance, in



Thaler                   Expires April 20, 2014                 [Page 2]


Internet-Draft      New URI Schemes Problem Statement       October 2013


   [I-D.ietf-iri-4395bis-irireg].  It does not, however, address the
   problems we discuss in this document, although it may be the logical
   place to do so.

   It is first important to understand the scale of the problem.  It is
   already common on many widely deployed platforms (including Windows,
   iOS, and Android) and form factors (PCs, phones, etc.) today to allow
   applications to be associated with specific URI schemes, such that
   when the URI is accessed (e.g., clicking on a link in a browser, or
   calling an equivalent API from an application), the associated
   application is launched to handle the URI.  That is, the application
   is given the URI and determines what action to take (as opposed to
   being given content that the URI points to).  Indeed, some such URIs
   are simply Uniform Resource Names that contain the data themselves,
   rather than Uniform Resource Locators that can be resolved to
   content.  As such, URIs are increasingly becoming a form of inter-
   process communication as a way to invoke another application, with
   arguments placed in the scheme-specific part of the URI.  Thus, in
   the extreme case, every application might define its own URI scheme,
   and the number of applications available on mainstream platforms
   today is easily numbered in the hundreds of thousands.

   This use of URIs can be viewed as different from the web.  That is,
   an increasingly larger portion of URI schemes are intended for
   "local" use, rather than for use with the web.  The "URI Generic
   Syntax" [RFC3986] explicitly allows for such a wide scope of use of
   URIs.  It states, in section 1.1:

      This specification does not limit the scope of what might be a
      resource; rather, the term "resource" is used in a general sense
      for whatever might be identified by a URI.  Familiar examples
      include an electronic document, an image, a source of information
      with a consistent purpose (e.g., "today's weather report for Los
      Angeles"), a service (e.g., an HTTP-to-SMS gateway), and a
      collection of other resources.  A resource is not necessarily
      accessible via the Internet; e.g., human beings, corporations, and
      bound books in a library can also be resources.  Likewise,
      abstract concepts can be resources, such as the operators and
      operands of a mathematical equation, the types of a relationship
      (e.g., "parent" or "employee"), or numeric values (e.g., zero,
      one, and infinity).

   and

      This specification does not place any limits on the nature of a
      resource, the reasons why an application might seek to refer to a
      resource, or the kinds of systems that might use URIs for the sake
      of identifying resources.



Thaler                   Expires April 20, 2014                 [Page 3]


Internet-Draft      New URI Schemes Problem Statement       October 2013


   The current process was designed based in part on joint
   recommendations from the W3C and IETF in 2002 [RFC3305], when the
   known uses of schemes were such that there were 34 registered
   schemes, 51 known publically documented but unregistered schemes, and
   50 or so private schemes with 2-3 being added every day, as noted
   (see Section 3.1 of [RFC3305]).  Such private growth has continued
   and expanded to more platforms since then, such that the public
   schemes are now probably a small minority.

2.  Problems

2.1.  Current registration process doesn't scale well

   Section 5.2 of [RFC4395] requires a four-week mailing list review for
   all Permanent registrations.  It is, however, ambiguous as to whether
   a mailing list review is required for Provisional registrations and
   if so, for how long.  The longer the process, the less of an
   incentive there is to register Provisional schemes.  This problem was
   discussed in 2010 by the IRI WG, which concluded that a mailing list
   review should not be required for Provisional schemes, only expert
   review which may take up to two weeks, but this conclusion has not
   yet been documented.

   The manual step of expert review still introduces a scalability
   bottleneck.  What if all new applications being submitted to an app
   store started sending requests for Provisional URI schemes?  The
   expert review process would be overwhelmed, especially if no one is
   paid to do the expert review.  As such, the goals stated in Section 1
   become far less effective when registered schemes are only a tiny
   fraction of the URI schemes in use in practice.

   The author ran an experiment in 2012, which was reported to the IRI
   WG at its final meeting at IETF 85, where over 75 schemes that were
   listed on Wikipedia as being unregistered but in use were submitted
   as third-party registrations.  All of them were registered after two
   weeks had passed and it was pointed out that the deadline had expired
   and per the process in [RFC4395], must be automatically listed.  The
   only noticeable outcome of the expert review, other than to introduce
   a two week delay and manual effort, was to add a warning about the
   unknown security impact of one scheme.  This is not intended to imply
   that the expert review was not valuable, only that the value provided
   could not scale effectively if the process were stressed with the
   current potential demand.

   In summary, [RFC4395] defines a set of goals, which we listed above
   in Section 1.  The current mechanism does not meet those goals.  To
   meet the stated goals would require the majority of schemes to be
   registered.  The current process cannot scale to do so, given current



Thaler                   Expires April 20, 2014                 [Page 4]


Internet-Draft      New URI Schemes Problem Statement       October 2013


   practice.  Hence, we either need to change the goals, or change the
   process, or both.

2.2.  Lack of incentive to register

   Currently there is little incentive for an organization outside the
   IETF to register schemes (whether as Permanent, Provisional, or
   Historical).  Registering introduces a cost, both in terms of manual
   effort needed to apply, but also in the time delay introduced.  This
   cost must be weighed against the benefit, which is primarily to
   simply lower the risk of collision.  (Another benefit is to provide
   ease of access to relevant documentation via the IANA registry,
   although this benefit is often seen as unimportant or even
   undesirable in some cases.)

   As long as the risk of collision is perceived to be low, or the
   effect of collision considered to be acceptable (e.g., asking the
   user which app to launch), registration is bypassed in favor of a
   "Private" scheme.  The effect of collision can of course be
   problematic (though the scheme-defining organization may not realize
   the danger) when the syntax of the scheme-specific part differs.
   Launching an application with a URI that is invalid according to that
   application's syntax for the custom URI scheme is not useful.

   An app store certification process could in theory require or
   encourage Provisional application.  However, there is little
   incentive for them to do so either, since an app store itself has a
   process which would be delayed and disincent application developers
   to submit applications.

2.3.  Current private scheme guidance causes conflicts

   Section 2.8 of [RFC4395] states:

      Organizations that desire a private name space for URI scheme
      names are encouraged to use a prefix based on their domain name,
      expressed in reverse order.  For example, a URI scheme name of
      com-example-info might be registered by the vendor that owns the
      example.com domain name.

   There are multiple problems with the above guidance:

   1.  No guidance is given for when it might or might not be
       appropriate to use a private name space.  For example, is this
       guidance appropriate for application vendors defining a custom
       scheme that they want to associate the application with?  As
       such, the current assumption is that it is appropriate for anyone
       who can live with some potential risk of collision.



Thaler                   Expires April 20, 2014                 [Page 5]


Internet-Draft      New URI Schemes Problem Statement       October 2013


   2.  Hyphens occur in actual domain names.  Consider one organization
       that owns the domain name "foo.bar.example", and another
       organization that owns "foo-bar.example".  Using the mechanism
       implied in the example can result in both colliding with
       "example-bar-foo-info".

   3.  The guidance is only an encouragement, and no precise algorithm
       is given.  For example, whether "." should be converted to "-" as
       in the example is unclear.  If an organization is actually trying
       to follow the recommended guidelines, they will likely use a "-"
       as directed and risk conflicts as noted above.  More commonly, an
       organization today will simply use a string that identifies (say)
       their application, and not be based on a domain name.

   4.  No protection is suggested against IANA later granting
       registration to a scheme that follows the recommended convention
       that is in use by someone else.  For example, as can be seen at
       [IANAURI], there are already registered schemes that use "."
       (e.g., "iris.beep") and "-" (e.g., "xcon-userid") in them, and
       there could be similar new schemes registered at any time.  If an
       organization had previously acquired the TLD "iris" or "xcon",
       those values could already be in use in applications from those
       organizations.  Especially now that ICANN is allowing gTLD
       applications, this is a very real possibility.

3.  Security Considerations

   The security considerations in [RFC4395] still apply.

4.  IANA Considerations

   This document requires no actions by the IANA.

5.  Informative References

   [I-D.ietf-iri-4395bis-irireg]
              Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
              Registration Procedures for New URI/IRI Schemes", draft-
              ietf-iri-4395bis-irireg-04 (work in progress), December
              2011.

   [IANAURI]  IANA, ., "Uniform Resource Identifier (URI) Schemes",
              2013, <http://www.iana.org/assignments/uri-schemes/uri-
              schemes.xhtml>.

   [RFC3305]  Mealling, M. and R. Denenberg, "Report from the Joint W3C/
              IETF URI Planning Interest Group: Uniform Resource
              Identifiers (URIs), URLs, and Uniform Resource Names



Thaler                   Expires April 20, 2014                 [Page 6]


Internet-Draft      New URI Schemes Problem Statement       October 2013


              (URNs): Clarifications and Recommendations", RFC 3305,
              August 2002.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66, RFC
              3986, January 2005.

   [RFC4395]  Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
              Registration Procedures for New URI Schemes", BCP 35, RFC
              4395, February 2006.

Author's Address

   Dave Thaler
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052
   USA

   Phone: +1 425 703 8835
   Email: dthaler@microsoft.com






























Thaler                   Expires April 20, 2014                 [Page 7]