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/