Standardising Structure in URIs
draft-nottingham-uri-get-off-my-lawn-01

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Last updated 2013-08-07
Replaced by RFC 7320, RFC 7320
Stream (None)
Intended RFC status (None)
Formats pdf htmlized (tools) htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                      M. Nottingham
Internet-Draft                                            August 7, 2013
Updates: 3986 (if approved)
Intended status: BCP
Expires: February 8, 2014

                    Standardising Structure in URIs
                draft-nottingham-uri-get-off-my-lawn-01

Abstract

   Sometimes, it is attractive to add features to protocols or
   applications by specifying a particular structure for URIs (or parts
   thereof).  This document cautions against this practice in standards
   (sometimes called "URI Squatting").

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 February 8, 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.

Nottingham              Expires February 8, 2014                [Page 1]
Internet-Draft           URI Structure Policies              August 2013

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Who This Document Is For  . . . . . . . . . . . . . . . . . 4
     1.2.  Notational Conventions  . . . . . . . . . . . . . . . . . . 5
   2.  Best Current Practices for Standarising Structured URIs . . . . 5
     2.1.  URI Schemes . . . . . . . . . . . . . . . . . . . . . . . . 5
     2.2.  URI Authorities . . . . . . . . . . . . . . . . . . . . . . 5
     2.3.  URI Paths . . . . . . . . . . . . . . . . . . . . . . . . . 5
     2.4.  URI Queries . . . . . . . . . . . . . . . . . . . . . . . . 5
     2.5.  URI Fragment Identifiers  . . . . . . . . . . . . . . . . . 6
   3.  Alternatives to Specifying Static URIs  . . . . . . . . . . . . 6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Appendix A.  Acknowlegements  . . . . . . . . . . . . . . . . . . . 8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8

Nottingham              Expires February 8, 2014                [Page 2]
Internet-Draft           URI Structure Policies              August 2013

1.  Introduction

   URIs [RFC3986] very often include structure and application data.
   This might include artefacts from filesystems (often occuring in the
   path component), and user information (often in the query component).
   In some cases, there can even be application-specific data in the
   authority component (e.g., some applications are spread across
   several hostnames to enable a form of partitioning or dispatch).

   Furthermore, constraints upon the structure of URIs can be imposed by
   an implementation; for example, many Web servers use the filename
   extension of the last path segment to determine the media type of the
   response.  Likewise, pre-packaged applications often have highly
   structured URIs that can only be changed in limited ways (often, just
   the hostname and port they are deployed upon).

   Because the owner of the URI is choosing to use the server or the
   software, this can be seen as reasonable delegation of authority.
   When such conventions are mandated by standards, however, it can have
   several potentially detrimental effects:

   o  Collisions - As more conventions for URI structure become
      standardised, it becomes more likely that there will be collisions
      between such conventions (especially considering that servers,
      applications and individual deployments will have their own
      conventions).
   o  Dilution - Adorning URIs with extra information to support new
Show full document text