idnits 2.17.1 draft-mc-tagresolution-00.txt: -(2): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. 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 (9 February 2021) is 1171 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Čermák, Ed. 3 Internet-Draft 9 February 2021 4 Intended status: Informational 5 Expires: 13 August 2021 7 Description of Entities Identified by the 'tag' URI Scheme 8 draft-mc-tagresolution-00 10 Abstract 12 This document specifies automated description resolution mechanism 13 for Uniform Resource Identifiers (URIs) in the "tag" scheme. Tag 14 URIs (also known as "tags") are designed to be non-dereferenceable, 15 however it may be useful for a tag minter to optinally provide a 16 public easily accessible description of the entity associated with a 17 tag. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 13 August 2021. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Querying Information about a Tag . . . . . . . . . . . . . . 3 55 2.1. Host-based Authority and the .well-known "tag" URI . . . 3 56 2.1.1. Obtaining the Archived Version of a Description . . . 4 57 2.2. Mail-based Authority . . . . . . . . . . . . . . . . . . 5 58 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 59 3.1. Assignment of .well-known 'tag' URI . . . . . . . . . . . 6 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 61 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 5.1. Normative References . . . . . . . . . . . . . . . . . . 7 63 5.2. Informative References . . . . . . . . . . . . . . . . . 7 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 66 1. Introduction 68 The 'tag' Uniform Resource Identifier (URI) scheme is described by 69 RFC 4151 [RFC4151]. URIs in this scheme (tags) are human-friendly 70 identifiers, internally consisting of 2 parts: the tagging entity (a 71 domain name or an e-mail address, followed by a date) and a specific 72 identifier (optional). The combination chosen for the tagging entity 73 guarantees uniqueness of tags across time and space, as long as no 74 unauthorized entity mints tags under an entity with a different 75 ownership. 77 Using tags as opaque identifiers in some cases is convenient for a 78 couple of reasons: they are simple and easily rememberable by humans, 79 the date component tells about the date of creation of the entity and 80 thus carries significant information about its relevance, and the 81 option of using e-mail addresses opens the possibility of minting new 82 tags to virtually everyone. 84 Use of tags in other contexts, such as in semantic web applications, 85 could be problematic. While dereferenceability is not a strict 86 requirement in those cases, it might be advantageous to have a 87 standardized mechanism for querying information about the entity 88 referred to by a specific tag, since it already contains enough 89 information to locate its tagging entity. 91 1.1. Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [RFC2119]. 97 2. Querying Information about a Tag 99 A tag URI has the following structure, in ABNF (RFC 5234 [RFC5234]): 101 tagURI = "tag:" authorityName "," date ":" specific [ "#" fragment ] 103 The tag specification mandates that any software that processes tags 104 MUST NOT reject authorities outside the original syntax. Therefore, 105 in case of future additions to the specification, we will consider 106 the following broader definition instead: 108 authorityName = ( web-host / addr-spec ) 109 web-host = ( host / userinfo-host-post ) 110 userinfo-host-port = [ userinfo "@" ] host ":" port 112 , and are specified in RFC 3986 [RFC3986]; 113 is specified in RFC 6068 [RFC6068]. As the querying 114 mechanisms specified here differ substantially between those two 115 forms, we will separate them into two groups of authorities, host- 116 based and mail-based. Mechanisms for other types of authorities are 117 not specified in this document. 119 Note that this document doesn't attempt to widen the definition of 120 the tag authority from its original specification, but only provides 121 a mechanism in case such an authority is used in practice. Due to 122 the fact that a host-based authority with could be 123 mistaken for an e-mail address, only authorities with a port can be 124 considered. Thus a tag beginning with "tag:user@example.org:80," has 125 a host-based authority, while a tag beginning with 126 "tag:user@example.org," has a mail-based authority. 128 2.1. Host-based Authority and the .well-known "tag" URI 130 Tags with a host-based authority are mapped to a .well-known URI (RFC 131 8615 [RFC8615]) with the "tag" suffix. It is RECOMMENDED for a 132 minter of such tags to use this service to publish a description of 133 the entity identified by the tag, or to redirect to one. When an 134 application attempts to dereference a host-based tag URI, it MAY 135 attempt to use the .well-known URI created via the mapping instead. 137 For a tag in the form of "tag:web-host,date:specific#fragment", the 138 corresponding HTTP(S) URL produced by the mapping is "http://web- 139 host/.well-known/tag/specific#fragment". The client, as well as the 140 server, MAY use "https" instead of "http", as well as additional HTTP 141 mechanisms such as content negotation (RFC 7231 [RFC7231]), when the 142 description is accessed. 144 There is no specific set of content types in which the description 145 should be accessible, however it is RECOMMENDED to provide a 146 description in at least "text/html" and either or both of 147 "application/rdf+xml" and "text/turtle". If the communication ends 148 in a success (code 2xx), the response body SHOULD contain the full 149 tag URI in any position. The fragment portion of the URI, if 150 present, MAY be used to select the relevant portion of the 151 description, in an application or content type-dependent manner. 153 For example, when a URI "tag:yaml.org,2002:int" is encountered by an 154 application, it could attempt to dereference a URL 155 "http://yaml.org/.well-known/tag/int". If such a page is available, 156 its content could indicate that is a 157 datatype. 159 The date and fragment portions of the tag SHOULD NOT be a part of the 160 HTTP request, thus it follows that the response body MAY describe all 161 entities that differ only in the date and fragment, with the specific 162 portion of the tag fixed. This is intentional, as the date portion 163 of a tag serves only to anchor the ownership of the authority in 164 time, while this mapping can only be used to query the present 165 version of any site. It is however possible to use a mapping that 166 uses the date portion and thus offers a higher level of 167 verifiability, as described in the following section. 169 2.1.1. Obtaining the Archived Version of a Description 171 It is possible to devise an alternative mapping that incorporates a 172 so-called archiving authority. This is dependent on the choice of 173 such an authority, and ensures that the credibility of the 174 description is no lesser than that of the archiving authority. 176 In the case that the tagging entity wishes to use an archiving 177 authority to preserve the description of the tag, it SHOULD publish 178 the description of the tag at the location as described above as 179 close as possible to the time instant specified by its date portion, 180 and save the URL via the archiving authority. This description MAY 181 then be queried at its archived location instead of the present one. 182 This ensures its credibility does not diminish over time. 184 There is no single specific mapping of this kind mandated by this 185 document, but as an example, the Wayback Machine located at 186 https://web.archive.org/ will be used to show a possible mapping. In 187 this case, "tag:domain,date:specific" is saved by navigating to the 188 URL "https://web.archive.org/save/http://domain/.well-known/tag/ 189 specific". Any client looking for a historical description of the 190 entity can navigate to "https://web.archive.org/web/datetime/ 191 http://domain/.well-known/tag/specific", where is the time 192 instant represented by the full canonical date portion of the tag, in 193 the yyyyMMddHHmmss format (ISO 8601 [ISO8601]). 195 In case the archiving service does not support content negotiation, 196 it is RECOMMENDED to use "text/html" as the primary content type of 197 the description, and embed other data into it (e.g. using HTML 198 extensions such as RDFa). 200 2.2. Mail-based Authority 202 In order to resolve tags based on an e-mail address, the application 203 needs to be able to create, send and receive e-mail messages (RFC 204 5322 [RFC5322]), i.e. act like a normal mail server (using SMTP (RFC 205 5321 [RFC5321])). The mapping is defined in terms of creating a URI 206 in the "mailto:" scheme (RFC 6068 [RFC6068]), which the application 207 MAY load and process as-is. If the application does not support 208 loading "mailto:" URIs, it MAY compose the message directly, but the 209 end result MUST be equivalent. 211 For a tag in the form of "tag:addr-spec,date:specific#fragment", the 212 corresponding URI produced by the mapping is "mailto:addr- 213 spec?subject=About%20tag%20%3Cspecific%3E". The message SHOULD 214 include the relevant fields that allow the recipient of the message 215 to reply to it, such as "From:" and "Message-ID:", and it MAY 216 populate other fields or add a body (to add a human-friendly text in 217 case the recipient is not a machine). 219 For a receiver of such a message, it is RECOMMENDED to reply with a 220 description of the entity identified by the tag in question with the 221 same content types of the individual parts of the reply as specified 222 for host-based authorities, and at least one of the parts SHOULD 223 contain the full tag URI in any position. The reply SHOULD have the 224 "In-Reply-To:" field to identify the original request. 226 Due to the nature of e-mail messages, the application MUST be 227 prepared for the case that a reply to the message will never be 228 received, and, to comply with mail etiquette, it MUST NOT send a 229 message asking for a description of a tag with the same authority and 230 specific portion more than once when it is waiting for a reply or 231 when the reply was already received and is still accessible. 233 When processing a reply, the application is free to interpret the 234 contents of the message as it sees fit, and MAY use the fragment 235 portion of the URI to select the relevant entities. It is 236 RECOMMENDED not to make any difference between interpretations of the 237 descriptions of host-based tags and mail-based tags, provided they 238 are accepted by the application. 240 3. IANA Considerations 242 3.1. Assignment of .well-known 'tag' URI 244 The following assignment of a well-known URI is made, per RFC 8615 245 [RFC8615]: 247 URI suffix: tag 249 Change controller: IETF 251 Specification document(s): This document 253 Related information: None 255 4. Security Considerations 257 In addition to the security considerations of the underlying 258 technologies, such as tags (RFC 4151 [RFC4151]), URIs (RFC 3986 259 [RFC3986]), and the "mailto:" scheme (RFC 6068 [RFC6068]), the most 260 notable security consideration is the case when a specific domain or 261 e-mail address starts providing malicious or errorneous description 262 of a tag, possibly by violation of its own security or simply due to 263 a change of owners. This is however something that linked data 264 applications must already acknowledge and be ready to face for every 265 usual dereferenced URL. 267 Due to the advantage of containing a date portion, tags offer higher 268 security than standard URLs for identifying entities, as it is 269 possible to use that information and compare certificates or "whois" 270 records with historical data, or simply skip tags that are too "old". 271 The possibility of using an archiving authority requires additional 272 trust, but prevents attacks on the original site from affecting the 273 application. Additionally, archive records that are not close enough 274 to the date of the tag can also be ignored by the application. 276 Mail-based tags are not as secure as host-based tags, since the 277 ownership of a particular e-mail address is usually completely 278 governed by its provider. However, some providers do not allow re- 279 registering an e-mail address or may implement other security 280 measures, such as exposing the age of a particular mailbox. This 281 knowledge could be used when estimating the credibility of the 282 provided description, in addition to verifying the identity of the 283 domain. 285 In case case, the application MAY refuse to query the description of 286 a tag or ignore the result if it doesn't conform to its own security 287 requirements. 289 5. References 291 5.1. Normative References 293 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 294 Requirement Levels", BCP 14, RFC 2119, 295 DOI 10.17487/RFC2119, March 1997, 296 . 298 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 299 Resource Identifier (URI): Generic Syntax", STD 66, 300 RFC 3986, DOI 10.17487/RFC3986, January 2005, 301 . 303 [RFC4151] Kindberg, T. and S. Hawke, "The 'tag' URI Scheme", 304 RFC 4151, DOI 10.17487/RFC4151, October 2005, 305 . 307 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 308 Specifications: ABNF", STD 68, RFC 5234, 309 DOI 10.17487/RFC5234, January 2008, 310 . 312 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 313 DOI 10.17487/RFC5322, October 2008, 314 . 316 [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' 317 URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, 318 . 320 [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers 321 (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, 322 . 324 5.2. Informative References 326 [ISO8601] International Organization for Standardization, "Data 327 elements and interchange formats -- Information 328 interchange -- Representation of dates and times", 329 ISO 8601:1988, 1988. 331 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 332 DOI 10.17487/RFC5321, October 2008, 333 . 335 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 336 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 337 DOI 10.17487/RFC7231, June 2014, 338 . 340 Author's Address 342 Marek Čermák (editor) 344 Email: standards@is4.site