Skip to main content

Defined Resource Operator (drop) The 'drop' URI Scheme
draft-mcsweeney-drop-scheme-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Tim McSweeney
Last updated 2020-05-18
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-mcsweeney-drop-scheme-00
Internet Engineering Task Force (IETF)                       T.McSweeney
Internet-Draft                               
Intended status: Informational                                                                                      
Expires: Nov 19,2020                                        May 18, 2020

                     draft-mcsweeney-drop-scheme-00
                     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."

   This Internet-Draft will expire on November 19, 2020.

Copyright Notice

   Copyright (c) 2020 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 . . . . . . . 3  
     2.5.  Interoperability Considerations . . . . . . . . . . . . . 4  
   3.  The drop URI Scheme Registration Request. . . . . . . . . . . 4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . 4
   6.  Normative References  . . . . . . . . . . . . . . . . . . . . 4  
   7.  Informative References. . . . . . . . . . . . . . . . . . . . 5  
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . . 5 
   Contributor . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 5 

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
   ^L
   of a URI reference without knowing the scheme-specific requirements
   of every possible identifier.  [RFC3986  abstract]
   
[RFC3986] defines the overall syntax for URIs as:

               URI = scheme ":" hier-part [ "?" query ] [ "#" fragment]
                       \1/  \2/    \3/         \4/          \5/

Similar to the previously registered 'tel' [RFC3966] and 'leaptofrogans'
[RFC8589] URIs, the 'drop' URI scheme is syntactically correct but does
not need to use all 5 of the parse-able components available to it.  The
'drop' scheme uses the number sign '#' as a general delimiter as seen
in Appendix A. Collected ABNF [RFC3986].  The 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 can be
located or further processing continued. It would look similar to
'sd54g54.dropexample.com'.  This subdomain characteristic gives it a
global uniqueness which adds value and prevents ambiguity.  

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 for
anything not found using the previous two methods.  The first, or
default, action is when an application invokes the 'drop' URI it 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.
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.
  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.

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 continue on 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.    URI Scheme Registration Request

   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 6 of this document

4.  IANA Considerations

   Expert Review" with an initial (optional)
   registration update request - permanent
   
5.  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.

6.  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/inof/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>.
   
   [RFC8589]  Tamas, A., Phister, B., Ed., and J-E. Rodriguez, "The
              'leaptofrogans' URI Scheme", RFC8589, DOI10.17487/RFC8589,
              May 2019, <https://www.rfc-editor.org/info/rfc8589>.

   [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>.

7.  Informative References

Acknowledgements

  

Contributors

   

Authors' Addressess
   
   Tim McSweeney
   Parameter One
   950a Union Rd 
   Suite #432
   West Seneca, NY 14224

   Comments are solicited and should be directed to Tim McSweeney at 
   tim@dropnumber.com