Web Linkingmnot@mnot.nethttp://www.mnot.net/
General
link relationThis specification defines a way to indicate the relationships between resources on the Web
(“links”) and the type of those relationships (“link relation types”).It also defines the use of such links in HTTP headers with the Link header field.This is a work-in-progress to revise RFC5988.The issues list can be found at https://github.com/mnot/I-D/labels/rfc5988bis.The most recent (often, unpublished) draft is at https://mnot.github.io/I-D/rfc5988bis/.Recent changes are listed at https://github.com/mnot/I-D/commits/gh-pages/rfc5988bis.This specification defines a way to indicate the relationships between resources on the Web
(“links”) and the type of those relationships (“link relation types”).HTML and Atom both have well-defined concepts of linking;
this specification generalises this into a framework that encompasses linking in these formats and
(potentially) elsewhere.Furthermore, this specification formalises an HTTP header field for conveying such links, having
been originally defined in Section 19.6.2.4 of , but removed from .The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”,
“RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14,
, as scoped to those conformance targets.This document uses the Augmented Backus-Naur Form (ABNF) notation of , including the
#rule, and explicitly includes the following rules from it: quoted-string, token, SP (space),
LOALPHA, DIGIT.Additionally, the following rules are included from : URI and URI-Reference; from
: type-name and subtype-name; from :
media_query_list; from : Language-Tag; and from ,
ext-value and parmname.In this specification, a link is a typed connection between two resources, and is comprised of:A link context,a link relation type (),a link target, andoptionally, target attributes.A link can be viewed as a statement of the form “{link context} has a {link relation type} resource
at {link target}, which has {target attributes}”.Link contexts and link targets are both IRIs . However, in the common case, the link
context will also be a URI , because many protocols (such as HTTP) do not support
dereferencing IRIs. Likewise, the link target will be sometimes be converted to a URI (see
, Section 3.1) in places that do not support IRIs (such as the Link header field defined
in ).This specification does not place restrictions on the cardinality of links; there can be multiple
links to and from a particular target, and multiple links of the same or different types between a
given context and target. Likewise, the relative ordering of links in any particular
serialisation, or between serialisations (e.g., the Link header field and in-content links) is not
specified or significant in this specification; applications that wish to consider ordering
significant can do so.Target attributes are a set of key/value pairs that describe the link or its target; for example,
a media type hint. This specification does not attempt to coordinate their names, cardinality or
use, but individual link relations, link serialisations and link applications can do so. This
specification does provide common target attributes for use in the Link HTTP header field.Links are conveyed in link serialisations; they are the “bytes on the wire”, and can occur in
various forms. This specification does not define a general syntax for links, nor does
it mandate a specific context for any given link; it is expected that serialisations of links will
specify both aspects. One such serialisation is communication of links through HTTP headers,
specified in .Finally, links are consumed by link applications. Generally, an application will define the link
relation types it uses, along with the serialisations that they might occur within. For example,
the application “Web browsing” looks for the “stylesheet” link relation type in the HTML link
serialisation.In the simplest case, a link relation type identifies the semantics of a link. For example, a link
with the relation type “copyright” indicates that the resource identified by the link target is a
statement of the copyright terms applying to the current link context.Link relation types can also be used to indicate that the target resource has particular
attributes, or exhibits particular behaviours; for example, a “service” link implies that the
identified resource is part of a defined protocol (in this case, a service description).Relation types are not to be confused with media types ; they do not identify the format
of the representation that results when the link is dereferenced. Rather, they only describe how
the current context is related to another resource.Relation types SHOULD NOT infer any additional semantics based upon the presence or absence of
another link relation type, or its own cardinality of occurrence. An exception to this is the
combination of the “alternate” and “stylesheet” registered relation types, which has special
meaning in HTML for historical reasons.There are two kinds of relation types: registered and extension.Well-defined relation types can be registered as tokens for convenience and/or to promote reuse by
other applications, using the procedure in .Registered relation type names MUST conform to the reg-rel-type rule, and MUST be compared
character-by-character in a case-insensitive fashion. They SHOULD be appropriate to the specificity
of the relation type; i.e., if the semantics are highly specific to a particular application, the
name should reflect that, so that more general names are available for less specific use.Registered relation types MUST NOT constrain the media type of the link context, and MUST NOT
constrain the available representation media types of the link target. However, they can specify
the behaviours and properties of the target resource (e.g., allowable HTTP methods, request and
response media types that must be supported).Historically, applications have sometimes referred to registered relation types with a URI
(e.g., ) by prefixing their names with an application-defined base URI. This
practice is NOT RECOMMENDED, because the resulting strings will not be considered equivalent to the
registered relation types by other processors. Applications that do use such URIs internally MUST
NOT use them in link serialisations that do not explicitly accommodate them.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 ).The Expert(s) will establish procedures for requesting registrations, and make them available from
the registry page.Registration requests consist of at least the following information:Relation Name:Description:Reference:The Expert(s) MAY define additional fields to be collected in the registry.General requirements for registered relation types are described in .See the registry for examples of the description field; generally, it SHOULD identify the semantics
in terms of the link’s context and target.Registrations MUST reference a freely available, stable specification.Note that relation types can be registered by third parties, if the Expert(s) determine that an
unregistered relation type is widely deployed and not likely to be registered in a timely manner.Decisions (or lack thereof) made by the Expert(s) can be first appealed to Application Area
Directors (contactable using app-ads@tools.ietf.org 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 iesg@iesg.org mailing list).Applications that don’t wish to register a relation type can use an extension relation type, which
is a URI that uniquely identifies the relation type. Although the URI can point to a
resource that contains a definition of the semantics of the relation type, clients SHOULD NOT
automatically access that resource to avoid overburdening its server.The URI used for an extension relation type SHOULD be under the control of the person or party
defining it, or be delegated to them. These URIs also SHOULD NOT use the base URI defined by an
application for registered relation types (as per ).When extension relation types are compared, they MUST be compared as strings (after converting to
URIs if serialised in a different format, such as a XML QNames ) in a
case-insensitive fashion, character-by-character. Because of this, all-lowercase URIs SHOULD be
used for extension relations.Note that while extension relation types are required to be URIs, a serialisation of links can
specify that they are expressed in another form, as long as they can be converted to URIs.The Link header field provides a means for serialising one or more links into HTTP headers.Each link-value conveys one target IRI as a URI-Reference (after conversion to one, if necessary;
see , Section 3.1) inside angle brackets (“<>”). If the URI-Reference is relative,
parsers MUST resolve it as per , Section 5. Note that any base IRI from the message’s
content is not applied.By default, the context of a link conveyed in the Link header field is identity of the
representation it is associated with, as defined in , Section 3.1.4.1, serialised as a
URI.When present, the anchor parameter overrides this with another URI, such as a fragment of this
resource, or a third resource (i.e., when the anchor value is an absolute URI). If the anchor
parameter’s value is a relative URI, parsers MUST resolve it as per , Section 5. Note
that any base URI from the body’s content is not applied.Consuming implementations can choose to ignore links with an anchor parameter. For example, the
application in use might not allow the link context to be assigned to a different resource. In such
cases, the entire link is to be ignored; consuming implementations MUST NOT process the link
without applying the anchor.Note that depending on HTTP status code and response headers, the link context might be “anonymous”
(i.e., no link context is available). For instance, this is the case on a 404 response to a GET
request.The relation type of a link is conveyed in the “rel” parameter’s value. The “rel” parameter MUST
NOT appear more than once in a given link-value; occurrences after the first MUST be ignored by
parsers.The “rev” parameter has been used in the past to indicate that the semantics of the relationship
are in the reverse direction. That is, a link from A to B with REL=”X” expresses the same
relationship as a link from B to A with REV=”X”. “rev” is deprecated by this specification because
it often confuses authors and readers; in most cases, using a separate relation type is preferable.Note that extension relation types are REQUIRED to be absolute URIs in Link headers, and MUST be
quoted if they contain a semicolon (“;”) or comma (“,”) (as these characters are used as delimiters
in the header field itself).The “hreflang”, “media”, “title”, “title*”, “type”, and any link-extension link-params are
considered to be target attributes for the link.The “hreflang” parameter, when present, is a hint indicating what the language of the result of
dereferencing the link should be. Note that this is only a hint; for example, it does not override
the Content-Language header field of a HTTP response obtained by actually following the link.
Multiple “hreflang” parameters on a single link-value indicate that multiple languages are
available from the indicated resource.The “media” parameter, when present, is used to indicate intended destination medium or media for
style information (see , Section 4.2.4). Its value MUST be quoted if it
contains a semicolon (“;”) or comma (“,”), and there MUST NOT be more than one “media” parameter in
a link-value.The “title” parameter, when present, is used to label the destination of a link such that it can be
used as a human-readable identifier (e.g., a menu entry) in the language indicated by the
Content-Language header field (if present). The “title” parameter MUST NOT appear more than once in
a given link-value; occurrences after the first MUST be ignored by parsers.The “title*” parameter can be used to encode this label in a different character set, and/or
contain language information as per . The “title*” parameter MUST
NOT appear more than once in a given link-value; occurrences after the first MUST be ignored by
parsers. If the parameter does not contain language information, its language is indicated by the
Content-Language header field (when present).If both the “title” and “title*” parameters appear in a link-value, processors SHOULD use the
“title*” parameter’s value.The “type” parameter, when present, is a hint indicating what the media type of the result of
dereferencing the link should be. Note that this is only a hint; for example, it does not override
the Content-Type header field of a HTTP response obtained by actually following the link. The
“type” parameter MUST NOT appear more than once in a given link-value; occurrences after the first
MUST be ignored by parsers.For example:indicates that “chapter2” is previous to this resource in a logical navigation path.Similarly,indicates that the root resource (“/”) is related to this resource with the extension relation type
“http://example.net/foo”.The example below shows an instance of the Link header field encoding multiple links, and also the
use of RFC 5987 encoding to encode both non-ASCII characters and language information.Here, both links have titles encoded in UTF-8, use the German language (“de”), and the second link
contains the Unicode code point U+00E4 (“LATIN SMALL LETTER A WITH DIAERESIS”).Note that link-values can convey multiple links between the same link target and link context; for
example:Here, the link to “http://example.org/” has the registered relation type “start” and the extension
relation type “http://example.net/relation/other”.In addition to the actions below, IANA should terminate the Link Relation Application Data
Registry, as it has not been used, and future use is not anticipated.This specification updates the Message Header registry entry for “Link” in HTTP to
refer to this document.This specification updates the registration procedures for the Link Relation Type registry; see
. The Expert(s) and IANA will interact as outlined below.IANA will direct any incoming requests regarding the registry to the processes established by the
Expert(s); typically, this will mean referring them to the registry HTML page.The Expert(s) will provide registry data to IANA in an agreed form (e.g. a specific XML format).
IANA will publish:
* The raw registry data
* The registry data, transformed into HTML
* The registry data in any alternative formats provided by the Expert(s)Each published document will be at a URL agreed to by IANA and the Expert(s), and IANA will
set HTTP response headers on them as (reasonably) requested by the Expert(s).Additionally, the HTML generated by IANA will:
* Take directions from the Expert(s) as to the content of the HTML page’s introductory text and markup
* Include a stable HTML fragment identifier for each registered link relationAll registry data documents MUST include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions ().The content of the Link header field is not secure, private or integrity-guaranteed, and due
caution should be exercised when using it. Use of Transport Layer Security (TLS) with HTTP
( and ) is currently the only end-to-end way to provide such protection.Link applications ought to consider the attack vectors opened by automatically following, trusting,
or otherwise using links gathered from HTTP headers. In particular, Link header fields that use the
“anchor” parameter to associate a link’s context with another resource should be treated with due
caution.The Link header field makes extensive use of IRIs and URIs. See for security
considerations relating to IRIs. See for security considerations relating to URIs. See
for security considerations relating to HTTP headers.Link targets may need to be converted to URIs in order to express them in serialisations that do
not support IRIs. This includes the Link HTTP header field.Similarly, the anchor parameter of the Link header field does not support IRIs, and therefore IRIs
must be converted to URIs before inclusion there.Relation types are defined as URIs, not IRIs, to aid in their comparison. It is not expected that
they will be displayed to end users.Note that registered Relation Names are required to be lower-case ASCII letters.The Internet Standards Process -- Revision 3This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Registration Procedures for Message Header FieldsThis specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Uniform Resource Identifier (URI): Generic SyntaxA Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]Internationalized Resource Identifiers (IRIs)This document defines a new protocol element, the Internationalized Resource Identifier (IRI), as a complement of the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). A mapping from IRIs to URIs is defined, which means that IRIs can be used instead of URIs, where appropriate, to identify resources. The approach of defining a new protocol element was chosen instead of extending or changing the definition of URIs. This was done in order to allow a clear distinction and to avoid incompatibilities with existing software. Guidelines are provided for the use and deployment of IRIs in various protocols, formats, and software components that currently deal with URIs.Media Type Specifications and Registration ProceduresThis document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice.Guidelines for Writing an IANA Considerations Section in RFCsMany protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Tags for Identifying LanguagesThis document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and RoutingThe Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.Hypertext Transfer Protocol (HTTP/1.1): Semantics and ContentThe Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.Media QueriesIndicating Character Encoding and Language for HTTP Header Field ParametersBy default, message header field parameters in Hypertext Transfer Protocol (HTTP) messages cannot carry characters outside the ISO- 8859-1 character set. RFC 2231 defines an encoding mechanism for use in Multipurpose Internet Mail Extensions (MIME) headers. This document specifies an encoding suitable for use in HTTP header fields that is compatible with a profile of the encoding defined in RFC 2231.Hypertext Transfer Protocol -- HTTP/1.1The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. [STANDARDS-TRACK]Hypertext Transfer Protocol -- HTTP/1.1HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068. [STANDARDS-TRACK]Upgrading to TLS Within HTTP/1.1This memo explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection. [STANDARDS-TRACK]HTTP Over TLSThis memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet. This memo provides information for the Internet community.The Atom Syndication FormatThis document specifies Atom, an XML-based Web content and metadata syndication format. [STANDARDS-TRACK]Namespaces in XML 1.0 (Third Edition)HTML5HTML+RDFa 1.1 - Second EditionHTML motivated the original syntax of the Link header field, and many of
the design decisions in this document are driven by a desire to stay compatible with it.In HTML, the link element can be mapped to links as specified here by using the “href” attribute
for the target URI, and “rel” to convey the relation type, as in the Link header field. The context
of the link is the URI associated with the entire HTML document.All of the link relation types defined by HTML have been included in the Link Relation Type
registry, so they can be used without modification. However, there are several potential ways to
serialise extension relation types into HTML, including:As absolute URIs,using the RDFa convention of mapping token
prefixes to URIs (in a manner similar to XML name spaces).Individual applications of linking will therefore need to define how their extension links should
be serialised into HTML.Surveys of existing HTML content have shown that unregistered link relation types that are not URIs
are (perhaps inevitably) common. Consuming HTML implementations ought not consider such
unregistered short links to be errors, but rather relation types with a local scope (i.e., their
meaning is specific and perhaps private to that document).HTML also defines several attributes on links that can be see as target attributes, including
“media”, “hreflang”, “type” and “sizes”.Finally, the HTML specification gives a special meaning when the “alternate” and “stylesheet”
relation types coincide in the same link. Such links ought to be serialised in the Link header field
using a single list of relation-types (e.g., rel=”alternate stylesheet”) to preserve this
relationship.Atom is a link serialisation that conveys links in the atom:link element, with the
“href” attribute indicating the link target and the “rel” attribute containing the relation type.
The context of the link is either a feed locator or an entry ID, depending on where it appears;
generally, feed-level links are obvious candidates for transmission as a Link header field.When serialising an atom:link into a Link header field, it is necessary to convert link targets (if
used) to URIs.Atom defines extension relation types in terms of IRIs. This specification re-defines them as URIs,
to simplify and reduce errors in their comparison.Atom allows registered link relation types to be serialised as absolute URIs using a prefix,
“http://www.iana.org/assignments/relation/”. This prefix is specific to the Atom serialisation.Furthermore, link relation types are always compared in a case-sensitive fashion; therefore,
registered link relation types SHOULD be converted to their registered form (usually, lowercase)
when serialised in an Atom document.Note also that while the Link header field allows multiple relations to be serialised in a single
link, atom:link does not. In this case, a single link-value may map to several atom:link elements.As with HTML, atom:link defines some attributes that are not explicitly mirrored in the Link header
field syntax, but they can also be used as link-extensions to maintain fidelity.This specification has the following differences from its predecessor, RFC5988:The initial relation type registrations were removed, since they’ve already been registered by
5988.The introduction has been shortened.The Link Relation Application Data Registry has been removed.Incorporated errata.Updated references.Link cardinality was clarified.Terminology was changed from “target IRI” and “context IRI” to “link target” and “link context”
respectively.Made assigning a URI to registered relation types application-specific.Removed misleading statement that the link header field is semantically equivalent to HTML and
Atom links.More carefully defined how the Experts and IANA should interact.More carefully defined and used “link serialisations” and “link applications.”Clarified the cardinality of target attributes (generically and for “type”).Corrected the default link context for the Link header field, to be dependent upon the identity of the representation (as per RFC7231).