Link Relations for Addressing
draft-johnston-addressing-link-relations-01

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

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 http://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 January 6, 2011.

Copyright Notice

Copyright (c) 2010 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 (http://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.

Table of Contents

1.  Introduction
2.  Terminology
3.  Link Relations
4.  Examples
5.  Security Considerations
6.  IANA Considerations
7.  References
    7.1.  Normative References
    7.2.  Informative References
Appendix A.  Contributors
Appendix B.  Change Log (to be removed by RFC Editor before publication)
    B.1.  draft-johnston-addressing-link-relations-00
    B.2.  draft-johnston-addressing-link-relations-01
§  Author's Address

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 (Link Relations).

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.

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:

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:

• A typical online store URL with category and session information in the query string
• A canonical or "preferred version" of the URL which may be common to any number of pages
• A permalink which relies on a database identifier that is guaranteed never to change
• A shortlink which is useful for space-constrained applications

Link: <http://example.com/product/swedish-fish?category=fish&sid=5678>;
      rel="self",
      <http://example.com/product/swedish-fish>; rel="canonical",
      <http://au.example.com/product/swedish-fish>; rel="mirror",
      <http://example.com/node/123>; rel="permalink",
      <http://example.com/sf>; rel="shortlink"

With the exception of canonical (which must only be specified once) there can be multiple links having the same relation:

Link: <http://example.com/product/swedish-fish>; rel="canonical",
      <http://au.example.com/product/swedish-fish>; rel="mirror",
      <http://fr.example.com/product/swedish-fish>; rel="mirror",
      <http://ie.example.com/product/swedish-fish>; rel="mirror"

It is also possible to combine relations where the same URL serves multiple roles:

Link: <http://example.com/product/swedish-fish>; rel="canonical permalink",
      <http://au.example.com/product/swedish-fish>; rel="immutable mirror",
      <http://example.com/sf>; 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 (Link Relations) are to be registered by IANA per [I‑D.nottingham‑http‑link‑header] (Nottingham, M., “Web Linking,” May 2010.).

7.  References

7.1. Normative References

7.2. Informative References

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] (Kupke, J. and M. Ohye, “Specify your canonical,” February 2009.)

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] (Johnston, S., “shortlink Specification,” April 2009.)

Appendix B.  Change Log (to be removed by RFC Editor before publication)

B.1.  draft-johnston-addressing-link-relations-00

Initial release.

B.2.  draft-johnston-addressing-link-relations-01

Updated affiliations.

Tickled for IETF-78.

Author's Address