URI Design and Ownership
draft-ietf-appsawg-uri-get-off-my-lawn-02

The information below is for an old version of the document
Document Type Active Internet-Draft (appsawg WG)
Last updated 2014-04-02
Replaces draft-nottingham-uri-get-off-my-lawn
Stream IETF
Intended RFC status (None)
Formats plain text pdf html bibtex
Reviews
Stream WG state Waiting for WG Chair Go-Ahead
Revised I-D Needed - Issue raised by WGLC, Doc Shepherd Follow-up Underway
Document shepherd Martin Thomson
Shepherd write-up Show (last changed 2014-01-28)
IESG IESG state I-D Exists
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
appsawg                                                    M. Nottingham
Internet-Draft                                             April 3, 2014
Updates: 3986 (if approved)
Intended status: BCP
Expires: October 5, 2014

                        URI Design and Ownership
               draft-ietf-appsawg-uri-get-off-my-lawn-02

Abstract

   RFC3986 Section 3.1 defines URI syntax as "a federated and extensible
   naming system my further restrict the syntax and semantics of
   identifiers using that scheme."  In other words, the structure of a
   URI is defined by its scheme.  While it is common for schemes to
   further delegate their substructure to the URI's owner, publishing
   standards that mandate particular forms of URI substructure is
   inappropriate, because the effectively usurps ownership.

   This document is intended to prevent this practice (sometimes called
   "URI Squatting") in standards, but updating RFC3986 to indicate where
   it is acceptable.

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 October 5, 2014.

Copyright Notice

   Copyright (c) 2014 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

Nottingham               Expires October 5, 2014                [Page 1]
Internet-Draft            URI Design Ownership                April 2014

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Who This Document Is For  . . . . . . . . . . . . . . . . . 4
     1.2.  Notational Conventions  . . . . . . . . . . . . . . . . . . 4
   2.  Best Current Practices for Standardizing Structured URIs  . . . 4
     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.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     5.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     5.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . 7
   Appendix B.  Alternatives to Specifying Structure in URIs . . . . . 7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8

Nottingham               Expires October 5, 2014                [Page 2]
Internet-Draft            URI Design Ownership                April 2014

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 (as defined in [webarch] Section
   2.2.2.1) is choosing to use the server or the software, this can be
   seen as reasonable delegation of authority.  When such conventions
Show full document text