Network Working Group S. Johnston
Internet-Draft Google
Intended status: Informational July 5, 2010
Expires: January 6, 2011
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.
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
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 January 6, 2011 [Page 4]
Internet-Draft Addressing Link Relations July 2010
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: <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:
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
[I-D.nottingham-http-link-header]
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
[canonical]
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
googlewebmastercentral.blogspot.com/2009/02/
specify-your-canonical.html>.
[shortlink]
Johnston, S., "shortlink Specification", April 2009,
<http://code.google.com/p/shortlink/>.
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.
B.2. draft-johnston-addressing-link-relations-01
Updated affiliations.
Tickled for IETF-78.
Author's Address
Sam Johnston
Google
Brandschenkestrasse, 110
Zuerich 8002
CH
Email: sj@google.com
Johnston Expires January 6, 2011 [Page 7]