This memo clarifies the status of the Link HTTP header and attempts to
consolidate link relations in a single registry. A means of indicating
the relationships between documents on the Web has been available for
some time in HTML, and was considered as a HTTP header in RFC 2068, but
removed from RFC 2616, due to a lack of implementation experience. There
have since surfaced many cases where a means of including this information
in HTTP headers has proved useful. However, because it was removed, the
status of the Link header is unclear, leading some to consider minting
new application-specific HTTP headers instead of reusing it. This
document seeks to address these shortcomings. Additionally, formats
other than HTML -- namely, Atom (RFC 4287) -- have also defined generic
linking mechanisms that are similar to those in HTML, but not identical.
This document aims to reconcile these differences when such links are
expressed as headers. This straw-man draft is intended to give a rough
idea of what it would take to align and consolidate the HTML and Atom
link relations into a single registry with reasonable extensibility
rules. In particular: (a) it changes the registry for Atom link relations,
and the process for registration; (b) it assigns more generic semantics
to several existing link relations, both Atom and HTML; (c) it changes
the syntax of the Link header -- in the case where extensions are present.
The Link entity-header field provides a means for describing a relationship
between two resources, generally between that of the entity associated
with the header and some other resource. An entity may include multiple
Link values. The Link header field is semantically equivalent to the
'link' element in HTML, as well as the 'atom:link' element in Atom. The
title parameter may be used to label the destination of a link such
that it can be used as identification within a human-readable menu...
Link Relation Registry: This specification is intended to update Atom
s a way of indicating the semantics of a link. Link relations are not
format-specific, and must not specify a particular format or media type
that they are to be used with. The security considerations of following
a particular link are not determined by the link's relation type; they
are determined by the specific context of the use and the media type of
the response. Likewise, a link relation should not specify what the
context of its use is, although the media type of the dereferenced link
may constrain how it is applied. New relations may be registered,
subject to IESG Approval, as outlined in RFC 2434.
No comments:
Post a Comment