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

Versions: 00 01

Network Working Group                                        S. Johnston
Internet-Draft                                                    Google
Intended status: Informational                              July 5, 2010
Expires: January 6, 2011

                     Link Relations for Addressing


   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.

Johnston                 Expires January 6, 2011                [Page 1]

Internet-Draft          Addressing Link Relations              July 2010

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
     B.2.  draft-johnston-addressing-link-relations-01 . . . . . . . . 7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7

Johnston                 Expires January 6, 2011                [Page 2]

Internet-Draft          Addressing Link Relations              July 2010

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 January 6, 2011                [Page 3]

Internet-Draft          Addressing Link Relations              July 2010

   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 January 6, 2011                [Page 4]

Internet-Draft          Addressing Link Relations              July 2010

   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 January 6, 2011                [Page 5]

Internet-Draft          Addressing Link Relations              July 2010

   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-10 (work in progress),
              May 2010.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

7.2.  Informative References

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

Johnston                 Expires January 6, 2011                [Page 6]

Internet-Draft          Addressing Link Relations              July 2010


              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.

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

   Updated affiliations.

   Tickled for IETF-78.

Author's Address

   Sam Johnston
   Brandschenkestrasse, 110
   Zuerich  8002

   Email: sj@google.com

Johnston                 Expires January 6, 2011                [Page 7]

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