Standardising Structure in URIs
draft-ietf-appsawg-uri-get-off-my-lawn-00

The information below is for an old version of the document
Document Type Active Internet-Draft (appsawg WG)
Last updated 2013-09-17
Replaces draft-nottingham-uri-get-off-my-lawn
Stream IETF
Intended RFC status (None)
Formats plain text pdf html bibtex
Reviews
Stream WG state WG Document
Document shepherd Martin Thomson
IESG IESG state I-D Exists
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                      M. Nottingham
Internet-Draft                                        September 17, 2013
Updates: 3986 (if approved)
Intended status: BCP
Expires: March 21, 2014

                    Standardising Structure in URIs
               draft-ietf-appsawg-uri-get-off-my-lawn-00

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 March 21, 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 March 21, 2014                 [Page 1]
Internet-Draft           URI Structure Policies           September 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 Standardising 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.  Acknowledgments  . . . . . . . . . . . . . . . . . . . 8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8

Nottingham               Expires March 21, 2014                 [Page 2]
Internet-Draft           URI Structure Policies           September 2013

1.  Introduction

   URIs [RFC3986] very often include structured application data.  This
   might include artifacts from filesystems (often occurring 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