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