idnits 2.17.1
draft-nottingham-uri-get-off-my-lawn-02.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
-- The draft header indicates that this document updates RFC3986, but the
abstract doesn't seem to mention this, which it should.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
(Using the creation date from RFC3986, updated by this document, for
RFC5378 checks: 2002-11-01)
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (August 29, 2013) is 3886 days in the past. Is this
intentional?
Checking references for intended status: Best Current Practice
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Obsolete normative reference: RFC 4395 (Obsoleted by RFC 7595)
-- Obsolete informational reference (is this intentional?): RFC 4844
(Obsoleted by RFC 8729)
-- Obsolete informational reference (is this intentional?): RFC 5785
(Obsoleted by RFC 8615)
-- Obsolete informational reference (is this intentional?): RFC 5988
(Obsoleted by RFC 8288)
Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 6 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group M. Nottingham
3 Internet-Draft August 29, 2013
4 Updates: 3986 (if approved)
5 Intended status: BCP
6 Expires: March 2, 2014
8 Standardising Structure in URIs
9 draft-nottingham-uri-get-off-my-lawn-02
11 Abstract
13 Sometimes, it is attractive to add features to protocols or
14 applications by specifying a particular structure for URIs (or parts
15 thereof). This document cautions against this practice in standards
16 (sometimes called "URI Squatting").
18 Status of this Memo
20 This Internet-Draft is submitted in full conformance with the
21 provisions of BCP 78 and BCP 79.
23 Internet-Drafts are working documents of the Internet Engineering
24 Task Force (IETF). Note that other groups may also distribute
25 working documents as Internet-Drafts. The list of current Internet-
26 Drafts is at http://datatracker.ietf.org/drafts/current/.
28 Internet-Drafts are draft documents valid for a maximum of six months
29 and may be updated, replaced, or obsoleted by other documents at any
30 time. It is inappropriate to use Internet-Drafts as reference
31 material or to cite them other than as "work in progress."
33 This Internet-Draft will expire on March 2, 2014.
35 Copyright Notice
37 Copyright (c) 2013 IETF Trust and the persons identified as the
38 document authors. All rights reserved.
40 This document is subject to BCP 78 and the IETF Trust's Legal
41 Provisions Relating to IETF Documents
42 (http://trustee.ietf.org/license-info) in effect on the date of
43 publication of this document. Please review these documents
44 carefully, as they describe your rights and restrictions with respect
45 to this document. Code Components extracted from this document must
46 include Simplified BSD License text as described in Section 4.e of
47 the Trust Legal Provisions and are provided without warranty as
48 described in the Simplified BSD License.
50 Table of Contents
52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
53 1.1. Who This Document Is For . . . . . . . . . . . . . . . . . 4
54 1.2. Notational Conventions . . . . . . . . . . . . . . . . . . 5
55 2. Best Current Practices for Standardising Structured URIs . . . 5
56 2.1. URI Schemes . . . . . . . . . . . . . . . . . . . . . . . . 5
57 2.2. URI Authorities . . . . . . . . . . . . . . . . . . . . . . 5
58 2.3. URI Paths . . . . . . . . . . . . . . . . . . . . . . . . . 5
59 2.4. URI Queries . . . . . . . . . . . . . . . . . . . . . . . . 5
60 2.5. URI Fragment Identifiers . . . . . . . . . . . . . . . . . 6
61 3. Alternatives to Specifying Static URIs . . . . . . . . . . . . 6
62 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
65 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7
66 6.2. Informative References . . . . . . . . . . . . . . . . . . 7
67 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 8
68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
70 1. Introduction
72 URIs [RFC3986] very often include structured application data. This
73 might include artifacts from filesystems (often occurring in the path
74 component), and user information (often in the query component). In
75 some cases, there can even be application-specific data in the
76 authority component (e.g., some applications are spread across
77 several hostnames to enable a form of partitioning or dispatch).
79 Furthermore, constraints upon the structure of URIs can be imposed by
80 an implementation; for example, many Web servers use the filename
81 extension of the last path segment to determine the media type of the
82 response. Likewise, pre-packaged applications often have highly
83 structured URIs that can only be changed in limited ways (often, just
84 the hostname and port they are deployed upon).
86 Because the owner of the URI is choosing to use the server or the
87 software, this can be seen as reasonable delegation of authority.
88 When such conventions are mandated by standards, however, it can have
89 several potentially detrimental effects:
91 o Collisions - As more conventions for URI structure become
92 standardised, it becomes more likely that there will be collisions
93 between such conventions (especially considering that servers,
94 applications and individual deployments will have their own
95 conventions).
96 o Dilution - Adorning URIs with extra information to support new
97 standard features dilutes their usefulness as identifiers when
98 that information is ephemeral (as URIs ought to be stable; see
99 [webarch] Section 3.5.1), or its inclusion causes several
100 alternate forms of the URI to exist (see [webarch] Section 2.3.1).
101 o Brittleness - A standard that specifies a static URI cannot change
102 its form in future revisions.
103 o Operational Difficulty - Supporting some URI conventions can be
104 difficult in some implementations. For example, specifying that a
105 particular query parameter be used precludes the use of Web
106 servers that serve the response from a filesystem. Likewise, an
107 application that fixes a base path for its operation (e.g., "/v1")
108 makes it impossible to deploy other applications with the same
109 prefix on the same host.
110 o Client Assumptions - When conventions are standardised, some
111 clients will inevitably assume that the standards are in use when
112 those conventions are seen. This can lead to interoperability
113 problems; for example, if a specification documents that the "sig"
114 URI query parameter indicates that its payload is a cryptographic
115 signature for the URI, it can lead to false positives.
117 While it is not ideal when a server or a deployed application
118 constrains URI structure (indeed, this is not recommended practice,
119 but that discussion is out of scope for this document), publishing
120 standards that mandate URI structure is inappropriate because the
121 structure of a URI needs to be firmly under the control of its owner,
122 and the IETF (as well as other organisations) should not usurp this
123 ownership; see [webarch] Section 2.2.2.1.
125 This document explains best current practices for establishing URI
126 structures, conventions and formats in standards. It also offers
127 strategies for specifications to avoid violating these guidelines in
128 Section 3.
130 1.1. Who This Document Is For
132 These guidelines are IETF Best Current Practice, and are therefore
133 binding upon IETF standards-track documents, as well as submissions
134 to the RFC Editor on the Independent and IRTF streams. See [RFC2026]
135 and [RFC4844] for more information.
137 Other Open Standards organisations (in the sense of [RFC2026]) are
138 encouraged to adopt them. Questions as to their applicability ought
139 to be handled through the liaison relationship, if present.
141 Ad hoc efforts are also encouraged to adopt them, as this RFC
142 reflects Best Current Practice.
144 This document's requirements specifically targets a few different
145 types of specifications:
147 o URI Scheme Definitions ("scheme definitions") - specifications
148 that define and register URI schemes, as per [RFC4395].
149 o Protocol Extensions ("extensions") - specifications that offer new
150 capabilities to potentially any identifier, or a large subset;
151 e.g., a new signature mechanism for 'http' URIs, or metadata for
152 any URI.
153 o Applications Using URIs ("applications") - specifications that use
154 URIs to meet specific needs; e.g., a HTTP interface to particular
155 information on a host.
157 Requirements that target the generic class "Specifications" apply to
158 all specifications, including both those enumerated above above and
159 others.
161 Note that this specification ought not be interpreted as preventing
162 the allocation of control of URIs by parties that legitimately own
163 them, or have delegated that ownership; for example, a specification
164 might legitimately specify the semantics of a URI on the IANA.ORG Web
165 site as part of the establishment of a registry.
167 1.2. Notational Conventions
169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
171 document are to be interpreted as described in [RFC2119].
173 2. Best Current Practices for Standardising Structured URIs
175 Different components of a URI have differing practices recommended.
177 2.1. URI Schemes
179 Applications and extensions MAY require use of specific URI
180 scheme(s); for example, it is perfectly acceptable to require that an
181 application support 'http' and 'https' URIs. However, applications
182 SHOULD NOT preclude the use of other URI schemes in the future, to
183 promote reuse, unless they are clearly specific to the nominated
184 schemes.
186 Specifications MUST NOT define substructure within URI schemes,
187 unless they do so by modifying [RFC4395], or they are the
188 registration document for the URI scheme(s) in question.
190 2.2. URI Authorities
192 Scheme definitions define the presence, format and semantics of an
193 authority component in URIs; all other specifications MUST NOT
194 constrain, define structure or semantics for them.
196 2.3. URI Paths
198 Scheme definitions define the presence, format, and semantics of a
199 path component in URIs; all other specifications MUST NOT constrain,
200 define structure or semantics for any path component.
202 The only exception to this requirement is registered "well-known"
203 URIs, as specified by [RFC5785]. See that document for a description
204 of the applicability of that mechanism.
206 2.4. URI Queries
208 The presence, format and semantics of the query component of URIs is
209 dependent upon many factors, and MAY be constrained by a scheme
210 definition. Often, they are determined by the implementation of a
211 resource itself.
213 Applications SHOULD NOT directly specify the syntax of queries, as
214 this can cause operational difficulties for deployments that do not
215 support a particular form of a query.
217 Extensions MUST NOT specify the format or semantics of queries. In
218 particular, extensions MUST NOT assume that all HTTP(S) resources are
219 capable of accepting queries in the format defined by [HTML4],
220 Section 17.13.4.
222 2.5. URI Fragment Identifiers
224 Media type definitions (as per [RFC6838] SHOULD specify the fragment
225 identifier syntax(es) to be used with them; other specifications MUST
226 NOT define structure within the fragment identifier, unless they are
227 explicitly defining one for reuse by media type definitions.
229 3. Alternatives to Specifying Static URIs
231 Given the issues above, the most successful strategy for applications
232 and extensions that wish to use URIs is to use them in the fashion
233 they were designed; as run-time artifacts that are exchanged as part
234 of the protocol, rather than statically specified syntax.
236 For example, if a specific URI needs to be known to interact with an
237 application, its "shape" can be determined by interacting with the
238 application's more general interface (in Web terms, its "home page")
239 to learn about that URI.
241 [RFC5988] describes a framework for identifying the semantics of a
242 link in a "link relation type" to aid this. [RFC6570] provides a
243 standard syntax for "link templates" that can be used to dynamically
244 insert application-specific variables into a URI to enable such
245 applications while avoiding impinging upon URI owners' control of
246 them.
248 [RFC5785] allows specific paths to be 'reserved' for standard use on
249 URI schemes that opt into that mechanism ('http' and 'https' by
250 default). Note, however, that this is not a general "escape valve"
251 for applications that need structured URIs; see that specification
252 for more information.
254 Specifying more elaborate structures in an attempt to avoid
255 collisions is not adequate to conform to this document. For example,
256 prefixing query parameters with "myapp_" does not help.
258 4. Security Considerations
260 This document does not introduce new protocol artifacts with security
261 considerations.
263 5. IANA Considerations
265 This document clarifies appropriate registry policy for new URI
266 schemes, and potentially for the creation of new URI-related
267 registries, if they attempt to mandate structure within URIs. There
268 are no direct IANA actions specified in this document.
270 6. References
272 6.1. Normative References
274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
275 Requirement Levels", BCP 14, RFC 2119, March 1997.
277 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
278 Resource Identifier (URI): Generic Syntax", STD 66,
279 RFC 3986, January 2005.
281 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
282 Registration Procedures for New URI Schemes", BCP 35,
283 RFC 4395, February 2006.
285 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
286 Specifications and Registration Procedures", BCP 13,
287 RFC 6838, January 2013.
289 6.2. Informative References
291 [HTML4] Jacobs, I., Le Hors, A., and D. Raggett, "HTML 4.01
292 Specification", December 1999,
293 .
295 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
296 3", BCP 9, RFC 2026, October 1996.
298 [RFC4844] Daigle, L. and Internet Architecture Board, "The RFC
299 Series and RFC Editor", RFC 4844, July 2007.
301 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
302 Uniform Resource Identifiers (URIs)", RFC 5785,
303 April 2010.
305 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
307 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
308 and D. Orchard, "URI Template", RFC 6570, March 2012.
310 [webarch] Jacobs, I. and N. Walsh, "Architecture of the World Wide
311 Web, Volume One", December 2004,
312 .
314 Appendix A. Acknowledgments
316 Thanks to David Booth, Anne van Kesteren and Erik Wilde for their
317 suggestions and feedback.
319 Author's Address
321 Mark Nottingham
323 Email: mnot@mnot.net
324 URI: http://www.mnot.net/