One document matched: draft-nottingham-rfc5988bis-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.28 -->
<!DOCTYPE rfc SYSTEM "../Tools/rfc2629xslt/rfc2629.dtd" [
]>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc rfcedstyle="yes"?>
<rfc ipr="pre5378Trust200902" docName="draft-nottingham-rfc5988bis-00" category="std" obsoletes="5988">
<front>
<title>Web Linking</title>
<author initials="M." surname="Nottingham" fullname="Mark Nottingham">
<organization></organization>
<address>
<email>mnot@mnot.net</email>
<uri>http://www.mnot.net/</uri>
</address>
</author>
<date year="2015"/>
<area>General</area>
<keyword>link relation</keyword>
<abstract>
<t>This specification defines a way to indicate the relationships between resources on the Web
(“links”) and the type of those relationships (“link relation types”).</t>
<t>It also defines the use of such links in HTTP headers with the Link header field.</t>
</abstract>
<note title="Note to Readers">
<t>This is a work-in-progress to revise RFC5988.</t>
<t>The issues list can be found at <eref target="https://github.com/mnot/I-D/labels/rfc5988bis">https://github.com/mnot/I-D/labels/rfc5988bis</eref>.</t>
<t>The most recent (often, unpublished) draft is at <eref target="https://mnot.github.io/I-D/rfc5988bis/">https://mnot.github.io/I-D/rfc5988bis/</eref>.</t>
<t>Recent changes are listed at <eref target="https://github.com/mnot/I-D/commits/gh-pages/rfc5988bis">https://github.com/mnot/I-D/commits/gh-pages/rfc5988bis</eref>.</t>
</note>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>This specification defines a way to indicate the relationships between resources on the Web
(“links”) and the type of those relationships (“link relation types”).</t>
<t>HTML <xref target="W3C.REC-html5-20141028"/> and Atom <xref target="RFC4287"/> both have well-defined concepts of linking;
this specification generalises this into a framework that encompasses linking in these formats and
(potentially) elsewhere.</t>
<t>Furthermore, this specification formalises an HTTP header field for conveying such links, having
been originally defined in Section 19.6.2.4 of <xref target="RFC2068"/>, but removed from <xref target="RFC2616"/>.</t>
</section>
<section anchor="notational-conventions" title="Notational Conventions">
<t>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,
<xref target="RFC2119"/>, as scoped to those conformance targets.</t>
<t>This document uses the Augmented Backus-Naur Form (ABNF) notation of <xref target="RFC7230"/>, including the
#rule, and explicitly includes the following rules from it: quoted-string, token, SP (space),
LOALPHA, DIGIT.</t>
<t>Additionally, the following rules are included from <xref target="RFC3986"/>: URI and URI-Reference; from
<xref target="RFC6838"/>: type-name and subtype-name; from <xref target="W3C.CR-css3-mediaqueries-20090915"/>:
media_query_list; from <xref target="RFC5646"/>: Language-Tag; and from <xref target="I-D.ietf-httpbis-rfc5987bis"/>,
ext-value and parmname.</t>
</section>
<section anchor="links" title="Links">
<t>In this specification, a link is a typed connection between two resources, and is comprised of:</t>
<t><list style="symbols">
<t>A link context,</t>
<t>a link relation type (<xref target="link-relation-types"/>),</t>
<t>a link target, and</t>
<t>optionally, target attributes.</t>
</list></t>
<t>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}”.</t>
<t>Link contexts and link targets are both IRIs <xref target="RFC3987"/>. However, in the common case, the link
context will also be a URI <xref target="RFC3986"/>, because many protocols (such as HTTP) do not support
dereferencing IRIs. Likewise, the link target will be sometimes be converted to a URI (see
<xref target="RFC3987"/>, Section 3.1) in places that do not support IRIs (such as the Link header field defined
in <xref target="header"/>).</t>
<t>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 and in-content links) is not
specified or significant in this specification; applications that wish to consider ordering
significant can do so.</t>
<t>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 or use, but does
provide common target attributes for use in the Link HTTP header.</t>
<t>Finally, this specification does not define a general syntax for expressing 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 <xref target="header"/>.</t>
</section>
<section anchor="link-relation-types" title="Link Relation Types">
<t>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.</t>
<t>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).</t>
<t>Relation types are not to be confused with media types <xref target="RFC6838"/>; 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.</t>
<t>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.</t>
<t>There are two kinds of relation types: registered and extension.</t>
<section anchor="registered-relation-types" title="Registered Relation Types">
<t>Well-defined relation types can be registered as tokens for convenience and/or to promote reuse by
other applications, using the procedure in <xref target="procedure"/>.</t>
<t>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.</t>
<t>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).</t>
<t>Applications that wish to refer to a registered relation type with a URI <xref target="RFC3986"/> MAY do so by
prepending “http://www.iana.org/assignments/relation/” to its name. Note that the resulting strings
are not considered equivalent to the registered relation types by many processors, and SHOULD NOT
be serialised unless the application using link relations specifically allows them.</t>
<section anchor="procedure" title="Registering Link Relation Types">
<t>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 <xref target="RFC5226"/>).</t>
<t>The Expert(s) will establish procedures for requesting registrations, and make them available from
the registry page.</t>
<t>Registration requests consist of at least the following information:</t>
<t><list style="symbols">
<t>Relation Name:</t>
<t>Description:</t>
<t>Reference:</t>
</list></t>
<t>The Expert(s) MAY define additional fields to be collected in the registry.</t>
<t>General requirements for registered relation types are described in <xref target="registered-relation-types"/>.</t>
<t>See the registry for examples of the description field; generally, it SHOULD identify the semantics
in terms of the link’s context and target.</t>
<t>Registrations MUST reference a freely available, stable specification.</t>
<t>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.</t>
<t>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).</t>
</section>
</section>
<section anchor="extension-relation-types" title="Extension Relation Types">
<t>Applications that don’t wish to register a relation type can use an extension relation type, which
is a URI <xref target="RFC3986"/> 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.</t>
<t>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 <xref target="W3C.REC-xml-names-20091208"/>) in a
case-insensitive fashion, character-by-character. Because of this, all-lowercase URIs SHOULD be
used for extension relations.</t>
<t>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.</t>
</section>
</section>
<section anchor="header" title="The Link Header Field">
<t>The Link entity-header field provides a means for serialising one or more links in HTTP headers.</t>
<figure><artwork><![CDATA[
Link = "Link" ":" #link-value
link-value = "<" URI-Reference ">" *( ";" link-param )
link-param = ( ( "rel" "=" relation-types )
| ( "anchor" "=" <"> URI-Reference <"> )
| ( "rev" "=" relation-types )
| ( "hreflang" "=" Language-Tag )
| ( "media" "="
( media_query_list | ( <"> media_query_list <"> ) )
)
| ( "title" "=" quoted-string )
| ( "title*" "=" ext-value )
| ( "type" "=" ( media-type | quoted-mt ) )
| ( link-extension ) )
link-extension = ( parmname [ "=" ( ptoken | quoted-string ) ] )
| ( ext-name-star "=" ext-value )
ext-name-star = parmname "*" ; reserved for RFC5987-profiled
; extensions. Whitespace NOT
; allowed in between.
ptoken = 1*ptokenchar
ptokenchar = "!" | "#" | "$" | "%" | "&" | "'" | "("
| ")" | "*" | "+" | "-" | "." | "/" | DIGIT
| ":" | "<" | "=" | ">" | "?" | "@" | ALPHA
| "[" | "]" | "^" | "_" | "`" | "{" | "|"
| "}" | "~"
media-type = type-name "/" subtype-name
quoted-mt = <"> media-type <">
relation-types = relation-type
| <"> relation-type *( 1*SP relation-type ) <">
relation-type = reg-rel-type | ext-rel-type
reg-rel-type = LOALPHA *( LOALPHA | DIGIT | "." | "-" )
ext-rel-type = URI
]]></artwork></figure>
<section anchor="link-target" title="Link Target">
<t>Each link-value conveys one target IRI as a URI-Reference (after conversion to one, if necessary;
see <xref target="RFC3987"/>, Section 3.1) inside angle brackets (“<>”). If the URI-Reference is relative,
parsers MUST resolve it as per <xref target="RFC3986"/>, Section 5. Note that any base IRI from the message’s
content is not applied.</t>
</section>
<section anchor="link-context" title="Link Context">
<t>By default, the context of a link conveyed in the Link header field is the IRI of the requested
resource.</t>
<t>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 <xref target="RFC3986"/>, Section 5. Note
that any base URI from the body’s content is not applied.</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="relation-type" title="Relation Type">
<t>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.</t>
<t>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.</t>
<t>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 itself).</t>
</section>
<section anchor="target-attributes" title="Target Attributes">
<t>The “hreflang”, “media”, “title”, “title*”, “type”, and any link-extension link-params are
considered to be target attributes for the link.</t>
<t>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 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.</t>
<t>The “media” parameter, when present, is used to indicate intended destination medium or media for
style information (see <xref target="W3C.REC-html5-20141028"/>, 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.</t>
<t>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 (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.</t>
<t>The “title*” parameter can be used to encode this label in a different character set, and/or
contain language information as per <xref target="I-D.ietf-httpbis-rfc5987bis"/>. 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 (when present).</t>
<t>If both the “title” and “title*” parameters appear in a link-value, processors SHOULD use the
“title*” parameter’s value.</t>
<t>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 of a HTTP response obtained by actually following the link. There MUST NOT
be more than one type parameter in a link-value.</t>
</section>
<section anchor="examples" title="Examples">
<t>For example:</t>
<figure><artwork><![CDATA[
Link: <http://example.com/TheBook/chapter2>; rel="previous";
title="previous chapter"
]]></artwork></figure>
<t>indicates that “chapter2” is previous to this resource in a logical navigation path.</t>
<t>Similarly,</t>
<figure><artwork><![CDATA[
Link: </>; rel="http://example.net/foo"
]]></artwork></figure>
<t>indicates that the root resource (“/”) is related to this resource with the extension relation type
“http://example.net/foo”.</t>
<t>The example below shows an instance of the Link header encoding multiple links, and also the use of
RFC 5987 encoding to encode both non-ASCII characters and language information.</t>
<figure><artwork><![CDATA[
Link: </TheBook/chapter2>;
rel="previous"; title*=UTF-8'de'letztes%20Kapitel,
</TheBook/chapter4>;
rel="next"; title*=UTF-8'de'n%c3%a4chstes%20Kapitel
]]></artwork></figure>
<t>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”).</t>
<t>Note that link-values can convey multiple links between the same link target and link context; for
example:</t>
<figure><artwork><![CDATA[
Link: <http://example.org/>;
rel="start http://example.net/relation/other"
]]></artwork></figure>
<t>Here, the link to “http://example.org/” has the registered relation type “start” and the extension
relation type “http://example.net/relation/other”.</t>
</section>
</section>
<section anchor="iana-considerations" title="IANA Considerations">
<t>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.</t>
<section anchor="link-http-header-registration" title="Link HTTP Header Registration">
<t>This specification updates the Message Header registry entry for “Link” in HTTP <xref target="RFC3864"/> to
refer to this document.</t>
<figure><artwork><![CDATA[
Header field: Link
Applicable protocol: http
Status: standard
Author/change controller:
IETF (iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
[RFC&rfc.number;]
]]></artwork></figure>
</section>
<section anchor="link-relation-type-registry" title="Link Relation Type Registry">
<t>This specification updates the registration procedures for the Link Relation Type registry; see
<xref target="procedure"/>. The Expert(s) and IANA will interact as outlined below.</t>
<t>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.</t>
<t>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)</t>
<t>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).</t>
<t>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 relation</t>
<t>All registry data documents MUST include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions (<eref target="http://trustee.ietf.org/license-info" />).</t>
</section>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>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
(<xref target="RFC2818"/> and <xref target="RFC2817"/>) is currently the only end-to-end way to provide such protection.</t>
<t>Applications that take advantage of typed links should consider the attack vectors opened by
automatically following, trusting, or otherwise using links gathered from HTTP headers. In
particular, Link headers that use the “anchor” parameter to associate a link’s context with another
resource should be treated with due caution.</t>
<t>The Link entity-header field makes extensive use of IRIs and URIs. See <xref target="RFC3987"/> for security
considerations relating to IRIs. See <xref target="RFC3986"/> for security considerations relating to URIs. See
<xref target="RFC7230"/> for security considerations relating to HTTP headers.</t>
</section>
<section anchor="internationalisation-considerations" title="Internationalisation Considerations">
<t>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.</t>
<t>Similarly, the anchor parameter of the Link header does not support IRIs, and therefore IRIs must
be converted to URIs before inclusion there.</t>
<t>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.</t>
<t>Note that registered Relation Names are required to be lower-case ASCII letters.</t>
</section>
</middle>
<back>
<references title='Normative References'>
<reference anchor='RFC2026' target='http://www.rfc-editor.org/info/rfc2026'>
<front>
<title>The Internet Standards Process -- Revision 3</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1996' month='October' />
<abstract><t>This 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.</t></abstract>
</front>
<seriesInfo name='BCP' value='9'/>
<seriesInfo name='RFC' value='2026'/>
<seriesInfo name='DOI' value='10.17487/RFC2026'/>
</reference>
<reference anchor='RFC2119' target='http://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In 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.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>
<reference anchor='RFC3864' target='http://www.rfc-editor.org/info/rfc3864'>
<front>
<title>Registration Procedures for Message Header Fields</title>
<author initials='G.' surname='Klyne' fullname='G. Klyne'><organization /></author>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham'><organization /></author>
<author initials='J.' surname='Mogul' fullname='J. Mogul'><organization /></author>
<date year='2004' month='September' />
<abstract><t>This 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.</t></abstract>
</front>
<seriesInfo name='BCP' value='90'/>
<seriesInfo name='RFC' value='3864'/>
<seriesInfo name='DOI' value='10.17487/RFC3864'/>
</reference>
<reference anchor='RFC3986' target='http://www.rfc-editor.org/info/rfc3986'>
<front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials='T.' surname='Berners-Lee' fullname='T. Berners-Lee'><organization /></author>
<author initials='R.' surname='Fielding' fullname='R. Fielding'><organization /></author>
<author initials='L.' surname='Masinter' fullname='L. Masinter'><organization /></author>
<date year='2005' month='January' />
<abstract><t>A 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]</t></abstract>
</front>
<seriesInfo name='STD' value='66'/>
<seriesInfo name='RFC' value='3986'/>
<seriesInfo name='DOI' value='10.17487/RFC3986'/>
</reference>
<reference anchor='RFC3987' target='http://www.rfc-editor.org/info/rfc3987'>
<front>
<title>Internationalized Resource Identifiers (IRIs)</title>
<author initials='M.' surname='Duerst' fullname='M. Duerst'><organization /></author>
<author initials='M.' surname='Suignard' fullname='M. Suignard'><organization /></author>
<date year='2005' month='January' />
<abstract><t>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.</t><t> 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.</t></abstract>
</front>
<seriesInfo name='RFC' value='3987'/>
<seriesInfo name='DOI' value='10.17487/RFC3987'/>
</reference>
<reference anchor='RFC6838' target='http://www.rfc-editor.org/info/rfc6838'>
<front>
<title>Media Type Specifications and Registration Procedures</title>
<author initials='N.' surname='Freed' fullname='N. Freed'><organization /></author>
<author initials='J.' surname='Klensin' fullname='J. Klensin'><organization /></author>
<author initials='T.' surname='Hansen' fullname='T. Hansen'><organization /></author>
<date year='2013' month='January' />
<abstract><t>This 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.</t></abstract>
</front>
<seriesInfo name='BCP' value='13'/>
<seriesInfo name='RFC' value='6838'/>
<seriesInfo name='DOI' value='10.17487/RFC6838'/>
</reference>
<reference anchor='RFC5226' target='http://www.rfc-editor.org/info/rfc5226'>
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author initials='T.' surname='Narten' fullname='T. Narten'><organization /></author>
<author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'><organization /></author>
<date year='2008' month='May' />
<abstract><t>Many 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).</t><t>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.</t><t>This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='26'/>
<seriesInfo name='RFC' value='5226'/>
<seriesInfo name='DOI' value='10.17487/RFC5226'/>
</reference>
<reference anchor='RFC5646' target='http://www.rfc-editor.org/info/rfc5646'>
<front>
<title>Tags for Identifying Languages</title>
<author initials='A.' surname='Phillips' fullname='A. Phillips' role='editor'><organization /></author>
<author initials='M.' surname='Davis' fullname='M. Davis' role='editor'><organization /></author>
<date year='2009' month='September' />
<abstract><t>This 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.</t></abstract>
</front>
<seriesInfo name='BCP' value='47'/>
<seriesInfo name='RFC' value='5646'/>
<seriesInfo name='DOI' value='10.17487/RFC5646'/>
</reference>
<reference anchor='RFC7230' target='http://www.rfc-editor.org/info/rfc7230'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The 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.</t></abstract>
</front>
<seriesInfo name='RFC' value='7230'/>
<seriesInfo name='DOI' value='10.17487/RFC7230'/>
</reference>
<reference anchor='W3C.CR-css3-mediaqueries-20090915'
target='http://www.w3.org/TR/2009/CR-css3-mediaqueries-20090915'>
<front>
<title>Media Queries</title>
<author initials='H.' surname='Lie' fullname='Håkon Wium Lie'>
<organization />
</author>
<author initials='T.' surname='Çelik' fullname='Tantek Çelik'>
<organization />
</author>
<author initials='D.' surname='Glazman' fullname='Daniel Glazman'>
<organization />
</author>
<author initials='A.' surname='Kesteren' fullname='Anne van Kesteren'>
<organization />
</author>
<date month='September' day='15' year='2009' />
</front>
<seriesInfo name='World Wide Web Consortium CR' value='CR-css3-mediaqueries-20090915' />
<format type='HTML' target='http://www.w3.org/TR/2009/CR-css3-mediaqueries-20090915' />
</reference>
<reference anchor='I-D.ietf-httpbis-rfc5987bis'>
<front>
<title>Indicating Character Encoding and Language for HTTP Header Field Parameters</title>
<author initials='J' surname='Reschke' fullname='Julian Reschke'>
<organization />
</author>
<date month='October' day='2' year='2015' />
<abstract><t>By 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.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-httpbis-rfc5987bis-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-httpbis-rfc5987bis-00.txt' />
</reference>
</references>
<references title='Informative References'>
<reference anchor='RFC2068' target='http://www.rfc-editor.org/info/rfc2068'>
<front>
<title>Hypertext Transfer Protocol -- HTTP/1.1</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding'><organization /></author>
<author initials='J.' surname='Gettys' fullname='J. Gettys'><organization /></author>
<author initials='J.' surname='Mogul' fullname='J. Mogul'><organization /></author>
<author initials='H.' surname='Frystyk' fullname='H. Frystyk'><organization /></author>
<author initials='T.' surname='Berners-Lee' fullname='T. Berners-Lee'><organization /></author>
<date year='1997' month='January' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='2068'/>
<seriesInfo name='DOI' value='10.17487/RFC2068'/>
</reference>
<reference anchor='RFC2616' target='http://www.rfc-editor.org/info/rfc2616'>
<front>
<title>Hypertext Transfer Protocol -- HTTP/1.1</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding'><organization /></author>
<author initials='J.' surname='Gettys' fullname='J. Gettys'><organization /></author>
<author initials='J.' surname='Mogul' fullname='J. Mogul'><organization /></author>
<author initials='H.' surname='Frystyk' fullname='H. Frystyk'><organization /></author>
<author initials='L.' surname='Masinter' fullname='L. Masinter'><organization /></author>
<author initials='P.' surname='Leach' fullname='P. Leach'><organization /></author>
<author initials='T.' surname='Berners-Lee' fullname='T. Berners-Lee'><organization /></author>
<date year='1999' month='June' />
<abstract><t>HTTP 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]</t></abstract>
</front>
<seriesInfo name='RFC' value='2616'/>
<seriesInfo name='DOI' value='10.17487/RFC2616'/>
</reference>
<reference anchor='RFC2817' target='http://www.rfc-editor.org/info/rfc2817'>
<front>
<title>Upgrading to TLS Within HTTP/1.1</title>
<author initials='R.' surname='Khare' fullname='R. Khare'><organization /></author>
<author initials='S.' surname='Lawrence' fullname='S. Lawrence'><organization /></author>
<date year='2000' month='May' />
<abstract><t>This 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]</t></abstract>
</front>
<seriesInfo name='RFC' value='2817'/>
<seriesInfo name='DOI' value='10.17487/RFC2817'/>
</reference>
<reference anchor='RFC2818' target='http://www.rfc-editor.org/info/rfc2818'>
<front>
<title>HTTP Over TLS</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2000' month='May' />
<abstract><t>This 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.</t></abstract>
</front>
<seriesInfo name='RFC' value='2818'/>
<seriesInfo name='DOI' value='10.17487/RFC2818'/>
</reference>
<reference anchor='RFC4287' target='http://www.rfc-editor.org/info/rfc4287'>
<front>
<title>The Atom Syndication Format</title>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham' role='editor'><organization /></author>
<author initials='R.' surname='Sayre' fullname='R. Sayre' role='editor'><organization /></author>
<date year='2005' month='December' />
<abstract><t>This document specifies Atom, an XML-based Web content and metadata syndication format. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4287'/>
<seriesInfo name='DOI' value='10.17487/RFC4287'/>
</reference>
<reference anchor='W3C.REC-xml-names-20091208'
target='http://www.w3.org/TR/2009/REC-xml-names-20091208'>
<front>
<title>Namespaces in XML 1.0 (Third Edition)</title>
<author initials='T.' surname='Bray' fullname='Tim Bray'>
<organization />
</author>
<author initials='D.' surname='Hollander' fullname='Dave Hollander'>
<organization />
</author>
<author initials='A.' surname='Layman' fullname='Andrew Layman'>
<organization />
</author>
<author initials='R.' surname='Tobin' fullname='Richard Tobin'>
<organization />
</author>
<author initials='H.' surname='Thompson' fullname='Henry Thompson'>
<organization />
</author>
<date month='December' day='8' year='2009' />
</front>
<seriesInfo name='World Wide Web Consortium Recommendation' value='REC-xml-names-20091208' />
<format type='HTML' target='http://www.w3.org/TR/2009/REC-xml-names-20091208' />
</reference>
<reference anchor='W3C.REC-html5-20141028'
target='http://www.w3.org/TR/2014/REC-html5-20141028'>
<front>
<title>HTML5</title>
<author initials='I.' surname='Hickson' fullname='Ian Hickson'>
<organization />
</author>
<author initials='R.' surname='Berjon' fullname='Robin Berjon'>
<organization />
</author>
<author initials='S.' surname='Faulkner' fullname='Steve Faulkner'>
<organization />
</author>
<author initials='T.' surname='Leithead' fullname='Travis Leithead'>
<organization />
</author>
<author initials='E.' surname='Navara' fullname='Erika Doyle Navara'>
<organization />
</author>
<author initials='E.' surname='O'Connor' fullname='Edward O'Connor'>
<organization />
</author>
<author initials='S.' surname='Pfeiffer' fullname='Silvia Pfeiffer'>
<organization />
</author>
<date month='October' day='28' year='2014' />
</front>
<seriesInfo name='World Wide Web Consortium Recommendation' value='REC-html5-20141028' />
<format type='HTML' target='http://www.w3.org/TR/2014/REC-html5-20141028' />
</reference>
<reference anchor='W3C.REC-html-rdfa-20150317'
target='http://www.w3.org/TR/2015/REC-html-rdfa-20150317'>
<front>
<title>HTML+RDFa 1.1 - Second Edition</title>
<author initials='M.' surname='Sporny' fullname='Manu Sporny'>
<organization />
</author>
<date month='March' day='17' year='2015' />
</front>
<seriesInfo name='World Wide Web Consortium Recommendation' value='REC-html-rdfa-20150317' />
<format type='HTML' target='http://www.w3.org/TR/2015/REC-html-rdfa-20150317' />
</reference>
</references>
<section anchor="using-the-link-header-with-the-html-format" title="Using the Link Header with the HTML Format">
<t>HTML motivated the original syntax of the Link header, and many of the design decisions in this
document are driven by a desire to stay compatible with it.</t>
<t>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. The context of
the link is the URI associated with the entire HTML document.</t>
<t>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:</t>
<t><list style="symbols">
<t>As absolute URIs,</t>
<t>using the RDFa <xref target="W3C.REC-html-rdfa-20150317"/> convention of mapping token
prefixes to URIs (in a manner similar to XML name spaces).</t>
</list></t>
<t>Individual applications of linking will therefore need to define how their extension links should
be serialised into HTML.</t>
<t>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).</t>
<t>HTML also defines several attributes on links that can be see as target attributes, including
“media”, “hreflang”, “type” and “sizes”.</t>
<t>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
using a single list of relation-types (e.g., rel=”alternate stylesheet”) to preserve this
relationship.</t>
</section>
<section anchor="using-the-link-header-with-the-atom-format" title="Using the Link Header with the Atom Format">
<t>Atom 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.</t>
<t>When serialising an atom:link into a Link header, it is necessary to convert link targets (if used)
to URIs.</t>
<t>Atom defines extension relation types in terms of IRIs. This specification re-defines them as URIs,
to simplify and reduce errors in their comparison.</t>
<t>Atom allows registered link relation types to be serialised as absolute URIs. Such relation types
SHOULD be converted to the appropriate registered form (e.g.,
“http://www.iana.org/assignments/relation/self” to “self”) so that they are not mistaken for
extension relation types.</t>
<t>Furthermore, Atom 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.</t>
<t>Note also that while the Link header 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.</t>
<t>As with HTML, atom:link defines some attributes that are not explicitly mirrored in the Link header
syntax, but they can also be used as link-extensions to maintain fidelity.</t>
</section>
<section anchor="changes-from-rfc5988" title="Changes from RFC5988">
<t>This specification has the following differences from its predecessor, RFC5988:</t>
<t><list style="symbols">
<t>The initial relation type registrations were removed, since they’ve already been registered by
5988.</t>
<t>The introduction has been shortened.</t>
<t>The Link Relation Application Data Registry has been removed.</t>
<t>Incorporated errata.</t>
<t>Updated references.</t>
<t>Link cardinality was clarified.</t>
<t>Terminology was changed from “target IRI” and “context IRI” to “link target” and “link context”
respectively.</t>
<t>A convention for assigning a URI to registered relation types was defined.</t>
<t>Removed misleading statement that the link header field is semantically equivalent to HTML and
Atom links.</t>
<t>More carefully defined how the Experts and IANA should interact.</t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 15:54:04 |