idnits 2.17.00 (12 Aug 2021) /tmp/idnits42696/draft-ietf-appsawg-uri-get-off-my-lawn-03.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 7, 2014) is 2965 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 7, 2014 4 Updates: 3986 (if approved) 5 Intended status: BCP 6 Expires: October 9, 2014 8 URI Design and Ownership 9 draft-ietf-appsawg-uri-get-off-my-lawn-03 11 Abstract 13 RFC3986 Section 1.1.1 defines URI syntax as "a federated and 14 extensible naming system wherein each scheme's specification may 15 further restrict the syntax and semantics of identifiers using that 16 scheme." In other words, the structure of a URI is defined by its 17 scheme. While it is common for schemes to further delegate their 18 substructure to the URI's owner, publishing independent standards 19 that mandate particular forms of URI substructure is inappropriate, 20 because the essentially usurps ownership. This document clarifies 21 both this problematic practice and some acceptable alternatives in 22 standards. 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 October 9, 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 Standardizing Structured URIs . . . 4 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 (as defined in [webarch] Section 93 2.2.2.1) is choosing to use the server or the software, this can be 94 seen as reasonable delegation of authority. When such conventions 95 are mandated by a party other than the owner, however, it can have 96 several potentially detrimental effects: 98 o Collisions - As more ad hoc conventions for URI structure become 99 standardized, it becomes more likely that there will be collisions 100 between them (especially considering that servers, applications 101 and individual deployments will have their own 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 standardized, 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 behavior. 125 Publishing an independent standard that constrains an existing URI 126 structure in ways which aren't explicitly allowed by [RFC3986] (e.g., 127 by defining it in the URI scheme) is usually inappropriate, because 128 the structure of a URI needs to be firmly under the control of its 129 owner, and the IETF (as well as other organizations) should not usurp 130 it. 132 This document explains best current practices for establishing URI 133 structures, conventions and formats in standards. It also offers 134 strategies for specifications to avoid violating these guidelines in 135 Appendix B. 137 1.1. Who This Document Is For 139 This document's requirements primarily target a few different types 140 of specifications: 142 o Protocol Extensions ("extensions") - specifications that offer new 143 capabilities to potentially any identifier, or a large subset; 144 e.g., a new signature mechanism for 'http' URIs, or metadata for 145 any URI. 146 o Applications Using URIs ("applications") - specifications that use 147 URIs to meet specific needs; e.g., a HTTP interface to particular 148 information on a host. 150 Requirements that target the generic class "Specifications" apply to 151 all specifications, including both those enumerated above and others. 153 Note that this specification ought not be interpreted as preventing 154 the allocation of control of URIs by parties that legitimately own 155 them, or have delegated that ownership; for example, a specification 156 might legitimately define the semantics of a URI on the IANA.ORG Web 157 site as part of the establishment of a registry. 159 1.2. Notational Conventions 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in [RFC2119]. 165 2. Best Current Practices for Standardizing Structured URIs 167 Best practices differ depending on the URI component, as described in 168 this section. 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 that URI scheme, or by modifying 180 [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, or define the structure or the semantics for URI 187 authorities, unless 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 in URIs. 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 or define the structure or the 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/