idnits 2.17.1 draft-johnston-addressing-link-relations-01.txt: 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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 5, 2010) is 5037 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2616' is defined on line 240, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Johnston 3 Internet-Draft Google 4 Intended status: Informational July 5, 2010 5 Expires: January 6, 2011 7 Link Relations for Addressing 8 draft-johnston-addressing-link-relations-01 10 Abstract 12 This specification defines link relations for a number of common 13 styles of resource addressing (for example, linking to the latest vs 14 a specific version of a resource). 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on January 6, 2011. 33 Copyright Notice 35 Copyright (c) 2010 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Link Relations . . . . . . . . . . . . . . . . . . . . . . . . 4 53 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 55 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 56 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 58 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 59 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . . 7 60 Appendix B. Change Log (to be removed by RFC Editor before 61 publication) . . . . . . . . . . . . . . . . . . . . . 7 62 B.1. draft-johnston-addressing-link-relations-00 . . . . . . . . 7 63 B.2. draft-johnston-addressing-link-relations-01 . . . . . . . . 7 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 This specification defines a number of link relations that may be 69 used to indicate different types of links to resources. Each defined 70 relation makes guarantees about the URL and/or the resource it refers 71 to, such as the version which is to be retrieved or some 72 characteristic of the URL itself. 74 [[ Feedback is welcome on the ietf-http-wg@w3.org mailing list, 75 although this is NOT a work item of the HTTPBIS WG. ]] 77 2. Terminology 79 The following term definitions clarify the concise link relation 80 descriptions in Section 3. 82 canonical Designates the preferred or standard way of writing the 83 URL, or the "canonical form" (also known as "standard form" or 84 "normal form"). While there can be an infinite number of 85 references to identical or vastly similar resources (for example 86 with different sort orders, highlighting or category information), 87 specifying which one is "canonical" allows automated agents to 88 avoid treating every such URL as unique. Search engines may use 89 this to consolidate properties such as link popularity and display 90 the preferred URL in search results, while other clients may 91 identify, save and share the preferred version rather than the one 92 they originally retrieved. 94 current Identifies resource(s) which are occuring in or belonging to 95 the present time, but may not necessarily be the single most 96 recent or "latest" version specifically. For example an entry or 97 page of a feed may identify the most recent entries in that feed 98 using the "current" relation. 100 immutable Refers to an immutable version of the link's context that 101 is not subject or susceptible to change or variation. This may 102 refer to a read-only resource, an archived copy of an otherwise 103 dynamic resource, a specific version in a version control system, 104 etc. This is in contrast to links which return the latest version 105 of the resource at any given time. 107 latest Refers to the single most recent version of the link's 108 context, which may be updated at any time. As most URLs return 109 the most recent version of the resource this relation is most 110 useful with version control systems. For example, older versions 111 of the resource may refer to the latest version. 113 mirror Provides a rudimentary facility to specify one or more 114 identical mirrors from which clients can obtain a resource. For 115 example a large enclosure may be available for download from a 116 number of different servers in different geographical locations in 117 order to distribute server load, reduce network load and improve 118 availability and performance. Link extensions for indicating 119 geographical location, slots, bandwidth, preference, etc. may be 120 defined in a future Internet-Draft. 122 permalink Designates an immutable URL which is not subject or 123 susceptible to change or variation even if the resource itself is 124 updated. A portmanteau of "permanent" and "link", the relation 125 allows clients to save and share a URL with the guarantee that it 126 will resolve to that resource so long as it still exists. 127 Typically the more information that is included in a link the more 128 volatile it is likely to be. For example a link to a blog post 129 that includes the title may change whenever the title is updated. 130 Where "permalink" is specified such changes must not cause the 131 designated URL to stop resolving or to resolve to another 132 resource. 134 Note: It is inappropriate to use the "bookmark" relation for this 135 as it is "used to provide direct links to key entry points into an 136 extended document" rather than as a reference to the resource 137 itself. 139 shortlink Designates one or more short link(s) which may be used in 140 artificially (e.g. microblogging) or technically (e.g. short 141 message service) constrained channels, or anywhere humans are 142 required to transcribe a link (e.g. print, television and radio). 143 This obviates the need to resort to third-party URL shortening 144 services by allowing webmasters to centrally specify preferred 145 short link(s) for use by all clients. For performance and 146 security reasons the domain should match that of the canonical 147 URL, unless a shorter domain is required/desired. Where more than 148 one is specified the client may select one at random, offer the 149 choice to the user, select the first, last or shortest one at 150 random, or intelligently determine which is the most suitable for 151 the purpose (for example, one with an alphabetical rather than 152 numerical path). 154 3. Link Relations 156 The following link relations are defined: 158 canonical Designates the preferred version of the URL for the link's 159 context. 161 current Identifies resource(s) which are occurring in or belonging 162 to the present time. 164 Note: Previously defined by RFC 5005 as "A URI that, when 165 dereferenced, returns a feed document containing the most recent 166 entries in the feed." 168 immutable Identifies an immutable version of the link's context. 170 latest Identifies the most recent version of the link's context. 172 mirror Identifies one or more exact replicas of the link's context. 174 permalink Designates an immutable "permanent link" for the link's 175 context. 177 shortlink Designates a "short link" for the link's context. 179 4. Examples 181 The following example illustrates: 183 o A typical online store URL with category and session information 184 in the query string 186 o A canonical or "preferred version" of the URL which may be common 187 to any number of pages 189 o A permalink which relies on a database identifier that is 190 guaranteed never to change 192 o A shortlink which is useful for space-constrained applications 194 Link: ; 195 rel="self", 196 ; rel="canonical", 197 ; rel="mirror", 198 ; rel="permalink", 199 ; rel="shortlink" 201 With the exception of canonical (which must only be specified once) 202 there can be multiple links having the same relation: 204 Link: ; rel="canonical", 205 ; rel="mirror", 206 ; rel="mirror", 207 ; rel="mirror" 209 It is also possible to combine relations where the same URL serves 210 multiple roles: 211 Link: ; rel="canonical permalink", 212 ; rel="immutable mirror", 213 ; rel="latest shortlink" 215 5. Security Considerations 217 Automated agents should take care when these relation crosses 218 administrative domains (e.g., the URI has a different authority than 219 the current document). In particular, third-party URL shortening 220 services may be unreliable. 222 Depending on the application it may not be appropriate to rely on the 223 "immutable" relation. For example, a malicious user may declare a 224 resource immutable and then modify it anyway. 226 6. IANA Considerations 228 The link relations defined in Section 3 are to be registered by IANA 229 per [I-D.nottingham-http-link-header]. 231 7. References 233 7.1. Normative References 235 [I-D.nottingham-http-link-header] 236 Nottingham, M., "Web Linking", 237 draft-nottingham-http-link-header-10 (work in progress), 238 May 2010. 240 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 241 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 242 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 244 7.2. Informative References 246 [canonical] 247 Kupke, J. and M. Ohye, "Specify your canonical", 248 February 2009, . 252 [shortlink] 253 Johnston, S., "shortlink Specification", April 2009, 254 . 256 Appendix A. Contributors 258 The canonical relation was originally defined by Google as "a format 259 that allows you to publicly specify your preferred version of a URL". 260 [canonical] 262 The shortlink relation was originally defined by Sam Johnston for 263 space-constrained (e.g. microblogging, mobile) and manual entry (e.g. 264 printed, spoken) applications. It was the primary motivator for this 265 specification and when it was submitted for discussion a number of 266 separate but related requirements were revealed. [shortlink] 268 Appendix B. Change Log (to be removed by RFC Editor before publication) 270 B.1. draft-johnston-addressing-link-relations-00 272 Initial release. 274 B.2. draft-johnston-addressing-link-relations-01 276 Updated affiliations. 278 Tickled for IETF-78. 280 Author's Address 282 Sam Johnston 283 Google 284 Brandschenkestrasse, 110 285 Zuerich 8002 286 CH 288 Email: sj@google.com