Skip to main content

6. IANA Considerations

This specification updates the Message Header registry entry for "Link" in HTTP [RFC3864] to refer to this document.

Header field: Link
Applicable protocol: http
Status: standard
Author/change controller:
    IETF  ([email protected])
    Internet Engineering Task Force
Specification document(s):
    [RFC5988]

This specification establishes the Link Relation Type registry, and updates Atom [RFC4287] to refer to it in place of the "Registry of Link Relations".

The underlying registry data (e.g., the XML file) must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions (http://trustee.ietf.org/license-info).

Relation types are registered on the advice of a Designated Expert (appointed by the IESG or their delegate), with a Specification Required (using terminology from [RFC5226]).

The requirements for registered relation types are described in Section 4.1.

Registration requests consist of the completed registration template below, typically published in an RFC or Open Standard (in the sense described by [RFC2026], Section 7). However, to allow for the allocation of values prior to publication, the Designated Expert may approve registration once they are satisfied that a specification will be published.

Note that relation types can be registered by third parties, if the Designated Expert determines that an unregistered relation type is widely deployed and not likely to be registered in a timely manner.

The registration template is:

Relation Name:

Description:

Reference:

Notes: [optional]

Application Data: [optional]

Registration requests should be sent to the [email protected] mailing list, marked clearly in the subject line (e.g., "NEW RELATION - example" to register an "example" relation type).

Within at most 14 days of the request, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful.

Decisions (or lack thereof) made by the Designated Expert can be first appealed to Application Area Directors (contactable using [email protected] email address or directly by looking up their email addresses on http://www.iesg.org/ website) and, if the appellant is not satisfied with the response, to the full IESG (using the [email protected] mailing list). IANA should only accept registry updates from the Designated Expert(s), and should direct all requests for registration to the review mailing list.

6.2.2. Initial Registry Contents​

The Link Relation Type registry's initial contents are:

Relation Name: alternate
Description: Designates a substitute for the link's context.
Reference: [W3C.REC-html401-19991224]

Relation Name: appendix
Description: Refers to an appendix.
Reference: [W3C.REC-html401-19991224]

Relation Name: bookmark
Description: Refers to a bookmark or entry point.
Reference: [W3C.REC-html401-19991224]

Relation Name: chapter
Description: Refers to a chapter in a collection of resources.
Reference: [W3C.REC-html401-19991224]

Relation Name: contents
Description: Refers to a table of contents.
Reference: [W3C.REC-html401-19991224]

Relation Name: copyright
Description: Refers to a copyright statement that applies to the
   link's context.
Reference: [W3C.REC-html401-19991224]

Relation Name: current
Description: Refers to a resource containing the most recent
   item(s) in a collection of resources.
Reference: [RFC5005]

Relation Name: describedby
Description: Refers to a resource providing information about the
   link's context.
Documentation: <http://www.w3.org/TR/powder-dr/#assoc-linking>

Relation Name: edit
Description: Refers to a resource that can be used to edit the
   link's context.
Reference: [RFC5023]

Relation Name: edit-media
Description: Refers to a resource that can be used to edit media
   associated with the link's context.
Reference: [RFC5023]

Relation Name: enclosure
Description: Identifies a related resource that is potentially
   large and might require special handling.
Reference: [RFC4287]

Relation Name: first
Description: An IRI that refers to the furthest preceding resource
   in a series of resources.
Reference: [RFC5988]
Notes: this relation type registration did not indicate a
   reference.  Originally requested by Mark Nottingham in December
   2004.

Relation Name: glossary
Description: Refers to a glossary of terms.
Reference: [W3C.REC-html401-19991224]

Relation Name: help
Description: Refers to a resource offering help (more information,
   links to other sources information, etc.)
Reference: [W3C.REC-html401-19991224]

Relation Name: hub
Description: Refers to a hub that enables registration for
   notification of updates to the context.
Reference: <http://pubsubhubbub.googlecode.com/> <http://
   pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.3.html>
Notes: this relation type was requested by Brett Slatkin.

Relation Name: index
Description: Refers to an index.
Reference: [W3C.REC-html401-19991224]

Relation Name: last
Description: An IRI that refers to the furthest following resource
   in a series of resources.
Reference: [RFC5988]
Notes: this relation type registration did not indicate a
   reference.  Originally requested by Mark Nottingham in December
   2004.

Relation Name: latest-version
Description: Points to a resource containing the latest (e.g.,
   current) version of the context.
Reference: [RFC5829]

Relation Name: license
Description: Refers to a license associated with the link's
   context.
Reference: [RFC4946]

Relation Name: next
Description: Refers to the next resource in a ordered series of
   resources.
Reference: [W3C.REC-html401-19991224]

Relation Name: next-archive
Description: Refers to the immediately following archive resource.
Reference: [RFC5005]

Relation Name: payment
Description: indicates a resource where payment is accepted.
Reference: [RFC5988]
Notes: this relation type registration did not indicate a
   reference.  Requested by Joshua Kinberg and Robert Sayre.  It is
   meant as a general way to facilitate acts of payment, and thus
   this specification makes no assumptions on the type of payment or
   transaction protocol.  Examples may include a Web page where
   donations are accepted or where goods and services are available
   for purchase. rel="payment" is not intended to initiate an
   automated transaction.  In Atom documents, a link element with a
   rel="payment" attribute may exist at the feed/channel level and/or
   the entry/item level.  For example, a rel="payment" link at the
   feed/channel level may point to a "tip jar" URI, whereas an entry/
   item containing a book review may include a rel="payment" link
   that points to the location where the book may be purchased
   through an online retailer.

Relation Name: prev
Description: Refers to the previous resource in an ordered series
   of resources.  Synonym for "previous".
Reference: [W3C.REC-html401-19991224]

Relation Name: predecessor-version
Description: Points to a resource containing the predecessor
   version in the version history.
Reference: [RFC5829]

Relation Name: previous
Description: Refers to the previous resource in an ordered series
   of resources.  Synonym for "prev".
Reference: [W3C.REC-html401-19991224]

Relation Name: prev-archive
Description: Refers to the immediately preceding archive resource.
Reference: [RFC5005]

Relation Name: related
Description: Identifies a related resource.
Reference: [RFC4287]

Relation Name: replies
Description: Identifies a resource that is a reply to the context
   of the link.
Reference: [RFC4685]

Relation Name: section
Description: Refers to a section in a collection of resources.
Reference: [W3C.REC-html401-19991224]

Relation Name: self
Description: Conveys an identifier for the link's context.
Reference: [RFC4287]

Relation Name: service
Description: Indicates a URI that can be used to retrieve a
   service document.
Reference: [RFC5023]
Notes: When used in an Atom document, this relation type specifies
   Atom Publishing Protocol service documents by default.  Requested
   by James Snell.

Relation Name: start
Description: Refers to the first resource in a collection of
   resources.
Reference: [W3C.REC-html401-19991224]

Relation Name: stylesheet
Description: Refers to an external style sheet.
Reference: [W3C.REC-html401-19991224]

Relation Name: subsection
Description: Refers to a resource serving as a subsection in a
   collection of resources.
Reference: [W3C.REC-html401-19991224]

Relation Name: successor-version
Description: Points to a resource containing the successor version
   in the version history.
Reference: [RFC5829]

Relation Name: up
Description: Refers to a parent document in a hierarchy of
   documents.
Reference: [RFC5988]
Notes: this relation type registration did not indicate a
   reference.  Requested by Noah Slater.

Relation Name: version-history
Description: points to a resource containing the version history
   for the context.
Reference: [RFC5829]

Relation Name: via
Description: Identifies a resource that is the source of the
   information in the link's context.
Reference: [RFC4287]

Relation Name: working-copy
Description: Points to a working copy for this resource.
Reference: [RFC5829]

Relation Name: working-copy-of
Description: Points to the versioned resource from which this
   working copy was obtained.
Reference: [RFC5829]

This specification also establishes the Link Relation Application Field registry, to allow entries in the Link Relation Type registry to be extended with application-specific data (hereafter, "app data") specific to all instances of a given link relation type.

Application data is registered on the advice of a Designated Expert (appointed by the IESG or their delegate), with a Specification Required (using terminology from [RFC5226]). Registration requests consist of the completed registration template below:

Application Name:

Description:

Default Value:

Notes: [optional]

The Description SHOULD identify the value space of the app data. The Default Value MUST be appropriate to entries to which the app data does not apply.

Entries that pre-date the addition of app data will automatically be considered to have the default value for that app data; if there are exceptions, the modification of such entries should be coordinated by the Designated Expert(s), in consultation with the author of the proposed app data as well as the registrant of the existing entry (if possible).

Registration requests should be sent to the [email protected] mailing list, marked clearly in the subject line (e.g., "NEW APP DATA - example" to register "example" app data).

Within at most 14 days of the request, the Designated Expert will either approve or deny the registration request, communicating this decision to the review list. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the [email protected] mailing list) for resolution.

When a registration request is successful, the Designated Expert will forward it to IANA for publication. IANA should only accept registry updates from the Designated Expert(s), and should direct all requests for registration to the review mailing list.