idnits 2.17.1 draft-thaler-uri-scheme-reg-ps-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 17, 2013) is 3844 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Thaler 3 Internet-Draft Microsoft 4 Intended status: Informational October 17, 2013 5 Expires: April 20, 2014 7 Guidelines and Registration Procedures for New URI Schemes: Problem 8 Statement 9 draft-thaler-uri-scheme-reg-ps-01.txt 11 Abstract 13 This document describes some problems with the existing guidelines 14 and procedures, as documented in RFC 4395, for new URI schemes. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on April 20, 2014. 33 Copyright Notice 35 Copyright (c) 2013 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2.1. Current registration process doesn't scale well . . . . . 4 53 2.2. Lack of incentive to register . . . . . . . . . . . . . . 5 54 2.3. Current private scheme guidance causes conflicts . . . . 5 55 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 56 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 57 5. Informative References . . . . . . . . . . . . . . . . . . . 6 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 60 1. Introduction 62 RFC 4395 [RFC4395] provides guidelines and recommendations for the 63 definition of Uniform Resource Identifier (URI) schemes. It defines 64 procedures and guidelines for four types of URI schemes: 66 a. Permanent, which [RFC4395] requires for all IETF Standards-Track 67 schemes, and which has strict requirements. 69 b. Provisional, which has a lower barrier. 71 c. Historical, which is for schemes no longer in use and hence 72 generally does not apply to "new" URI schemes. 74 d. Private, meaning not registered with IANA. 76 As explained in Section 1 of [RFC4395], the purpose of an IANA- 77 maintained registry is to: 79 1. provide a central point of discovery for established URI scheme 80 names, and easy location of their defining documents; 82 2. discourage use of the same URI scheme name for different 83 purposes; 85 3. help those proposing new URI scheme names to discern established 86 trends and conventions, and avoid names that might be confused 87 with existing ones; 89 4. encourage registration by setting a low barrier for provisional 90 registrations. 92 However, the guidance in [RFC4395] is, in many cases that are now 93 common, ambiguous or insufficient to accomplish the stated purposes. 94 This document discusses a number of such problems. In doing so, we 95 note that an effort was started to update the guidance, in 97 [I-D.ietf-iri-4395bis-irireg]. It does not, however, address the 98 problems we discuss in this document, although it may be the logical 99 place to do so. 101 It is first important to understand the scale of the problem. It is 102 already common on many widely deployed platforms (including Windows, 103 iOS, and Android) and form factors (PCs, phones, etc.) today to allow 104 applications to be associated with specific URI schemes, such that 105 when the URI is accessed (e.g., clicking on a link in a browser, or 106 calling an equivalent API from an application), the associated 107 application is launched to handle the URI. That is, the application 108 is given the URI and determines what action to take (as opposed to 109 being given content that the URI points to). Indeed, some such URIs 110 are simply Uniform Resource Names that contain the data themselves, 111 rather than Uniform Resource Locators that can be resolved to 112 content. As such, URIs are increasingly becoming a form of inter- 113 process communication as a way to invoke another application, with 114 arguments placed in the scheme-specific part of the URI. Thus, in 115 the extreme case, every application might define its own URI scheme, 116 and the number of applications available on mainstream platforms 117 today is easily numbered in the hundreds of thousands. 119 This use of URIs can be viewed as different from the web. That is, 120 an increasingly larger portion of URI schemes are intended for 121 "local" use, rather than for use with the web. The "URI Generic 122 Syntax" [RFC3986] explicitly allows for such a wide scope of use of 123 URIs. It states, in section 1.1: 125 This specification does not limit the scope of what might be a 126 resource; rather, the term "resource" is used in a general sense 127 for whatever might be identified by a URI. Familiar examples 128 include an electronic document, an image, a source of information 129 with a consistent purpose (e.g., "today's weather report for Los 130 Angeles"), a service (e.g., an HTTP-to-SMS gateway), and a 131 collection of other resources. A resource is not necessarily 132 accessible via the Internet; e.g., human beings, corporations, and 133 bound books in a library can also be resources. Likewise, 134 abstract concepts can be resources, such as the operators and 135 operands of a mathematical equation, the types of a relationship 136 (e.g., "parent" or "employee"), or numeric values (e.g., zero, 137 one, and infinity). 139 and 141 This specification does not place any limits on the nature of a 142 resource, the reasons why an application might seek to refer to a 143 resource, or the kinds of systems that might use URIs for the sake 144 of identifying resources. 146 The current process was designed based in part on joint 147 recommendations from the W3C and IETF in 2002 [RFC3305], when the 148 known uses of schemes were such that there were 34 registered 149 schemes, 51 known publically documented but unregistered schemes, and 150 50 or so private schemes with 2-3 being added every day, as noted 151 (see Section 3.1 of [RFC3305]). Such private growth has continued 152 and expanded to more platforms since then, such that the public 153 schemes are now probably a small minority. 155 2. Problems 157 2.1. Current registration process doesn't scale well 159 Section 5.2 of [RFC4395] requires a four-week mailing list review for 160 all Permanent registrations. It is, however, ambiguous as to whether 161 a mailing list review is required for Provisional registrations and 162 if so, for how long. The longer the process, the less of an 163 incentive there is to register Provisional schemes. This problem was 164 discussed in 2010 by the IRI WG, which concluded that a mailing list 165 review should not be required for Provisional schemes, only expert 166 review which may take up to two weeks, but this conclusion has not 167 yet been documented. 169 The manual step of expert review still introduces a scalability 170 bottleneck. What if all new applications being submitted to an app 171 store started sending requests for Provisional URI schemes? The 172 expert review process would be overwhelmed, especially if no one is 173 paid to do the expert review. As such, the goals stated in Section 1 174 become far less effective when registered schemes are only a tiny 175 fraction of the URI schemes in use in practice. 177 The author ran an experiment in 2012, which was reported to the IRI 178 WG at its final meeting at IETF 85, where over 75 schemes that were 179 listed on Wikipedia as being unregistered but in use were submitted 180 as third-party registrations. All of them were registered after two 181 weeks had passed and it was pointed out that the deadline had expired 182 and per the process in [RFC4395], must be automatically listed. The 183 only noticeable outcome of the expert review, other than to introduce 184 a two week delay and manual effort, was to add a warning about the 185 unknown security impact of one scheme. This is not intended to imply 186 that the expert review was not valuable, only that the value provided 187 could not scale effectively if the process were stressed with the 188 current potential demand. 190 In summary, [RFC4395] defines a set of goals, which we listed above 191 in Section 1. The current mechanism does not meet those goals. To 192 meet the stated goals would require the majority of schemes to be 193 registered. The current process cannot scale to do so, given current 194 practice. Hence, we either need to change the goals, or change the 195 process, or both. 197 2.2. Lack of incentive to register 199 Currently there is little incentive for an organization outside the 200 IETF to register schemes (whether as Permanent, Provisional, or 201 Historical). Registering introduces a cost, both in terms of manual 202 effort needed to apply, but also in the time delay introduced. This 203 cost must be weighed against the benefit, which is primarily to 204 simply lower the risk of collision. (Another benefit is to provide 205 ease of access to relevant documentation via the IANA registry, 206 although this benefit is often seen as unimportant or even 207 undesirable in some cases.) 209 As long as the risk of collision is perceived to be low, or the 210 effect of collision considered to be acceptable (e.g., asking the 211 user which app to launch), registration is bypassed in favor of a 212 "Private" scheme. The effect of collision can of course be 213 problematic (though the scheme-defining organization may not realize 214 the danger) when the syntax of the scheme-specific part differs. 215 Launching an application with a URI that is invalid according to that 216 application's syntax for the custom URI scheme is not useful. 218 An app store certification process could in theory require or 219 encourage Provisional application. However, there is little 220 incentive for them to do so either, since an app store itself has a 221 process which would be delayed and disincent application developers 222 to submit applications. 224 2.3. Current private scheme guidance causes conflicts 226 Section 2.8 of [RFC4395] states: 228 Organizations that desire a private name space for URI scheme 229 names are encouraged to use a prefix based on their domain name, 230 expressed in reverse order. For example, a URI scheme name of 231 com-example-info might be registered by the vendor that owns the 232 example.com domain name. 234 There are multiple problems with the above guidance: 236 1. No guidance is given for when it might or might not be 237 appropriate to use a private name space. For example, is this 238 guidance appropriate for application vendors defining a custom 239 scheme that they want to associate the application with? As 240 such, the current assumption is that it is appropriate for anyone 241 who can live with some potential risk of collision. 243 2. Hyphens occur in actual domain names. Consider one organization 244 that owns the domain name "foo.bar.example", and another 245 organization that owns "foo-bar.example". Using the mechanism 246 implied in the example can result in both colliding with 247 "example-bar-foo-info". 249 3. The guidance is only an encouragement, and no precise algorithm 250 is given. For example, whether "." should be converted to "-" as 251 in the example is unclear. If an organization is actually trying 252 to follow the recommended guidelines, they will likely use a "-" 253 as directed and risk conflicts as noted above. More commonly, an 254 organization today will simply use a string that identifies (say) 255 their application, and not be based on a domain name. 257 4. No protection is suggested against IANA later granting 258 registration to a scheme that follows the recommended convention 259 that is in use by someone else. For example, as can be seen at 260 [IANAURI], there are already registered schemes that use "." 261 (e.g., "iris.beep") and "-" (e.g., "xcon-userid") in them, and 262 there could be similar new schemes registered at any time. If an 263 organization had previously acquired the TLD "iris" or "xcon", 264 those values could already be in use in applications from those 265 organizations. Especially now that ICANN is allowing gTLD 266 applications, this is a very real possibility. 268 3. Security Considerations 270 The security considerations in [RFC4395] still apply. 272 4. IANA Considerations 274 This document requires no actions by the IANA. 276 5. Informative References 278 [I-D.ietf-iri-4395bis-irireg] 279 Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 280 Registration Procedures for New URI/IRI Schemes", draft- 281 ietf-iri-4395bis-irireg-04 (work in progress), December 282 2011. 284 [IANAURI] IANA, ., "Uniform Resource Identifier (URI) Schemes", 285 2013, . 288 [RFC3305] Mealling, M. and R. Denenberg, "Report from the Joint W3C/ 289 IETF URI Planning Interest Group: Uniform Resource 290 Identifiers (URIs), URLs, and Uniform Resource Names 291 (URNs): Clarifications and Recommendations", RFC 3305, 292 August 2002. 294 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 295 Resource Identifier (URI): Generic Syntax", STD 66, RFC 296 3986, January 2005. 298 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 299 Registration Procedures for New URI Schemes", BCP 35, RFC 300 4395, February 2006. 302 Author's Address 304 Dave Thaler 305 Microsoft Corporation 306 One Microsoft Way 307 Redmond, WA 98052 308 USA 310 Phone: +1 425 703 8835 311 Email: dthaler@microsoft.com