Description of Entities Identified by the 'tag' URI Scheme
draft-mc-tagresolution-00

Document Type Active Internet-Draft (individual)
Author =?utf-8?b?TWFyZWsgxIxlcm3DoWs=?= 
Last updated 2021-02-09
Stream (None)
Intended RFC status (None)
Formats pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Internet Engineering Task Force                           M. Čermák, Ed.
Internet-Draft                                           9 February 2021
Intended status: Informational                                          
Expires: 13 August 2021

       Description of Entities Identified by the 'tag' URI Scheme
                       draft-mc-tagresolution-00

Abstract

   This document specifies automated description resolution mechanism
   for Uniform Resource Identifiers (URIs) in the "tag" scheme.  Tag
   URIs (also known as "tags") are designed to be non-dereferenceable,
   however it may be useful for a tag minter to optinally provide a
   public easily accessible description of the entity associated with a
   tag.

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 13 August 2021.

Copyright Notice

   Copyright (c) 2021 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.

Čermák                   Expires 13 August 2021                 [Page 1]
Internet-Draft          Description of 'tag' URIs          February 2021

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Querying Information about a Tag  . . . . . . . . . . . . . .   3
     2.1.  Host-based Authority and the .well-known "tag" URI  . . .   3
       2.1.1.  Obtaining the Archived Version of a Description . . .   4
     2.2.  Mail-based Authority  . . . . . . . . . . . . . . . . . .   5
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Assignment of .well-known 'tag' URI . . . . . . . . . . .   6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     5.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   The 'tag' Uniform Resource Identifier (URI) scheme is described by
   RFC 4151 [RFC4151].  URIs in this scheme (tags) are human-friendly
   identifiers, internally consisting of 2 parts: the tagging entity (a
   domain name or an e-mail address, followed by a date) and a specific
   identifier (optional).  The combination chosen for the tagging entity
   guarantees uniqueness of tags across time and space, as long as no
   unauthorized entity mints tags under an entity with a different
   ownership.

   Using tags as opaque identifiers in some cases is convenient for a
   couple of reasons: they are simple and easily rememberable by humans,
   the date component tells about the date of creation of the entity and
   thus carries significant information about its relevance, and the
   option of using e-mail addresses opens the possibility of minting new
   tags to virtually everyone.

   Use of tags in other contexts, such as in semantic web applications,
   could be problematic.  While dereferenceability is not a strict
   requirement in those cases, it might be advantageous to have a
   standardized mechanism for querying information about the entity
   referred to by a specific tag, since it already contains enough
   information to locate its tagging entity.

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Čermák                   Expires 13 August 2021                 [Page 2]
Internet-Draft          Description of 'tag' URIs          February 2021

2.  Querying Information about a Tag

   A tag URI has the following structure, in ABNF (RFC 5234 [RFC5234]):

   tagURI = "tag:" authorityName "," date ":" specific [ "#" fragment ]

   The tag specification mandates that any software that processes tags
   MUST NOT reject authorities outside the original syntax.  Therefore,
   in case of future additions to the specification, we will consider
   the following broader definition instead:

            authorityName = ( web-host / addr-spec )
            web-host = ( host / userinfo-host-post )
            userinfo-host-port = [ userinfo "@" ] host ":" port

   <userinfo>, <host> and <port> are specified in RFC 3986 [RFC3986];
   <addr-spec> is specified in RFC 6068 [RFC6068].  As the querying
   mechanisms specified here differ substantially between those two
   forms, we will separate them into two groups of authorities, host-
   based and mail-based.  Mechanisms for other types of authorities are
   not specified in this document.

   Note that this document doesn't attempt to widen the definition of
   the tag authority from its original specification, but only provides
   a mechanism in case such an authority is used in practice.  Due to
   the fact that a host-based authority with <userinfo> could be
   mistaken for an e-mail address, only authorities with a port can be
   considered.  Thus a tag beginning with "tag:user@example.org:80," has
   a host-based authority, while a tag beginning with
   "tag:user@example.org," has a mail-based authority.

2.1.  Host-based Authority and the .well-known "tag" URI

   Tags with a host-based authority are mapped to a .well-known URI (RFC
   8615 [RFC8615]) with the "tag" suffix.  It is RECOMMENDED for a
   minter of such tags to use this service to publish a description of
   the entity identified by the tag, or to redirect to one.  When an
   application attempts to dereference a host-based tag URI, it MAY
   attempt to use the .well-known URI created via the mapping instead.

   For a tag in the form of "tag:web-host,date:specific#fragment", the
   corresponding HTTP(S) URL produced by the mapping is "http://web-
   host/.well-known/tag/specific#fragment".  The client, as well as the
   server, MAY use "https" instead of "http", as well as additional HTTP
   mechanisms such as content negotation (RFC 7231 [RFC7231]), when the
   description is accessed.

Čermák                   Expires 13 August 2021                 [Page 3]
Internet-Draft          Description of 'tag' URIs          February 2021

   There is no specific set of content types in which the description
   should be accessible, however it is RECOMMENDED to provide a
   description in at least "text/html" and either or both of
   "application/rdf+xml" and "text/turtle".  If the communication ends
   in a success (code 2xx), the response body SHOULD contain the full
   tag URI in any position.  The fragment portion of the URI, if
   present, MAY be used to select the relevant portion of the
   description, in an application or content type-dependent manner.

   For example, when a URI "tag:yaml.org,2002:int" is encountered by an
   application, it could attempt to dereference a URL
   "http://yaml.org/.well-known/tag/int".  If such a page is available,
   its content could indicate that <tag:yaml.org,2002:int> is a
   datatype.

   The date and fragment portions of the tag SHOULD NOT be a part of the
   HTTP request, thus it follows that the response body MAY describe all
   entities that differ only in the date and fragment, with the specific
   portion of the tag fixed.  This is intentional, as the date portion
   of a tag serves only to anchor the ownership of the authority in
   time, while this mapping can only be used to query the present
   version of any site.  It is however possible to use a mapping that
   uses the date portion and thus offers a higher level of
   verifiability, as described in the following section.

2.1.1.  Obtaining the Archived Version of a Description

   It is possible to devise an alternative mapping that incorporates a
   so-called archiving authority.  This is dependent on the choice of
   such an authority, and ensures that the credibility of the
   description is no lesser than that of the archiving authority.

   In the case that the tagging entity wishes to use an archiving
   authority to preserve the description of the tag, it SHOULD publish
   the description of the tag at the location as described above as
   close as possible to the time instant specified by its date portion,
   and save the URL via the archiving authority.  This description MAY
   then be queried at its archived location instead of the present one.
   This ensures its credibility does not diminish over time.

Čermák                   Expires 13 August 2021                 [Page 4]
Internet-Draft          Description of 'tag' URIs          February 2021

   There is no single specific mapping of this kind mandated by this
   document, but as an example, the Wayback Machine located at
   https://web.archive.org/ will be used to show a possible mapping.  In
   this case, "tag:domain,date:specific" is saved by navigating to the
   URL "https://web.archive.org/save/http://domain/.well-known/tag/
   specific".  Any client looking for a historical description of the
   entity can navigate to "https://web.archive.org/web/datetime/
   http://domain/.well-known/tag/specific", where <datetime> is the time
   instant represented by the full canonical date portion of the tag, in
   the yyyyMMddHHmmss format (ISO 8601 [ISO8601]).

   In case the archiving service does not support content negotiation,
   it is RECOMMENDED to use "text/html" as the primary content type of
   the description, and embed other data into it (e.g. using HTML
   extensions such as RDFa).

2.2.  Mail-based Authority

   In order to resolve tags based on an e-mail address, the application
   needs to be able to create, send and receive e-mail messages (RFC
   5322 [RFC5322]), i.e. act like a normal mail server (using SMTP (RFC
   5321 [RFC5321])).  The mapping is defined in terms of creating a URI
   in the "mailto:" scheme (RFC 6068 [RFC6068]), which the application
   MAY load and process as-is.  If the application does not support
   loading "mailto:" URIs, it MAY compose the message directly, but the
   end result MUST be equivalent.

   For a tag in the form of "tag:addr-spec,date:specific#fragment", the
   corresponding URI produced by the mapping is "mailto:addr-
   spec?subject=About%20tag%20%3Cspecific%3E".  The message SHOULD
   include the relevant fields that allow the recipient of the message
   to reply to it, such as "From:" and "Message-ID:", and it MAY
   populate other fields or add a body (to add a human-friendly text in
   case the recipient is not a machine).

   For a receiver of such a message, it is RECOMMENDED to reply with a
   description of the entity identified by the tag in question with the
   same content types of the individual parts of the reply as specified
   for host-based authorities, and at least one of the parts SHOULD
   contain the full tag URI in any position.  The reply SHOULD have the
   "In-Reply-To:" field to identify the original request.

   Due to the nature of e-mail messages, the application MUST be
   prepared for the case that a reply to the message will never be
   received, and, to comply with mail etiquette, it MUST NOT send a
   message asking for a description of a tag with the same authority and
   specific portion more than once when it is waiting for a reply or
   when the reply was already received and is still accessible.

Čermák                   Expires 13 August 2021                 [Page 5]
Internet-Draft          Description of 'tag' URIs          February 2021

   When processing a reply, the application is free to interpret the
   contents of the message as it sees fit, and MAY use the fragment
   portion of the URI to select the relevant entities.  It is
   RECOMMENDED not to make any difference between interpretations of the
   descriptions of host-based tags and mail-based tags, provided they
   are accepted by the application.

3.  IANA Considerations

3.1.  Assignment of .well-known 'tag' URI

   The following assignment of a well-known URI is made, per RFC 8615
   [RFC8615]:

   URI suffix: tag

   Change controller: IETF

   Specification document(s): This document

   Related information: None

4.  Security Considerations

   In addition to the security considerations of the underlying
   technologies, such as tags (RFC 4151 [RFC4151]), URIs (RFC 3986
   [RFC3986]), and the "mailto:" scheme (RFC 6068 [RFC6068]), the most
   notable security consideration is the case when a specific domain or
   e-mail address starts providing malicious or errorneous description
   of a tag, possibly by violation of its own security or simply due to
   a change of owners.  This is however something that linked data
   applications must already acknowledge and be ready to face for every
   usual dereferenced URL.

   Due to the advantage of containing a date portion, tags offer higher
   security than standard URLs for identifying entities, as it is
   possible to use that information and compare certificates or "whois"
   records with historical data, or simply skip tags that are too "old".
   The possibility of using an archiving authority requires additional
   trust, but prevents attacks on the original site from affecting the
   application.  Additionally, archive records that are not close enough
   to the date of the tag can also be ignored by the application.

   Mail-based tags are not as secure as host-based tags, since the
   ownership of a particular e-mail address is usually completely
   governed by its provider.  However, some providers do not allow re-
   registering an e-mail address or may implement other security
   measures, such as exposing the age of a particular mailbox.  This

Čermák                   Expires 13 August 2021                 [Page 6]
Internet-Draft          Description of 'tag' URIs          February 2021

   knowledge could be used when estimating the credibility of the
   provided description, in addition to verifying the identity of the
   domain.

   In case case, the application MAY refuse to query the description of
   a tag or ignore the result if it doesn't conform to its own security
   requirements.

5.  References

5.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [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,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC4151]  Kindberg, T. and S. Hawke, "The 'tag' URI Scheme",
              RFC 4151, DOI 10.17487/RFC4151, October 2005,
              <https://www.rfc-editor.org/info/rfc4151>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <https://www.rfc-editor.org/info/rfc5322>.

   [RFC6068]  Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
              URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010,
              <https://www.rfc-editor.org/info/rfc6068>.

   [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
              (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
              <https://www.rfc-editor.org/info/rfc8615>.

5.2.  Informative References

Čermák                   Expires 13 August 2021                 [Page 7]
Internet-Draft          Description of 'tag' URIs          February 2021

   [ISO8601]  International Organization for Standardization, "Data
              elements and interchange formats -- Information
              interchange -- Representation of dates and times",
              ISO 8601:1988, 1988.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              DOI 10.17487/RFC5321, October 2008,
              <https://www.rfc-editor.org/info/rfc5321>.

   [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
              DOI 10.17487/RFC7231, June 2014,
              <https://www.rfc-editor.org/info/rfc7231>.

Author's Address

   Marek Čermák (editor)

   Email: standards@is4.site

Čermák                   Expires 13 August 2021                 [Page 8]