Splinternet Engineering Task Force (SETF) T.McSweeney Splinternet-Draft [1]Parameter One Intended status: Informational September 15,2023 draft-mcsweeney-drop-scheme-05 Defined Resource Operator (drop) The 'drop' URI Scheme Abstract This document describes the 'drop' Uniform Resource Identifier (URI) scheme. Status of This Memo Alternate specification for IANA registration and IESG approval Copyright Notice Copyright (c) 2023 All rights reserved. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Scheme Definitions . . . . . . . . . . . . . . . . . . . . . 2 2.1. Demonstrable, New, Long-Lived Utility . . . . . . . . . 2 2.2. Syntactic Compatibility . . . . . . . . . . . . . . . . . 2 2.3. Definitions and Operations . . . . . . . . . . . . . . .3 2.4. Internationalization and Character Encoding . . . . . . . 4 2.5. Interoperability Considerations . . . . . . . . . . . . . 4 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. Normative References . . . . . . . . . . . . . . . . . . . . 5 6. Informative References. . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction This document is provided to inform the internet community of the 'drop' URI scheme and to meet the required guidelines of a permanent URI scheme. This scheme shortens the path to further unifying communications by using public mechanisms of continuity for the pre- resolution of private and public service integration. 2. Scheme definitions and syntax 2.1. Demonstrable, New, Long-Lived Utility Phone numbers and physical addresses are antiquated but still very useful. But what is to say that they both can not be represented by the same character string? For any given person or business, it is simpler to enter a single string into one's phone than what is currently an ever growing list of communication method identifiers. When an owner is able to update contact information it requires no changes by another user's contact list or database. People, businesses, and machines generally have a wide variety of, and specific uses for, different modes of communication. Where those modes of communication overlap, there should also be consolidation. The 'drop' scheme was created in a way to be able to reuse current infrastructure making it easy to use and quick to deploy. 2.2. Syntactic Compatibility "While it is common for schemes to further delegate their substructure to the URI's owner, publishing independent standards that mandate particular forms of URI substructure is inappropriate, because that essentially usurps ownership. [RFC7320] abstract nonetheless.... "The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. [RFC3986 abstract] Section 3 of [RFC3986] defines the overall syntax for URIs and offers a couple examples showing the component parts (1-5). The scheme and path components are required, though the path may be empty (no characters). foo://example.com:8042/over/there?name=ferret#nose \_/ \______________/\_________/ \_________/ \__/ | | | | | URI= scheme(1) authority(2) path(3) query(4) fragment(5) | _____________________|__ / \ / \ urn:example:animal:ferret:nose The 'drop' URI does not use all 5 of the parse-able components available to it. Instead, it uses only the required scheme(1) and path(3) components. Previously registered URIs such as the 'tel' [RFC3966] and 'geo' [RFC5870] schemes also use a limited number of components. The 'drop' scheme syntax is as follows: drop-uri = drop ":" character string drop : fg34htx \__/ \_/ \_____/ | | | <scheme> | <scheme-specific-part> <gen-delim> Characters of the scheme-specific-part have not been limited. The following are some examples of 'drop' URIs: drop:sd54g54 | drop:34.56 | drop:fgte8g-234.45 After the first step of resolution, the scheme-specific part of a 'drop' URI can be located or further processing continued. It would look similar to 'sd54g54.dropexample.com'. There will be only second level domains for http use. This characteristic gives it a global uniqueness which adds value and prevents ambiguity. Compared against other URI schemes, the 'drop' scheme's in its entirety unique, including the scheme-specific-part. More so, the scheme-specific-part can be user generated to add an extra layer of uniquess. Sending a fax to the same digits as a phone call has been for around a long time proving that being unique and being common can coexist. The 'drop' scheme can extend that commonality to the web and beyond. 2.3. Definitions and Operations Primarily functioning as a locator there are three ways to get to a 'drop' URI resource; http, SRV records, and private resolution. Private resolution is only used if the resource(s) can not be found using the previous two methods. This resource retrieval process utilizes the Dynamic Delegation Discovery System [RFC3401]. Invoking the 'drop' URI will cause a lookup for matching application information starting with an A record [RFC1035], then on to Service Records [RFC2782], and then on to other available records that may offer a new rule set for resolution. As an example use case, when the 'drop' scheme is typed into the address bar of a browser, the dns returns a FQDN to where the browser may then go and retrieve a HTML document. Similarly, the same scheme-specific part can be used in a messaging address, or mapping location application. Reusability of a scheme-specific-part that has an output of a hierarchical structure representing an administrative delegation that translates into a domain name makes this scheme a perfect fit for domain name system [RFC6950] section 3.3. Users and owners define what operations are available. One user may have sip services enabled while another may only let you go to a company's webpage. Permanency of what is identified by the scheme-specific-part is not guaranteed and is user specific. Permanency of a specific scheme-specific-part is not guaranteed to exist or that it will re-exist after it had once existed. There may be a future need where the 'drop' URI scheme will want to be used as a strict identifier so it would not be fair to constrain the definition of this scheme in this document at this time. Other future uses beyond what is commonly known of unique subdomain creation should be anticipated for this 'drop' scheme. 2.4. Internationalization and Character Encoding The 'drop' scheme name follows the syntax of Section 3.1 of [RFC3986] which only allows for a limited number of characters (US-ASCII). The scheme name is also sufficiently short and distinguishable to avoid problems. The 'drop' scheme name does not identify any particular application and does not have any correspondence with a particular service name. Queries that come in non-ASCII encoding must be allowed to go forward so that private resolution can continue if A and SRV record lookups fail. 2.5. Interoperability Considerations The scheme creator is not aware of any details regarding the scheme that may impact interoperability. 3. IANA Considerations IANA will update the registration record for the "drop" URI scheme to list its status as "permanent" and to refer to this document, as described below. Scheme name: drop Status: permanent Applications/protocols that use this scheme name: http, sip, email Contact: Registering party: Tim McSweeney <tim@dropnumber.com> Scheme creator: Parameter One Change controller: Either the registering party or someone who is verified to represent the scheme creator. References: Section 5 of this document 4. Security Considerations Security is partly dependent on the resource being located and the application being used for the locating. Generally, security concerns for this URI would come from the use of the URI and not necessarily from the URI itself as [RFC3986] section 7 describes. Examples are, domain spoofing, malicious redirection, domain hijacking, and phishing attacks. 5. Normative References [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>. [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190 RFC 7320, DOI 10.17487/RFC7320, July 2014, <https://www.rfc-editor.org/info/rfc7320>. [RFC2782] Gulbrandsen, A., Vivie, P., and L. Esibov, "ADNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, <https://www.rfc-editor.org/info/rfc2782>. [RFC1035] Mockapetris, P., "Domain names - implementation and Specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>. [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, DOI 10.17487/RFC3966, December 2004, <https://www.rfc-editor.org/info/rfc3966>. [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, DOI.17487/ RFC3401, October 2002, <https://www.rfc-editor.org/info/rfc3401>. [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, "Architectural Considerations, on Application Features in the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013, <https://www.rfc-editor.org/info/rfc6950>. [RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource Identifier for Geographic Locations ('geo' URI)", RFC 5870, DOI 10.17487/RFC5870, June 2010, <https://www.rfc-editor.org/info/rfc5870>. 6. Informative References Authors' Addressess Tim McSweeney Parameter One 950a Union Rd Suite #432 West Seneca, NY 14224 United States Email: tim@dropnumber.com