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

The information below is for an old version of the document
Document Type Active Internet-Draft (appsawg WG)
Last updated 2014-05-15 (latest revision 2014-04-22)
Replaces draft-nottingham-uri-get-off-my-lawn
Stream IETF
Intended RFC status Best Current Practice
Formats plain text pdf html bibtex
Reviews
Stream WG state Submitted to IESG for Publication
Document shepherd Martin Thomson
Shepherd write-up Show (last changed 2014-04-07)
IESG IESG state IESG Evaluation::AD Followup
Consensus Boilerplate Yes
Telechat date
Needs 8 more YES or NO OBJECTION positions to pass.
Responsible AD Barry Leiba
Send notices to appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-uri-get-off-my-lawn@tools.ietf.org, mt@mozilla.com
IANA IANA review state IANA OK - No Actions Needed
IANA action state None
appsawg                                                    M. Nottingham
Internet-Draft
Updates: 3986 (if approved)                               April 23, 2014
Intended status: Best Current Practice
Expires: October 25, 2014

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

Abstract

   RFC3986 Section 1.1.1 defines URI syntax as "a federated and
   extensible naming system wherein each scheme's specification may
   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 independent standards
   that mandate particular forms of URI substructure is inappropriate,
   because that essentially usurps ownership.  This document further
   describes this problematic practice and provides some acceptable
   alternatives for use in standards.

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 25, 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
   (http://trustee.ietf.org/license-info) in effect on the date of

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

   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Who This Document Is For  . . . . . . . . . . . . . . . .   3
     1.2.  Notational Conventions  . . . . . . . . . . . . . . . . .   4
   2.  Best Current Practices for Standardizing Structured URIs  . .   4
     2.1.  URI Schemes . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  URI Authorities . . . . . . . . . . . . . . . . . . . . .   4
     2.3.  URI Paths . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.4.  URI Queries . . . . . . . . . . . . . . . . . . . . . . .   5
     2.5.  URI Fragment Identifiers  . . . . . . . . . . . . . . . .   5
   3.  Alternatives to Specifying Structure in URIs  . . . . . . . .   6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

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 are mandated by a party other than the owner, however, it
   can have several potentially detrimental effects:

Show full document text