Network Working Group S. Johnston Internet-Draft Australian Online Solutions Intended status: Informational September 21, 2009 Expires: March 25, 2010 Link Relations for Addressing draft-johnston-addressing-link-relations-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 25, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This specification defines link relations for a number of common styles of resource addressing (for example, linking to the latest vs a specific version of a resource). Johnston Expires March 25, 2010 [Page 1] Internet-Draft Addressing Link Relations September 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Link Relations . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . . 7 Appendix B. Change Log (to be removed by RFC Editor before publication) . . . . . . . . . . . . . . . . . . . . . 7 B.1. draft-johnston-addressing-link-relations-00 . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Johnston Expires March 25, 2010 [Page 2] Internet-Draft Addressing Link Relations September 2009 1. Introduction This specification defines a number of link relations that may be used to indicate different types of links to resources. Each defined relation makes guarantees about the URL and/or the resource it refers to, such as the version which is to be retrieved or some characteristic of the URL itself. [[ Feedback is welcome on the ietf-http-wg@w3.org mailing list, although this is NOT a work item of the HTTPBIS WG. ]] 2. Terminology The following term definitions clarify the concise link relation descriptions in Section 3. canonical Designates the preferred or standard way of writing the URL, or the "canonical form" (also known as "standard form" or "normal form"). While there can be an infinite number of references to identical or vastly similar resources (for example with different sort orders, highlighting or category information), specifying which one is "canonical" allows automated agents to avoid treating every such URL as unique. Search engines may use this to consolidate properties such as link popularity and display the preferred URL in search results, while other clients may identify, save and share the preferred version rather than the one they originally retrieved. current Identifies resource(s) which are occuring in or belonging to the present time, but may not necessarily be the single most recent or "latest" version specifically. For example an entry or page of a feed may identify the most recent entries in that feed using the "current" relation. immutable Refers to an immutable version of the link's context that is not subject or susceptible to change or variation. This may refer to a read-only resource, an archived copy of an otherwise dynamic resource, a specific version in a version control system, etc. This is in contrast to links which return the latest version of the resource at any given time. latest Refers to the single most recent version of the link's context, which may be updated at any time. As most URLs return the most recent version of the resource this relation is most useful with version control systems. For example, older versions of the resource may refer to the latest version. Johnston Expires March 25, 2010 [Page 3] Internet-Draft Addressing Link Relations September 2009 mirror Provides a rudimentary facility to specify one or more identical mirrors from which clients can obtain a resource. For example a large enclosure may be available for download from a number of different servers in different geographical locations in order to distribute server load, reduce network load and improve availability and performance. Link extensions for indicating geographical location, slots, bandwidth, preference, etc. may be defined in a future Internet-Draft. permalink Designates an immutable URL which is not subject or susceptible to change or variation even if the resource itself is updated. A portmanteau of "permanent" and "link", the relation allows clients to save and share a URL with the guarantee that it will resolve to that resource so long as it still exists. Typically the more information that is included in a link the more volatile it is likely to be. For example a link to a blog post that includes the title may change whenever the title is updated. Where "permalink" is specified such changes must not cause the designated URL to stop resolving or to resolve to another resource. Note: It is inappropriate to use the "bookmark" relation for this as it is "used to provide direct links to key entry points into an extended document" rather than as a reference to the resource itself. shortlink Designates one or more short link(s) which may be used in artificially (e.g. microblogging) or technically (e.g. short message service) constrained channels, or anywhere humans are required to transcribe a link (e.g. print, television and radio). This obviates the need to resort to third-party URL shortening services by allowing webmasters to centrally specify preferred short link(s) for use by all clients. For performance and security reasons the domain should match that of the canonical URL, unless a shorter domain is required/desired. Where more than one is specified the client may select one at random, offer the choice to the user, select the first, last or shortest one at random, or intelligently determine which is the most suitable for the purpose (for example, one with an alphabetical rather than numerical path). 3. Link Relations The following link relations are defined: Johnston Expires March 25, 2010 [Page 4] Internet-Draft Addressing Link Relations September 2009 canonical Designates the preferred version of the URL for the link's context. current Identifies resource(s) which are occurring in or belonging to the present time. Note: Previously defined by RFC 5005 as "A URI that, when dereferenced, returns a feed document containing the most recent entries in the feed." immutable Identifies an immutable version of the link's context. latest Identifies the most recent version of the link's context. mirror Identifies one or more exact replicas of the link's context. permalink Designates an immutable "permanent link" for the link's context. shortlink Designates a "short link" for the link's context. 4. Examples The following example illustrates: o A typical online store URL with category and session information in the query string o A canonical or "preferred version" of the URL which may be common to any number of pages o A permalink which relies on a database identifier that is guaranteed never to change o A shortlink which is useful for space-constrained applications Link: ; rel="self", ; rel="canonical", ; rel="mirror", ; rel="permalink", ; rel="shortlink" With the exception of canonical (which must only be specified once) there can be multiple links having the same relation: Johnston Expires March 25, 2010 [Page 5] Internet-Draft Addressing Link Relations September 2009 Link: ; rel="canonical", ; rel="mirror", ; rel="mirror", ; rel="mirror" It is also possible to combine relations where the same URL serves multiple roles: Link: ; rel="canonical permalink", ; rel="immutable mirror", ; rel="latest shortlink" 5. Security Considerations Automated agents should take care when these relation crosses administrative domains (e.g., the URI has a different authority than the current document). In particular, third-party URL shortening services may be unreliable. Depending on the application it may not be appropriate to rely on the "immutable" relation. For example, a malicious user may declare a resource immutable and then modify it anyway. 6. IANA Considerations The link relations defined in Section 3 are to be registered by IANA per [I-D.nottingham-http-link-header]. 7. References 7.1. Normative References [I-D.nottingham-http-link-header] Nottingham, M., "Web Linking", draft-nottingham-http-link-header-06 (work in progress), July 2009. 7.2. Informative References [canonical] Kupke, J. and M. Ohye, "Specify your canonical", February 2009, . [shortlink] Johnston Expires March 25, 2010 [Page 6] Internet-Draft Addressing Link Relations September 2009 Johnston, S., "shortlink Specification", April 2009, . Appendix A. Contributors The canonical relation was originally defined by Google as "a format that allows you to publicly specify your preferred version of a URL". [canonical] The shortlink relation was originally defined by Sam Johnston for space-constrained (e.g. microblogging, mobile) and manual entry (e.g. printed, spoken) applications. It was the primary motivator for this specification and when it was submitted for discussion a number of separate but related requirements were revealed. [shortlink] Appendix B. Change Log (to be removed by RFC Editor before publication) B.1. draft-johnston-addressing-link-relations-00 Initial release. Author's Address Sam Johnston Australian Online Solutions GPO Box 296 Sydney, NSW 2001 AU Email: samj@samj.net Johnston Expires March 25, 2010 [Page 7]