<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="link-relations.xsl"?>
<?oxygen RNGSchema="link-relations.rng" type="xml"?>
<registry xmlns="http://www.iana.org/assignments" id="link-relations">
  <title>Atom Link Relations</title>
  <updated>2009-01-26</updated>


<registry id="link-relations-1">
  <title>Atom Link Relations</title>
  <xref type="rfc" data="rfc4287"/> 
  <registration_rule>IESG Approval (via request to IANA)</registration_rule>
  
  <record>
    <value>alternate</value>
    <xref type="rfc" data="rfc4287"/>
  </record>
  <record date="2006-02-02">
    <value>current</value>
    <description>A URI that, when dereferenced, returns a feed document
      containing the most recent entries in the feed.</description>
    <expected_display_characteristics>Undefined; this relation can be used for
      background processing or to provide extended functionality without
      displaying its value.</expected_display_characteristics>
    <security_considerations>Automated agents should take care when this
      relation crosses administrative domains (e.g., the URI has a different
      authority than the current document).</security_considerations>
    <xref type="rfc" data="rfc5005"/>
  </record>
  <record date="2009-02-20">
    <value>describedby</value>
    <description>The relationship A 'describedby' B asserts that resource B
      provides a description of resource A. There are no constraints on the
      format or representation of either A or B, neither are there any further
      constraints on either resource.</description>
    <expected_display_characteristics>None</expected_display_characteristics>
    <security_considerations>Descriptions of resources may be socially sensitive, may require
      processing to be understood and may or may not not be accurate.
      Consumers of descriptive resources should be aware of the source and
      chain of custody of the data. Security considerations for URIs (Section
      7 of RFC 3986) and IRIs (Section 8 of RFC 3987 ) apply to the extent
      that describing resources may affect consumers' decisions about how or
      whether to retrieve those resources.</security_considerations>
    <xref type="person" data="Phil_Archer"/>
    <xref type="uri" data="http://www.w3.org/TR/powder-dr/#assoc-linking"/>
  </record>
  
  
  <record date="2007-07-27">
    <value>edit</value>
    <description>An IRI of an editable Member Entry.  When appearing within an
      atom:entry, the href IRI can be used to retrieve, update and delete
      the Resource represented by that Entry.</description>
    <expected_display_characteristics>Undefined; this relation can be used for
      background processing or to provide extended functionality without
      displaying its value.</expected_display_characteristics>
    <security_considerations>Automated agents should take care when this
      relation crosses administrative domains (e.g., the URI has a different
      authority than the current document).</security_considerations>
    <xref type="rfc" data="rfc5023"/>
  </record>
  
  
  <record date="2007-07-27">
    <value>edit-media</value>
    <description>An IRI of an editable Media Resource.  When appearing within
      an atom:entry, the href IRI can be used to retrieve, update and delete
      the Media Resource associated with that Entry.</description>
    <expected_display_characteristics>Undefined; this relation can be used for
      background processing or to provide extended functionality without
      displaying its value.</expected_display_characteristics>
    <security_considerations>Automated agents should take care when this
      relation crosses administrative domains (e.g., the URI has a different
      authority than the current document).</security_considerations>
    <xref type="rfc" data="rfc5023"/>
  </record>
  
  
  <record>
    <value>enclosure</value>
    <xref type="rfc" data="rfc4287"/>
  </record>
  <record date="2006-02-02">
    <value>first</value>
    <description>A URI that refers to the furthest preceding document in a
      series of documents.</description>
    <expected_display_characteristics>Undefined; this relation can be used for
      background processing or to provide extended functionality without
      displaying its value.</expected_display_characteristics>
    <security_considerations>Automated agents should take care when this
      relation crosses administrative domains (e.g., the URI has a different
      authority than the current document). Such agents should also take
      care to detect circular references.</security_considerations>
    <xref type="text">Mark Nottingham, December 2004</xref>
  </record>
  
  
  <record date="2009-11-20">
    <value>hub</value>
    <description>A URI for a hub that enables registration for real-time updates 
      to the resource</description>
    <expected_display_characteristics/>
    <security_considerations/>
    <xref type="person" data="Brett_Slatkin"/>
    <xref type="uri" data="http://pubsubhubbub.googlecode.com"/>
  </record>
 
 
  <record date="2006-02-02">
    <value>last</value>
    <description>A URI that refers to the furthest following document in a
      series of documents.</description>
    <expected_display_characteristics>Undefined; this relation can be used for
      background processing or to provide extended functionality without
      displaying its value.</expected_display_characteristics>
    <security_considerations>Automated agents should take care when this
      relation crosses administrative domains (e.g., the URI has a different
      authority than the current document). Such agents should also take
      care to detect circular references.</security_considerations>
    <xref type="text">Mark Nottingham, December 2004</xref>
  </record>
  
  
  <record>
    <value>latest-version</value>
    <description>   When included on a versioned resource, this link points to a resource
      containing the latest (e.g., current) version.
      
      The latest version is defined by the system.  For linear versioning
      systems, this is probably the latest version by timestamp.  For
      systems that support branching, there will be multiple latest
      versions, one for each branch in the version history.
      
      Some systems may allow multiple of these link relations.
    </description>
    <expected_display_characteristics>Undefined; this relation can be
      used for background processing or to provide extended
      functionality without displaying its value.
    </expected_display_characteristics>
    <security_considerations>   Automated agents should take care when these relations cross
      administrative domains (e.g., the URI has a different authority than
      the current document).  Such agents should also take care to detect
      circular references.
      
      Care should be applied when versioned resources are subject to
      differing access policies.  In this case, exposing links may leak
      information even if the linked resource itself is properly secured.
      In particular, the syntax of the link URI/IRI could expose sensitive
      information (see Section 16.2 of [RFC3253] for a similar
      consideration in WebDAV Versioning).  Note that this applies to
      exposing link metadata in general, not only to links related to
      versioning.
    </security_considerations>
    <xref type="draft" data="RFC-brown-versioning-link-relations-07"/>
  </record>
  
  
  <record date="2007-05-14">
    <value>license</value>
    <xref type="rfc" data="rfc4946"/>
  </record>
  <record date="2006-02-02">
    <value>next</value>
    <description>A URI that refers to the immediately following document in a
      series of documents.</description>
    <expected_display_characteristics>Undefined; this relation can be used for
      background processing or to provide extended functionality without
      displaying its value.</expected_display_characteristics>
    <security_considerations>Automated agents should take care when this
      relation crosses administrative domains (e.g., the URI has a different
      authority than the current document). Such agents should also take
      care to detect circular references.</security_considerations>
    <xref type="rfc" data="rfc5005"/>
  </record>
  
  
  <record date="2007-07-13">
    <value>next-archive</value>
    <description>A URI that refers to the immediately following archive
      document.</description>
    <security_considerations>See
      [RFC-nottingham-atompub-feed-history-11.txt]</security_considerations>
    <xref type="rfc" data="rfc5005"/>
  </record>
  
  
  <record date="2006-02-02">
    <value>payment</value>
    <description>rel="payment" indicates a URI where payment is accepted. 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 WWW page where donations
      are accepted or where goods and services are available for purchase.

      rel="payment" is not intended to initiate an automated transaction.

      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.</description>
    <expected_display_characteristics>End-user software could support
      rel="payment" by displaying a "payment button" along with the content.
      Alternatively, content aggregators may display a payment hyperlink
      containing the text specified in a corresponding title attribute
      within the &lt;link&gt; element, for example:

      &lt;link rel="payment" href="http://example.com/c.r.e.a.m"
      title="give me the loot"/&gt;

      May display either a payment button or a hyperlink containing the
      text, "give me the loot."</expected_display_characteristics>
    <security_considerations>The link element is subject to tampering and
      observation, as is the linked resource. For that reason,
      implementations should clearly signal the level trust and privacy a
      linked resource provides. If present, digital signatures provide
      authentication, message integrity, and non-repudiation with proof of
      origin. Encryption provides data confidentiality.  Implementations
      should also consider the level of confidentiality and message
      integrity provided by the transport used to reach the payment
      resource.</security_considerations>
    <xref type="person" data="Joshua_Kinberg"/>
    <xref type="person" data="Robert_Sayre"/>
  </record>


  <record>
    <value>predecessor-version</value>
    <description>When included on a versioned resource, this link points to a resource
      containing the predecessor version in the version history.
      
      Some systems may allow multiple of these link relations in the case
      of a multiple branches merging.
    </description>
    <expected_display_characteristics>Undefined; this relation can be
      used for background processing or to provide extended
      functionality without displaying its value.
    </expected_display_characteristics>
    <security_considerations>   Automated agents should take care when these relations cross
      administrative domains (e.g., the URI has a different authority than
      the current document).  Such agents should also take care to detect
      circular references.
      
      Care should be applied when versioned resources are subject to
      differing access policies.  In this case, exposing links may leak
      information even if the linked resource itself is properly secured.
      In particular, the syntax of the link URI/IRI could expose sensitive
      information (see Section 16.2 of [RFC3253] for a similar
      consideration in WebDAV Versioning).  Note that this applies to
      exposing link metadata in general, not only to links related to
      versioning.
    </security_considerations>
    <xref type="draft" data="RFC-brown-versioning-link-relations-07"/>
  </record>

  
  <record date="2007-07-13">
    <value>prev-archive</value>
    <description>A URI that refers to the immediately preceding archive
      document.</description>
    <security_considerations>See
      [RFC-nottingham-atompub-feed-history-11.txt]</security_considerations>
    <xref type="rfc" data="rfc5005"/>
  </record>
  <record date="2006-02-02">
    <value>previous</value>
    <description>A URI that refers to the immediately preceding document in a
      series of documents.</description>
    <expected_display_characteristics>Undefined; this relation can be used for
      background processing or to provide extended functionality without
      displaying its value.</expected_display_characteristics>
    <security_considerations>Automated agents should take care when this
      relation crosses administrative domains (e.g., the URI has a different
      authority than the current document). Such agents should also take
      care to detect circular references.</security_considerations>
    <xref type="rfc" data="rfc5005"/>
  </record>
  
  
  <record>
    <value>related</value>
    <xref type="rfc" data="rfc4287"/>
  </record>
  
  
  <record date="2006-06-28">
    <value>replies</value>
    <xref type="rfc" data="rfc4685"/>
  </record>
  
  
  <record>
    <value>self</value>
    <xref type="rfc" data="rfc4287"/>
  </record>
  
  
  <record date="2008-05-20">
    <value>service</value>
    <description>rel="service" indicates a URI that can be used to retrieve an
      Atom Publishing Protocol Service Document as defined by RFC
      5023.</description>
    <expected_display_characteristics>Support for rel="service" links will vary
      across user agent implementations. The link relation is intended to
      provide user agents with a means of auto-discovering service endpoints so
      that basic configuration actions can be performed automatically with
      minimal user input. User agents may or may not present the link to end
      users.</expected_display_characteristics>
    <security_considerations>The link element is subject to tampering and
      observation, as is the linked resource. For that reason, implementations
      should clearly signal the level trust and privacy a linked resource
      provides. If present, digital signatures provide authentication, message
      integrity, and non-repudiation with proof of origin. Encryption provides
      data confidentiality. Implementations should also consider the level of
      confidentiality and message integrity provided by the transport used to
      reach the payment resource.</security_considerations>
    <xref type="person" data="James_Snell"/>
  </record>
  
  
  <record>
    <value>successor-version</value>
    <description>When included on a versioned resource, this link points to a resource
      containing the successor version in the version history.
      
      Some systems may allow multiple of these link relations in order to
      support branching.
    </description>
    <expected_display_characteristics>Undefined; this relation can be
      used for background processing or to provide extended
      functionality without displaying its value.
    </expected_display_characteristics>
    <security_considerations>   Automated agents should take care when these relations cross
      administrative domains (e.g., the URI has a different authority than
      the current document).  Such agents should also take care to detect
      circular references.
      
      Care should be applied when versioned resources are subject to
      differing access policies.  In this case, exposing links may leak
      information even if the linked resource itself is properly secured.
      In particular, the syntax of the link URI/IRI could expose sensitive
      information (see Section 16.2 of [RFC3253] for a similar
      consideration in WebDAV Versioning).  Note that this applies to
      exposing link metadata in general, not only to links related to
      versioning.
    </security_considerations>
    <xref type="draft" data="RFC-brown-versioning-link-relations-07"/>
  </record>
  
  
  <record date="2009-01-28">
    <value>up</value>
    <description>A URI that refers to a parent document in a hierarchy of
      documents.
    </description>
    <expected_display_characteristics>Undefined; this relation can be used for
      background processing or to provide extended functionality without
      displaying its value.</expected_display_characteristics>
    <security_considerations>Automated agents should take care when this
      relation crosses administrative domains (e.g., the URI has a different
      authority than the current document). Such agents should also take care to
      detect circular references.</security_considerations>
    <xref type="person" data="Noah_Slater"/>
  </record>
  
  
  <record>
    <value>version-history</value>
    <description>When included on a versioned resource, this link points to a resource
      containing the version history for this resource.
    </description>
    <expected_display_characteristics>Undefined; this relation can be
      used for background processing or to provide extended
      functionality without displaying its value.
    </expected_display_characteristics>
    <security_considerations>   Automated agents should take care when these relations cross
      administrative domains (e.g., the URI has a different authority than
      the current document).  Such agents should also take care to detect
      circular references.
      
      Care should be applied when versioned resources are subject to
      differing access policies.  In this case, exposing links may leak
      information even if the linked resource itself is properly secured.
      In particular, the syntax of the link URI/IRI could expose sensitive
      information (see Section 16.2 of [RFC3253] for a similar
      consideration in WebDAV Versioning).  Note that this applies to
      exposing link metadata in general, not only to links related to
      versioning.
     </security_considerations>
    <xref type="draft" data="RFC-brown-versioning-link-relations-07"/>
  </record>
  
  
  <record>
    <value>via</value>
    <xref type="rfc" data="rfc4287"/>
  </record>
  
  
  <record>
    <value>working-copy</value>
    <description>When included on a versioned resource, this link points to a working
      copy for this resource.
      
      Some systems may allow multiple of these link relations.
    </description>
    <expected_display_characteristics>Undefined; this relation can be
      used for background processing or to provide extended
      functionality without displaying its value.
    </expected_display_characteristics>
    <security_considerations>   Automated agents should take care when these relations cross
      administrative domains (e.g., the URI has a different authority than
      the current document).  Such agents should also take care to detect
      circular references.
      
      Care should be applied when versioned resources are subject to
      differing access policies.  In this case, exposing links may leak
      information even if the linked resource itself is properly secured.
      In particular, the syntax of the link URI/IRI could expose sensitive
      information (see Section 16.2 of [RFC3253] for a similar
      consideration in WebDAV Versioning).  Note that this applies to
      exposing link metadata in general, not only to links related to
      versioning.
    </security_considerations>
    <xref type="draft" data="RFC-brown-versioning-link-relations-07"/>
  </record>
  
  
  <record>
    <value>working-copy-of</value>
    <description>When included on a working copy, this link points to the versioned
      resource from which this working copy was obtained.
    </description>
    <expected_display_characteristics>Undefined; this relation can be
      used for background processing or to provide extended
      functionality without displaying its value.
    </expected_display_characteristics>
    <security_considerations>   Automated agents should take care when these relations cross
      administrative domains (e.g., the URI has a different authority than
      the current document).  Such agents should also take care to detect
      circular references.
      
      Care should be applied when versioned resources are subject to
      differing access policies.  In this case, exposing links may leak
      information even if the linked resource itself is properly secured.
      In particular, the syntax of the link URI/IRI could expose sensitive
      information (see Section 16.2 of [RFC3253] for a similar
      consideration in WebDAV Versioning).  Note that this applies to
      exposing link metadata in general, not only to links related to
      versioning.
    </security_considerations>
    <xref type="draft" data="RFC-brown-versioning-link-relations-07"/>
  </record>
  
  
</registry>
  
  <people>
    <person id="Brett_Slatkin">
      <name>Brett Slatkin</name>
      <uri>mailto:bslatkin&amp;google.com</uri>
      <updated>2009-11-20</updated>
    </person>
    <person id="James_Snell">
      <name>James Snell</name>
      <uri>mailto:jasnell&amp;gmail.com</uri>
      <updated>2008-05-20</updated>
    </person>
    <person id="Joshua_Kinberg">
      <name>Joshua Kinberg</name>
      <uri>mailto:jkinberg&amp;gmail.com</uri>
      <updated>2006-02</updated>
    </person>
    <person id="Noah_Slater">
      <name>Noah Slater</name>
      <uri>mailto:nslater&amp;tumbolia.org</uri>
      <updated>2009-01-30</updated>
    </person>
    <person id="Phil_Archer">
      <name>Phil Archer</name>
      <uri>mailto:phil&amp;philarcher.org</uri>
      <updated>2009-02-20</updated>
    </person>
    <person id="Robert_Sayre">
      <name>Robert Sayre</name>
      <uri>mailto:sayrer&amp;gmail.com</uri>
      <updated>2006-02</updated>
    </person>
  </people>
</registry>
