idnits 2.17.1 draft-ietf-appsawg-uri-get-off-my-lawn-01.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 directly say this. It does mention RFC3986 though, so this could be OK. 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 (January 30, 2014) is 3737 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 5785 (Obsoleted by RFC 8615) -- Obsolete informational reference (is this intentional?): RFC 5988 (Obsoleted by RFC 8288) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 appsawg M. Nottingham 3 Internet-Draft January 30, 2014 4 Updates: 3986 (if approved) 5 Intended status: BCP 6 Expires: August 3, 2014 8 URI Design and Ownership 9 draft-ietf-appsawg-uri-get-off-my-lawn-01 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). However, publishing standards that mandate URI structure 16 is inappropriate because the structure of a URI needs to be firmly 17 under the control of its owner, and the IETF (as well as other 18 organisations) should not usurp this ownership. 20 This document is intended to prevent this practice (sometimes called 21 "URI Squatting") in standards, but updating RFC3986 to indicate where 22 it is acceptable. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 3, 2014. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Who This Document Is For . . . . . . . . . . . . . . . . . 4 60 1.2. Notational Conventions . . . . . . . . . . . . . . . . . . 4 61 2. Best Current Practices for Standardising Structured URIs . . . 5 62 2.1. URI Schemes . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.2. URI Authorities . . . . . . . . . . . . . . . . . . . . . . 5 64 2.3. URI Paths . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.4. URI Queries . . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.5. URI Fragment Identifiers . . . . . . . . . . . . . . . . . 6 67 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 69 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 5.1. Normative References . . . . . . . . . . . . . . . . . . . 6 71 5.2. Informative References . . . . . . . . . . . . . . . . . . 7 72 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 7 73 Appendix B. Alternatives to Specifying Structure in URIs . . . . . 7 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 URIs [RFC3986] very often include structured application data. This 79 might include artifacts from filesystems (often occurring in the path 80 component), and user information (often in the query component). In 81 some cases, there can even be application-specific data in the 82 authority component (e.g., some applications are spread across 83 several hostnames to enable a form of partitioning or dispatch). 85 Furthermore, constraints upon the structure of URIs can be imposed by 86 an implementation; for example, many Web servers use the filename 87 extension of the last path segment to determine the media type of the 88 response. Likewise, pre-packaged applications often have highly 89 structured URIs that can only be changed in limited ways (often, just 90 the hostname and port they are deployed upon). 92 Because the owner of the URI is choosing to use the server or the 93 software, this can be seen as reasonable delegation of authority. 94 When such conventions are mandated by standards, however, it can have 95 several potentially detrimental effects: 97 o Collisions - As more conventions for URI structure become 98 standardised, it becomes more likely that there will be collisions 99 between such conventions (especially considering that servers, 100 applications and individual deployments will have their own 101 conventions). 102 o Dilution - When the information added to a URI is ephemeral, this 103 dilutes its utility by reducing its stability (see [webarch] 104 Section 3.5.1), and can cause several alternate forms of the URI 105 to exist (see [webarch] Section 2.3.1). 106 o Rigidity - Fixed URI syntax often interferes with desired 107 deployment patterns. For example, if an authority wishes to offer 108 several applications on a single hostname, it becomes difficult to 109 impossible to do if their URIs do not allow the required 110 flexibility. 111 o Operational Difficulty - Supporting some URI conventions can be 112 difficult in some implementations. For example, specifying that a 113 particular query parameter be used precludes the use of Web 114 servers that serve the response from a filesystem. Likewise, an 115 application that fixes a base path for its operation (e.g., "/v1") 116 makes it impossible to deploy other applications with the same 117 prefix on the same host. 118 o Client Assumptions - When conventions are standardised, some 119 clients will inevitably assume that the standards are in use when 120 those conventions are seen. This can lead to interoperability 121 problems; for example, if a specification documents that the "sig" 122 URI query parameter indicates that its payload is a cryptographic 123 signature for the URI, it can lead to undesirable behaviour. 125 While it is not ideal when a server or a deployed application 126 constrains URI structure (indeed, this is not recommended practice, 127 but that discussion is out of scope for this document), publishing 128 standards that mandate URI structure (beyond those allowed by 129 [RFC3986]) is inappropriate because the structure of a URI needs to 130 be firmly under the control of its owner, and the IETF (as well as 131 other organisations) should not usurp this ownership; see [webarch] 132 Section 2.2.2.1. 134 This document explains best current practices for establishing URI 135 structures, conventions and formats in standards. It also offers 136 strategies for specifications to avoid violating these guidelines in 137 Appendix B. 139 1.1. Who This Document Is For 141 This document's requirements specifically target a few different 142 types of specifications: 144 o URI Scheme Definitions ("scheme definitions") - specifications 145 that define and register URI schemes, as per [RFC4395]. 146 o Protocol Extensions ("extensions") - specifications that offer new 147 capabilities to potentially any identifier, or a large subset; 148 e.g., a new signature mechanism for 'http' URIs, or metadata for 149 any URI. 150 o Applications Using URIs ("applications") - specifications that use 151 URIs to meet specific needs; e.g., a HTTP interface to particular 152 information on a host. 154 Requirements that target the generic class "Specifications" apply to 155 all specifications, including both those enumerated above above and 156 others. 158 Note that this specification ought not be interpreted as preventing 159 the allocation of control of URIs by parties that legitimately own 160 them, or have delegated that ownership; for example, a specification 161 might legitimately define the semantics of a URI on the IANA.ORG Web 162 site as part of the establishment of a registry. 164 1.2. Notational Conventions 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in [RFC2119]. 170 2. Best Current Practices for Standardising Structured URIs 172 Best practices differ depending on the URI component. 174 2.1. URI Schemes 176 Applications and extensions MAY require use of specific URI 177 scheme(s); for example, it is perfectly acceptable to require that an 178 application support 'http' and 'https' URIs. However, applications 179 SHOULD NOT preclude the use of other URI schemes in the future, 180 unless they are clearly specific to the nominated schemes. 182 A specification that defines substructure within a URI scheme MUST do 183 so in a registration document for the URI scheme in question, or by 184 modifying [RFC4395]. 186 2.2. URI Authorities 188 Scheme definitions define the presence, format and semantics of an 189 authority component in URIs; all other specifications MUST NOT 190 constrain, define structure or semantics for URI authorities. 192 For example, an extension or application cannot say that the "foo" 193 prefix in "foo_app.example.com" is meaningful or triggers special 194 handling. 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 For example, an application cannot specify a fixed URI path "/myapp", 207 since this usurps the host's control of that space. Specifying a 208 fixed path relative to another (e.g., {whatever}/myapp) is also bad 209 practice, since it "locks" the URIs in use; while doing so might 210 prevent collisions, it does not avoid the other issues discussed. 212 2.4. URI Queries 214 The presence, format and semantics of the query component of URIs is 215 dependent upon many factors, and MAY be constrained by a scheme 216 definition. Often, they are determined by the implementation of a 217 resource itself. 219 Applications SHOULD NOT directly specify the syntax of queries, as 220 this can cause operational difficulties for deployments that do not 221 support a particular form of a query. 223 Extensions MUST NOT specify the format or semantics of queries. 225 For example, an extension cannot be minted that indicates that all 226 query parameters with the name "sig" indicate a cryptographic 227 signature. 229 2.5. URI Fragment Identifiers 231 Media type definitions (as per [RFC6838] SHOULD specify the fragment 232 identifier syntax(es) to be used with them; other specifications MUST 233 NOT define structure within the fragment identifier, unless they are 234 explicitly defining one for reuse by media type definitions. 236 3. Security Considerations 238 This document does not introduce new protocol artifacts with security 239 considerations. It prohibits some practices that might lead to 240 vulnerabilities; for example, if a security-sensitive mechanism is 241 introduced by assuming that a URI path component or query string has 242 a particular meaning, false positives might be encountered (due to 243 sites that already use the chosen string). 245 4. IANA Considerations 247 This document clarifies appropriate registry policy for new URI 248 schemes, and potentially for the creation of new URI-related 249 registries, if they attempt to mandate structure within URIs. There 250 are no direct IANA actions specified in this document. 252 5. References 254 5.1. Normative References 256 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 257 Requirement Levels", BCP 14, RFC 2119, March 1997. 259 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 260 Resource Identifier (URI): Generic Syntax", STD 66, 261 RFC 3986, January 2005. 263 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 264 Registration Procedures for New URI Schemes", BCP 35, 265 RFC 4395, February 2006. 267 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 268 Specifications and Registration Procedures", BCP 13, 269 RFC 6838, January 2013. 271 5.2. Informative References 273 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 274 Uniform Resource Identifiers (URIs)", RFC 5785, 275 April 2010. 277 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 279 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 280 and D. Orchard, "URI Template", RFC 6570, March 2012. 282 [webarch] Jacobs, I. and N. Walsh, "Architecture of the World Wide 283 Web, Volume One", December 2004, 284 . 286 Appendix A. Acknowledgments 288 Thanks to David Booth, Dave Crocker, Tim Bray, Anne van Kesteren, 289 Martin Thomson and Erik Wilde for their suggestions and feedback. 291 Appendix B. Alternatives to Specifying Structure in URIs 293 Given the issues above, the most successful strategy for applications 294 and extensions that wish to use URIs is to use them in the fashion 295 they were designed; as links that are exchanged as part of the 296 protocol, rather than statically specified syntax. Several existing 297 specifications can aid in this. 299 [RFC5988] specifies relation types for Web links. By providing a 300 framework for linking on the Web, where every link has a relation 301 type, context and target, it allows applications to define a link's 302 semantics and connectivity. 304 [RFC6570] provides a standard syntax for URI Templates that can be 305 used to dynamically insert application-specific variables into a URI 306 to enable such applications while avoiding impinging upon URI owners' 307 control of them. 309 [RFC5785] allows specific paths to be 'reserved' for standard use on 310 URI schemes that opt into that mechanism ('http' and 'https' by 311 default). Note, however, that this is not a general "escape valve" 312 for applications that need structured URIs; see that specification 313 for more information. 315 Specifying more elaborate structures in an attempt to avoid 316 collisions is not adequate to conform to this document. For example, 317 prefixing query parameters with "myapp_" does not help, because the 318 prefix itself is subject to the risk of collision (since it is not 319 "reserved"). 321 Author's Address 323 Mark Nottingham 325 Email: mnot@mnot.net 326 URI: http://www.mnot.net/