Internet DRAFT - draft-mcsweeney-drop-scheme
draft-mcsweeney-drop-scheme
Internet Engineering Task Force (IETF) T.McSweeney
Internet-Draft [1]Parameter One
Intended status: Informational August 15,2022
Expires: February 16,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
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may not be modified, and derivative works of it may not
be created, except to format it for publication as an RFC or to
translate it into languages other than English.
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. But unlike these other schemes the 'drop' scheme uses the
number sign '#' as a general delimiter where typically a colon ":" is
found. The ":" and the "#" are two of the seven charcters catagorized as
general delimiters (gen-delims) in the "reserved" set. The general
delimiters (gen-delims), described in Section 2.2 [RFC3986], can be used
to seperate generic URI components(1-5). The "#" is defined as a
delimiter by the implementation-specific syntax of the 'drop' URI's
dereferencing algorithm. 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 becomes the subdomain portion of a FQDN where the resource(s) can be
located or further processing continued. It would look similar to
'sd54g54.dropexample.com'. There will be only one second level domain
for http use. This subdomain characteristic gives it a global
uniqueness which adds value and prevents ambiguity.
Compared against other URI schemes, the 'drop' scheme's use of a number
sign makes the scheme 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
