idnits 2.17.1 draft-mcsweeney-drop-scheme-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 326 lines 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 (August 30, 2020) is 1328 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7320 (Obsoleted by RFC 8820) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force (IETF) T.McSweeney 2 Internet-Draft 3 Intended status: Informational 4 Expires: March 3,2021 August 30, 2020 6 draft-mcsweeney-drop-scheme-03 7 Defined Resource Operator (drop) 8 The 'drop' URI Scheme 10 Abstract 12 This document describes the 'drop' Uniform Resource 13 Identifier (URI) scheme. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 Copyright Notice 32 Copyright (c) 2020 IETF Trust and the persons identified as the 33 document authors. All rights reserved. 35 This document is subject to BCP 78 and the IETF Trust's Legal 36 Provisions Relating to IETF Documents 37 (https://trustee.ietf.org/license-info) in effect on the date of 38 publication of this document. Please review these documents 39 carefully, as they describe your rights and restrictions with respect 40 to this document. Code Components extracted from this document must 41 include Simplified BSD License text as described in Section 4.e of 42 the Trust Legal Provisions and are provided without warranty as 43 described in the Simplified BSD License. 45 This document may not be modified, and derivative works of it may not 46 be created, except to format it for publication as an RFC or to 47 translate it into languages other than English. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Scheme Definitions . . . . . . . . . . . . . . . . . . . . . 2 53 2.1. Demonstrable, New, Long-Lived Utility . . . . . . . . . 2 54 2.2. Syntactic Compatibility . . . . . . . . . . . . . . . . . 2 55 2.3. Definitions and Operations . . . . . . . . . . . . . . .3 56 2.4. Internationalization and Character Encoding . . . . . . . 3 57 2.5. Interoperability Considerations . . . . . . . . . . . . . 4 58 3. The drop URI Scheme Registration Request. . . . . . . . . . . 4 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 61 6. Normative References . . . . . . . . . . . . . . . . . . . . 4 62 7. Informative References. . . . . . . . . . . . . . . . . . . . 5 63 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5 64 Contributor . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 67 1. Introduction 69 This document is provided to inform the internet community of the 70 'drop' URI scheme and to meet the required guidelines of a permanent 71 URI scheme. This scheme shortens the path to further unifying 72 communications by using public mechanisms of continuity for the pre- 73 resolution of private and public service integration. 75 2. Scheme definitions and syntax 77 2.1. Demonstrable, New, Long-Lived Utility 79 Phone numbers and physical addresses are antiquated but still very 80 useful. But what is to say that they both can not be represented by the 81 same character string? For any given person or business, it is simpler 82 to enter a single string into one's phone than what is currently an ever 83 growing list of communication method identifiers. When an owner is able 84 to update contact information it requires no changes by another user's 85 contact list or database. People, businesses, and machines generally 86 have a wide variety of, and specific uses for, different modes of 87 communication. Where those modes of communication overlap, there should 88 also be consolidation. The 'drop' scheme was created in a way to be 89 able to reuse current infrastructure making it easy to use and quick to 90 deploy. 92 2.2. Syntactic Compatibility 94 "While it is common for schemes to further delegate their 95 substructure to the URI's owner, publishing independent standards 96 that mandate particular forms of URI substructure is inappropriate, 97 because that essentially usurps ownership. [RFC7320] abstract 99 nonetheless.... 101 "The URI syntax defines a grammar that is a superset of all 102 valid URIs, allowing an implementation to parse the common components 103 of a URI reference without knowing the scheme-specific requirements 104 of every possible identifier. [RFC3986 abstract] 106 Section 3 of [RFC3986] defines the overall syntax for URIs and offers a 107 couple examples showing the component parts (1-5). The scheme and path 108 components are required, though the path may be empty (no characters). 110 foo://example.com:8042/over/there?name=ferret#nose 111 \_/ \______________/\_________/ \_________/ \__/ 112 | | | | | 113 URI= scheme(1) authority(2) path(3) query(4) fragment(5) 114 | _____________________|__ 115 / \ / \ 116 urn:example:animal:ferret:nose 118 The 'drop' URI does not use all 5 of the parse-able components 119 available to it. Instead, it uses only the required scheme(1) and 120 path(3) components. Previously registered URIs such as the 'tel' 121 [RFC3966] and 'geo' [RFC5870] schemes also use a limited number of 122 components. But unlike these other schemes the 'drop' scheme uses the 123 number sign '#' as a general delimiter where typically a colon ":" is 124 found. The ":" and the "#" are two of the seven charcters catagorized as 125 general delimiters (gen-delims) in the "reserved" set. The general 126 delimiters (gen-delims), described in Section 2.2 [RFC3986], can be used 127 to seperate generic URI components(1-5). The "#" is defined as a 128 delimiter by the implementation-specific syntax of the 'drop' URI's 129 dereferencing algorithm. The 'drop' scheme syntax is as follows: 131 drop-uri = drop "#" character string 133 drop # fg34htx 134 \__/ \_/ \_____/ 135 | | | 136 | 137 139 Characters of the scheme-specific-part have not been limited. 140 The following are some examples of 'drop' URIs: 142 drop#sd54g54 | drop#34.56 | drop#fgte8g-234.45 144 After the first step of resolution, the scheme-specific part of a 'drop' 145 URI becomes the subdomain portion of a FQDN where the resource(s) can be 146 located or further processing continued. It would look similar to 147 'sd54g54.dropexample.com'. There will be only one second level domain 148 for http use. This subdomain characteristic gives it a global 149 uniqueness which adds value and prevents ambiguity. 151 Compared against other URI schemes, the 'drop' scheme's use of a number 152 sign makes the scheme in its entirety unique, including the 153 scheme-specific-part. More so, the scheme-specific-part can be user 154 generated to add an extra layer of uniquess. Sending a fax to the same 155 digits as a phone call has been for around a long time proving that 156 being unique and being common can coexist. The 'drop' scheme can extend 157 that commonality to the web and beyond. 159 2.3. Definitions and Operations 161 Primarily functioning as a locator there are three ways to get to a 162 'drop' URI resource; http, SRV records, and private resolution. Private 163 resolution is only used if the resource(s) can not be found using the 164 previous two methods. This resource retrieval process utilizes the 165 Dynamic Delegation Discovery System [RFC3401]. Invoking the 'drop' URI 166 will cause a lookup for matching application information starting with 167 an A record [RFC1035], then on to Service Records [RFC2782], and then on 168 to other available records that may offer a new rule set for resolution. 169 As an example use case, when the 'drop' scheme is typed into the address 170 bar of a browser, the dns returns a FQDN to where the browser may then 171 go and retrieve a HTML document. Similarly, the same scheme-specific 172 part can be used in a messaging address, or mapping location 173 application. Reusability of a scheme-specific-part that has an output 174 of a hierarchical structure representing an administrative delegation 175 that translates into a domain name makes this scheme a perfect fit for 176 domain name system [RFC6950] section 3.3. Users and owners define what 177 operations are available. One user may have sip services enabled while 178 another may only let you go to a company's webpage. 180 Permanency of what is identified by the scheme-specific-part is not 181 guaranteed and is user specific. Permanency of a specific 182 scheme-specific-part is not guaranteed to exist or that it will re-exist 183 after it had once existed. There may be a future need where the 'drop' 184 URI scheme will want to be used as a strict identifier so it would not 185 be fair to constrain the definition of this scheme in this document at 186 this time. Other future uses beyond what is commonly known of unique 187 subdomain creation should be anticipated for this 'drop' scheme. 189 2.4. Internationalization and Character Encoding 191 The 'drop' scheme name follows the syntax of Section 3.1 of [RFC3986] 192 which only allows for a limited number of characters (US-ASCII). 193 The scheme name is also sufficiently short and distinguishable to 194 avoid problems. The 'drop' scheme name does not identify any 195 particular application and does not have any correspondence with a 196 particular service name. Queries that come in non-ASCII encoding 197 must be allowed to go forward so that private resolution can continue 198 if A and SRV record lookups fail. 200 2.5. Interoperability Considerations 202 The scheme creator is not aware of any details regarding the scheme 203 that may impact interoperability. 205 3. URI Scheme Registration Request 207 Scheme name: drop 209 Status: permanent 211 Applications/protocols that use this scheme name: 212 http, sip, email 214 Contact: 215 Registering party: Tim McSweeney 216 Scheme creator: Parameter One 218 Change controller: 219 Either the registering party or someone who is verified to represent 220 the scheme creator. 222 References: Section 6 of this document 224 4. IANA Considerations 226 Please add prevoiusly submitted records into the uri.arpa zone for 227 this draft. [RFC2860] 229 Please update the scheme registration information and point to this 230 draft. 232 5. Security Considerations 234 Security is partly dependent on the resource being located 235 and the application being used for the locating. Generally, security 236 concerns for this URI would come from the use of the URI and not 237 necessarily from the URI itself as [RFC3986] section 7 describes. 238 Examples are, domain spoofing, malicious redirection, domain hijacking, 239 and phishing attacks. 241 6. Normative References 243 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 244 Resource Identifier (URI): Generic Syntax", STD 66, 245 RFC 3986, DOI 10.17487/RFC3986, January 2005, 246 . 248 [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190 RFC 249 7320, DOI 10.17487/RFC7320, July 2014, 250 . 252 [RFC2782] Gulbrandsen, A., Vivie, P., and L. Esibov, "ADNS RR for 253 specifying the location of services (DNS SRV)", RFC 2782, 254 DOI 10.17487/RFC2782, February 2000, 255 . 257 [RFC1035] Mockapetris, P., "Domain names - implementation and 258 Specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 259 November 1987, . 261 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 262 3966, DOI 10.17487/RFC3966, December 2004, 263 . 265 [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 266 Part One: The Comprehensive DDDS", RFC 3401, DOI.17487/ 267 RFC3401, October 2002, 268 . 270 [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, 271 "Architectural Considerations, on Application Features in 272 the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013, 273 . 275 [RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource 276 Identifier for Geographic Locations ('geo' URI)", RFC 277 5870, DOI 10.17487/RFC5870, June 2010, 278 . 280 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 281 Understanding Concerning the Technical Work of the 282 Internet Assigned Numbers Authority"' RFC 2860, DOI 283 10.17487/RFC2860, June 2000, 284 . 286 7. Informative References 288 Acknowledgements 289 A special thank you to those individuals that take action and 290 participate at all levels of the URI review process from the IETF, IESG, 291 IANA, ICANN. 293 Contributors 294 Henry S. Thompson 295 Ted Hardie 297 Authors' Addressess 299 Tim McSweeney 300 Parameter One 301 950a Union Rd 302 Suite #432 303 West Seneca, NY 14224 305 Comments are solicited and should be directed to Tim McSweeney at 306 tim@dropnumber.com