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

  Guidelines and Registration Procedures for New URI Schemes: Problem


   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 13, 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 13, 2014                 [Page 1]

Internet-Draft      New URI Schemes Problem Statement       October 2013

Table of Contents

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

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

   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

   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.

Thaler                   Expires April 13, 2014                 [Page 2]

Internet-Draft      New URI Schemes Problem Statement       October 2013

   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) today to allow applications to be associated with
   specific URI schemes, such that when the URI is accessed, 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 at least.

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 by the IRI WG, which concluded that a mailing list review
   is not required for Provisional schemes, only expert review which may
   take up to two weeks.

   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 2010, 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

Thaler                   Expires April 13, 2014                 [Page 3]

Internet-Draft      New URI Schemes Problem Statement       October 2013

   could not scale effectively if the process were stressed with the
   current potential demand.

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 primary 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 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 use), 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 13, 2014                 [Page 4]

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

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

   [IANAURI]  IANA, "Uniform Resource Identifier (URI) Schemes", <http://

   [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

Thaler                   Expires April 13, 2014                 [Page 5]

Internet-Draft      New URI Schemes Problem Statement       October 2013

   Dave Thaler
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052

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

Thaler                   Expires April 13, 2014                 [Page 6]