[Docs] [txt|pdf|xml] [Tracker] [Email] [Nits]

Versions: 00 01

Network Working Group                                        S. Johnston
Internet-Draft                               Australian Online Solutions
Intended status: Informational                        September 21, 2009
Expires: March 25, 2010

                     Link Relations for Addressing

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   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.


   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

      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

   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

   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

   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: <http://example.com/product/swedish-fish?category=fish&sid=5678>;
       <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:

Johnston                 Expires March 25, 2010                 [Page 5]

Internet-Draft          Addressing Link Relations         September 2009

   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 are to be registered by IANA
   per [I-D.nottingham-http-link-header].

7.  References

7.1.  Normative References

              Nottingham, M., "Web Linking",
              draft-nottingham-http-link-header-06 (work in progress),
              July 2009.

7.2.  Informative References

              Kupke, J. and M. Ohye, "Specify your canonical",
              February 2009, <http://


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

   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

   Email: samj@samj.net

Johnston                 Expires March 25, 2010                 [Page 7]

Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/