< draft-nottingham-rfc5988bis-05.txt   draft-nottingham-rfc5988bis-06.txt >
Network Working Group M. Nottingham Network Working Group M. Nottingham
Internet-Draft April 19, 2017 Internet-Draft June 6, 2017
Obsoletes: 5988 (if approved) Obsoletes: 5988 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: October 21, 2017 Expires: December 8, 2017
Web Linking Web Linking
draft-nottingham-rfc5988bis-05 draft-nottingham-rfc5988bis-06
Abstract Abstract
This specification defines a model for the relationships between This specification defines a model for the relationships between
resources on the Web ("links") and the type of those relationships resources on the Web ("links") and the type of those relationships
("link relation types"). ("link relation types").
It also defines the serialisation of such links in HTTP headers with It also defines the serialisation of such links in HTTP headers with
the Link header field. the Link header field.
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 21, 2017. This Internet-Draft will expire on December 8, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 36 skipping to change at page 2, line 36
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
2. Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Conformance and Error Handling . . . . . . . . . . . . . 4
2. Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Link Relation Types . . . . . . . . . . . . . . . . . . . 5 2.1. Link Relation Types . . . . . . . . . . . . . . . . . . . 5
2.1.1. Registered Relation Types . . . . . . . . . . . . . . 5 2.1.1. Registered Relation Types . . . . . . . . . . . . . . 5
2.1.2. Extension Relation Types . . . . . . . . . . . . . . 7 2.1.2. Extension Relation Types . . . . . . . . . . . . . . 7
2.2. Target Attributes . . . . . . . . . . . . . . . . . . . . 7 2.2. Target Attributes . . . . . . . . . . . . . . . . . . . . 8
3. Link Serialisation in HTTP Headers . . . . . . . . . . . . . 8 3. Link Serialisation in HTTP Headers . . . . . . . . . . . . . 8
3.1. Link Target . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Link Target . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Link Context . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Link Context . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Relation Type . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Relation Type . . . . . . . . . . . . . . . . . . . . . . 10
3.4. Target Attributes . . . . . . . . . . . . . . . . . . . . 10 3.4. Target Attributes . . . . . . . . . . . . . . . . . . . . 10
3.4.1. Serialisation-Defined Attributes . . . . . . . . . . 10 3.4.1. Serialisation-Defined Attributes . . . . . . . . . . 10
3.4.2. Extension Attributes . . . . . . . . . . . . . . . . 11 3.4.2. Extension Attributes . . . . . . . . . . . . . . . . 12
3.5. Link Header Field Examples . . . . . . . . . . . . . . . 11 3.5. Link Header Field Examples . . . . . . . . . . . . . . . 12
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
4.1. Link HTTP Header Field Registration . . . . . . . . . . . 13 4.1. Link HTTP Header Field Registration . . . . . . . . . . . 13
4.2. Link Relation Type Registry . . . . . . . . . . . . . . . 13 4.2. Link Relation Type Registry . . . . . . . . . . . . . . . 13
4.3. Link Relation Application Data Registry . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. Internationalisation Considerations . . . . . . . . . . . . . 14 6. Internationalisation Considerations . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . 15 7.1. Normative References . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . 16 7.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Notes on Other Link Serialisations . . . . . . . . . 17 Appendix A. Notes on Other Link Serialisations . . . . . . . . . 18
A.1. Link Serialisation in HTML . . . . . . . . . . . . . . . 17 A.1. Link Serialisation in HTML . . . . . . . . . . . . . . . 18
A.2. Link Serialisation in Atom . . . . . . . . . . . . . . . 17 A.2. Link Serialisation in Atom . . . . . . . . . . . . . . . 18
Appendix B. Algorithm for Parsing Link Headers . . . . . . . . . 18 Appendix B. Algorithms for Parsing Link Header Fields . . . . . 19
Appendix C. Changes from RFC5988 . . . . . . . . . . . . . . . . 21 B.1. Parsing a Header Set for Links . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 B.2. Parsing a Link Field Value . . . . . . . . . . . . . . . 20
B.3. Parsing Parameters . . . . . . . . . . . . . . . . . . . 22
B.4. Parsing a Quoted String . . . . . . . . . . . . . . . . . 23
Appendix C. Changes from RFC5988 . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
This specification defines a model for indicate the relationships This specification defines a model for the relationships between
between resources on the Web ("links") and the type of those resources on the Web ("links") and the type of those relationships
relationships ("link relation types"). ("link relation types").
HTML [W3C.REC-html5-20141028] and Atom [RFC4287] both have well- HTML [W3C.REC-html5-20141028] and Atom [RFC4287] both have well-
defined concepts of linking; Section 2 generalises this into a defined concepts of linking; Section 2 generalises this into a
framework that encompasses linking in these formats and (potentially) framework that encompasses linking in these formats and (potentially)
elsewhere. elsewhere.
Furthermore, Section 3 defines an HTTP header field for conveying Furthermore, Section 3 defines an HTTP header field for conveying
such links. such links.
1.1. Notational Conventions 1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in BCP 14, [RFC2119], as "OPTIONAL" in this document are to be interpreted as described in BCP
scoped to those conformance targets. 14 [RFC2119],[I-D.leiba-rfc2119-update] when, and only when, they
appear in all capitals, as shown here.
This document uses the Augmented Backus-Naur Form (ABNF) notation of This document uses the Augmented Backus-Naur Form (ABNF) notation of
[RFC7230], including the #rule, and explicitly includes the following [RFC7230], including the #rule, and explicitly includes the following
rules from it: quoted-string, token, SP (space), BWS (bad rules from it: quoted-string, token, SP (space), BWS (bad
whitespace), OWS (optional whitespace), RWS (required whitespace) whitespace), OWS (optional whitespace), RWS (required whitespace)
LOALPHA, DIGIT. LOALPHA, DIGIT.
Additionally, the following rules are included from [RFC3986]: URI Additionally, the following rules are included from [RFC3986]: URI
and URI-Reference; from [RFC6838]: type-name and subtype-name; from and URI-Reference; from [RFC6838]: type-name and subtype-name; from
[W3C.CR-css3-mediaqueries-20090915]: media_query_list; and from
[W3C.REC-css3-mediaqueries-20120619]: media-query-list; and from
[RFC5646]: Language-Tag. [RFC5646]: Language-Tag.
1.2. Conformance and Error Handling
The requirements regarding conformance and error handling highlighted
in [RFC7230], Section 2.5 apply to this document.
2. Links 2. Links
In this specification, a link is a typed connection between two In this specification, a link is a typed connection between two
resources, and is comprised of: resources, and is comprised of:
o A _link context_, o A _link context_,
o a _link relation type_ (Section 2.1), o a _link relation type_ (Section 2.1),
o a _link target_, and o a _link target_, and
skipping to change at page 4, line 44 skipping to change at page 5, line 10
the wire", and can occur in various forms. For example, Atom the wire", and can occur in various forms. For example, Atom
[RFC4287] and HTML [W3C.REC-html5-20141028] both defined [RFC4287] and HTML [W3C.REC-html5-20141028] both defined
serialisations of links into their respective formats, and Section 3 serialisations of links into their respective formats, and Section 3
defines how to serialise links in HTTP header fields. defines how to serialise links in HTTP header fields.
This specification does not define a general syntax for links across This specification does not define a general syntax for links across
different serialisations, nor does it mandate a specific context for different serialisations, nor does it mandate a specific context for
any given link; it is expected that serialisations of links will any given link; it is expected that serialisations of links will
specify both aspects. specify both aspects.
Finally, links are consumed by _link applications_. Generally, an Finally, links are used by _link applications_. Generally, an
application will define the link relation type(s) it uses, along with application will define the link relation type(s) it uses, along with
the serialisation(s) that they might occur within. For example, the the serialisation(s) that they might occur within. For example, the
application "Web browsing" looks for the "stylesheet" link relation application "Web browsing" looks for the "stylesheet" link relation
type in the HTML link serialisation, whereas the application type in the HTML link serialisation (and optionally in the Link
"AtomPub" uses the "edit" and "edit-media" link relations. header field), whereas the application "AtomPub" uses the "edit" and
"edit-media" link relations in the Atom serialisation.
2.1. Link Relation Types 2.1. Link Relation Types
In the simplest case, a link relation type identifies the semantics In the simplest case, a link relation type identifies the semantics
of a link. For example, a link with the relation type "copyright" of a link. For example, a link with the relation type "copyright"
indicates that the current link context has a copyright resource at indicates that the current link context has a copyright resource at
the link target. the link target.
Link relation types can also be used to indicate that the target Link relation types can also be used to indicate that the target
resource has particular attributes, or exhibits particular resource has particular attributes, or exhibits particular
behaviours; for example, a "service" link implies that the link behaviours; for example, a "service" link implies that the link
target can be used as part of a defined protocol (in this case, a target can be used as part of a defined protocol (in this case, a
service description). service description).
Relation types are not to be confused with media types [RFC6838]; Relation types are not to be confused with media types [RFC2046];
they do not identify the format of the representation that results they do not identify the format of the representation that results
when the link is dereferenced. Rather, they only describe how the when the link is dereferenced. Rather, they only describe how the
current context is related to another resource. current context is related to another resource.
Relation types SHOULD NOT infer any additional semantics based upon Relation types SHOULD NOT infer any additional semantics based upon
the presence or absence of another link relation type, or its own the presence or absence of another link relation type, or its own
cardinality of occurrence. An exception to this is the combination cardinality of occurrence. An exception to this is the combination
of the "alternate" and "stylesheet" registered relation types, which of the "alternate" and "stylesheet" registered relation types, which
has special meaning in HTML for historical reasons. has special meaning in HTML for historical reasons.
skipping to change at page 6, line 6 skipping to change at page 6, line 19
link context, and MUST NOT constrain the available representation link context, and MUST NOT constrain the available representation
media types of the link target. However, they can specify the media types of the link target. However, they can specify the
behaviours and properties of the target resource (e.g., allowable behaviours and properties of the target resource (e.g., allowable
HTTP methods, request and response media types that are required be HTTP methods, request and response media types that are required be
supported). supported).
Historically, registered relation types have been identified with a Historically, registered relation types have been identified with a
URI [RFC3986] by prefixing their names with an application-defined URI [RFC3986] by prefixing their names with an application-defined
base URI (e.g., see Appendix A.2). This practice is NOT RECOMMENDED, base URI (e.g., see Appendix A.2). This practice is NOT RECOMMENDED,
because the resulting strings will not be considered equivalent to because the resulting strings will not be considered equivalent to
the registered relation types by other processors. Applications that the registered relation types by other applications. Applications
do use such URIs internally MUST NOT use them in link serialisations that do use such URIs internally MUST NOT use them in link
that do not explicitly accommodate them. serialisations that do not explicitly accommodate them.
2.1.1.1. Registering Link Relation Types 2.1.1.1. Registering Link Relation Types
The link relations registry is located at The link relations registry is located at
https://www.iana.org/assignments/link-relations/ . Registration https://www.iana.org/assignments/link-relations/ . Registration
requests can be made by following the instructions located there, or requests can be made by following the instructions located there, or
by sending an e-mail to the "link-relations@ietf.org" mailing list. by sending an e-mail to the "link-relations@ietf.org" mailing list.
Registration requests consist of at least the following information: Registration requests consist of at least the following information:
o *Relation Name*: The name of the relation type o *Relation Name*: The name of the relation type
o *Description*: A short English description of the type's o *Description*: A short English description of the type's
semantics. It SHOULD be stated in terms of the relationship semantics. It SHOULD be stated in terms of the relationship
between the link context and link target. between the link context and link target.
o *Reference*: Reference to the document that specifies the link o *Reference*: Reference to the document that specifies the link
relation type, preferably including a URI that can be used to relation type, preferably including a URI that can be used to
retrieve a copy of the document. An indication of the relevant retrieve a copy of the document. An indication of the relevant
section(s) MAY also be included, but is not required. section(s) can also be included, but is not required.
The Expert(s) MAY define additional fields to be collected in the The Expert(s) MAY define additional fields to be collected in the
registry. registry.
General requirements for registered relation types are described in General requirements for registered relation types are described in
Section 2.1.1. Section 2.1.1.
Registrations MUST reference a freely available, stable Registrations MUST reference a freely available, stable
specification. specification.
Note that relation types can be registered by third parties Note that relation types can be registered by third parties
(including the Expert(s)), if the Expert(s) determine that an (including the Expert(s)), if the Expert(s) determine that an
unregistered relation type is widely deployed and not likely to be unregistered relation type is widely deployed and not likely to be
registered in a timely manner. registered in a timely manner otherwise.
2.1.1.2. Registration Request Processing 2.1.1.2. Registration Request Processing
Relation types are registered on the advice of a Designated Expert Relation types are registered on the advice of a Designated Expert
(appointed by the IESG or their delegate), with a Specification (appointed by the IESG or their delegate), with a Specification
Required (using terminology from [RFC5226]). Required (using terminology from Section 4.1 of [RFC5226]).
The goal of the registry is to reflect common use of links on the The goal of the registry is to reflect common use of links on the
Internet. Therefore, the Expert(s) SHOULD be strongly biased towards Internet. Therefore, the Expert(s) SHOULD be strongly biased towards
approving registrations, unless they are abusive, frivolous, not approving registrations, unless they are abusive, frivolous, not
likely to be used on the Internet, or actively harmful to the likely to be used on the Internet, or actively harmful to the
Internet and/or the Web (not merely aesthetically displeasing, or Internet and/or the Web (not merely aesthetically displeasing, or
architecturally dubious). As stated in Section 2.1.1, the Experts architecturally dubious). As stated in Section 2.1.1, the Experts
MAY withhold registration of names that are too general for the MAY withhold registration of names that are too general for the
proposed application. proposed application.
skipping to change at page 7, line 51 skipping to change at page 8, line 18
2.2. Target Attributes 2.2. Target Attributes
_Target attributes_ are a list of key/value pairs that describe the _Target attributes_ are a list of key/value pairs that describe the
link or its target; for example, a media type hint. link or its target; for example, a media type hint.
They can be defined both by individual link relation types and by They can be defined both by individual link relation types and by
link serialisations. link serialisations.
This specification does not attempt to coordinate the name of target This specification does not attempt to coordinate the name of target
attributes, their cardinality or use. Serialisations SHOULD attributes, their cardinality or use. Those creating and maintaining
coordinate their target attributes to avoid conflicts in semantics or serialisations SHOULD coordinate their target attributes to avoid
syntax. conflicts in semantics or syntax, and MAY define their own registries
of target attributes.
The names of target attributes SHOULD conform to the token rule, but The names of target attributes SHOULD conform to the token rule, but
SHOULD NOT include any of the characters "%", "'" or "*", for SHOULD NOT include any of the characters "%", "'" or "*", for
portability across serializations, and MUST be compared in a case- portability across serializations, and MUST be compared in a case-
insensitive fashion. insensitive fashion.
Target attribute definitions SHOULD specify: Target attribute definitions SHOULD specify:
o The serialisation of their values into Unicode or a subset o The serialisation of their values into Unicode or a subset
thereof, to maximise their chances of portability across link thereof, to maximise their chances of portability across link
skipping to change at page 8, line 51 skipping to change at page 9, line 18
This specification defines the link-params "rel", "anchor", "rev", This specification defines the link-params "rel", "anchor", "rev",
"hreflang", "media", "title", "title*", and "type"; see Section 3.2, "hreflang", "media", "title", "title*", and "type"; see Section 3.2,
Section 3.3 and Section 3.4. Section 3.3 and Section 3.4.
3.1. Link Target 3.1. Link Target
Each link-value conveys one target IRI as a URI-Reference (after Each link-value conveys one target IRI as a URI-Reference (after
conversion to one, if necessary; see [RFC3987], Section 3.1) inside conversion to one, if necessary; see [RFC3987], Section 3.1) inside
angle brackets ("<>"). If the URI-Reference is relative, parsers angle brackets ("<>"). If the URI-Reference is relative, parsers
MUST resolve it as per [RFC3986], Section 5. Note that any base IRI MUST resolve it as per [RFC3986], Section 5. Note that any base IRI
from the message's content is not applied. appearing in the message's content is not applied.
3.2. Link Context 3.2. Link Context
By default, the context of a link conveyed in the Link header field By default, the context of a link conveyed in the Link header field
is identity of the representation it is associated with, as defined is the URL of the representation it is associated with, as defined in
in [RFC7231], Section 3.1.4.1, serialised as a URI. [RFC7231], Section 3.1.4.1, serialised as a URI.
When present, the anchor parameter overrides this with another 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 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 the anchor value is an absolute URI). If the anchor parameter's
value is a relative URI, parsers MUST resolve it as per [RFC3986], value is a relative URI, parsers MUST resolve it as per [RFC3986],
Section 5. Note that any base URI from the body's content is not Section 5. Note that any base URI from the body's content is not
applied. applied.
The ABNF for the "anchor" parameter's value is: The ABNF for the "anchor" parameter's value is:
URI-Reference URI-Reference ; Section 4.1 of {{RFC3986}}
Consuming implementations can choose to ignore links with an anchor Link application can choose to ignore links with an anchor parameter.
parameter. For example, the application in use might not allow the For example, the application in use might not allow the link context
link context to be assigned to a different resource. In such cases, to be assigned to a different resource. In such cases, the entire
the entire link is to be ignored; consuming implementations MUST NOT link is to be ignored; link applications MUST NOT process the link
process the link without applying the anchor. without applying the anchor.
Note that depending on HTTP status code and response headers, the Note that depending on HTTP status code and response headers, the
link context might be "anonymous" (i.e., no link context is link context might be "anonymous" (i.e., no link context is
available). For example, this is the case on a 404 response to a GET available). For example, this is the case on a 404 response to a GET
request. request.
3.3. Relation Type 3.3. Relation Type
The relation type of a link conveyed in the Link header field is The relation type of a link conveyed in the Link header field is
conveyed in the "rel" parameter's value. The "rel" parameter MUST conveyed in the "rel" parameter's value. The "rel" parameter MUST
skipping to change at page 10, line 5 skipping to change at page 10, line 25
link from B to A with REV="X". "rev" is deprecated by this link from B to A with REV="X". "rev" is deprecated by this
specification because it often confuses authors and readers; in most specification because it often confuses authors and readers; in most
cases, using a separate relation type is preferable. cases, using a separate relation type is preferable.
The ABNF for the "rel" and "rev" parameters' values is: The ABNF for the "rel" and "rev" parameters' values is:
relation-type *( 1*SP relation-type ) relation-type *( 1*SP relation-type )
where: where:
relation-type = reg-rel-type | ext-rel-type relation-type = reg-rel-type / ext-rel-type
reg-rel-type = LOALPHA *( LOALPHA | DIGIT | "." | "-" ) reg-rel-type = LOALPHA *( LOALPHA / DIGIT / "." / "-" )
ext-rel-type = URI ext-rel-type = URI ; Section 3 of {{RFC3986}}
Note that extension relation types are REQUIRED to be absolute URIs Note that extension relation types are REQUIRED to be absolute URIs
in Link headers, and MUST be quoted if they contain a semicolon (";") in Link header fields, and MUST be quoted when they contain
or comma (",") (as these characters are used as delimiters in the characters not allowed in tokens, such as semicolon (";") or comma
header field itself). (",") (as these characters are used as delimiters in the header field
itself).
3.4. Target Attributes 3.4. Target Attributes
The Link header field defines several target attributes specific to The Link header field defines several target attributes specific to
this serialisation, and also allows extension target attributes. this serialisation, and also allows extension target attributes.
Target attributes are serialised in the Link header field as Target attributes are serialised in the Link header field as
parameters (see [RFC7231], Section 3.1.1.1 for the definition of parameters (see [RFC7231], Section 3.1.1.1 for the definition of
their syntax). their syntax).
3.4.1. Serialisation-Defined Attributes 3.4.1. Serialisation-Defined Attributes
skipping to change at page 10, line 49 skipping to change at page 11, line 21
The "media" attribute, when present, is used to indicate intended The "media" attribute, when present, is used to indicate intended
destination medium or media for style information (see destination medium or media for style information (see
[W3C.REC-html5-20141028], Section 4.2.4). Its value MUST be quoted [W3C.REC-html5-20141028], Section 4.2.4). Its value MUST be quoted
if it contains a semicolon (";") or comma (","). There MUST NOT be if it contains a semicolon (";") or comma (","). There MUST NOT be
more than one "media" attribute in a link-value; occurrences after more than one "media" attribute in a link-value; occurrences after
the first MUST be ignored by parsers. the first MUST be ignored by parsers.
The ABNF for the "media" parameter's value is: The ABNF for the "media" parameter's value is:
media_query_list media-query-list
The "title" attribute, when present, is used to label the destination The "title" attribute, when present, is used to label the destination
of a link such that it can be used as a human-readable identifier 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- (e.g., a menu entry) in the language indicated by the Content-
Language header field (if present). The "title" attribute MUST NOT Language header field (if present). The "title" attribute MUST NOT
appear more than once in a given link; occurrences after the first appear more than once in a given link; occurrences after the first
MUST be ignored by parsers. MUST be ignored by parsers.
The "title*" link-param can be used to encode this attribute in a The "title*" link-param can be used to encode this attribute in a
different character set, and/or contain language information as per different character set, and/or contain language information as per
[I-D.ietf-httpbis-rfc5987bis]. The "title*" link-param MUST NOT [I-D.ietf-httpbis-rfc5987bis]. The "title*" link-param MUST NOT
appear more than once in a given link-value; occurrences after the appear more than once in a given link-value; occurrences after the
first MUST be ignored by parsers. If the attribute does not contain first MUST be ignored by parsers. If the attribute does not contain
language information, its language is indicated by the Content- language information, its language is indicated by the Content-
Language header field (when present). Language header field (when present).
If both the "title" and "title*" link-param appear in a link, If both the "title" and "title*" link-param appear in a link,
processors SHOULD use the "title*" link-param's value for the "title" applications SHOULD use the "title*" link-param's value for the
attribute. "title" attribute.
The "type" attribute, when present, is a hint indicating what the The "type" attribute, when present, is a hint indicating what the
media type of the result of dereferencing the link should be. Note 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 that this is only a hint; for example, it does not override the
Content-Type header field of a HTTP response obtained by actually Content-Type header field of a HTTP response obtained by actually
following the link. The "type" attribute MUST NOT appear more than following the link. The "type" attribute MUST NOT appear more than
once in a given link-value; occurrences after the first MUST be once in a given link-value; occurrences after the first MUST be
ignored by parsers. ignored by parsers.
The ABNF for the "type" parameter's value is: The ABNF for the "type" parameter's value is:
type-name "/" subtype-name type-name "/" subtype-name ; see {{RFC6838}}, Section 4.2
3.4.2. Extension Attributes 3.4.2. Extension Attributes
Other link-params are link-extensions, and are to be considered as Other link-params are link-extensions, and are to be considered as
target attributes. target attributes.
Such target attributes MAY be defined to use the encoding in Such target attributes MAY be defined to use the encoding in
[I-D.ietf-httpbis-rfc5987bis] (e.g., "example" and "example*"). When [I-D.ietf-httpbis-rfc5987bis] (e.g., "example" and "example*"). When
both forms are present, they SHOULD be considered to be the same both forms are present, they SHOULD be considered to be the same
target attribute; processors SHOULD use the value of the name ending target attribute; applications SHOULD use the value of the name
in "*" (after [I-D.ietf-httpbis-rfc5987bis] decoding), but MAY fall ending in "*" (after [I-D.ietf-httpbis-rfc5987bis] decoding), but MAY
back to the other value if there is an error in decoding it, or if fall back to the other value if there is an error in decoding it, or
they do not support decoding. if they do not support decoding.
3.5. Link Header Field Examples 3.5. Link Header Field Examples
For example: For example:
Link: <http://example.com/TheBook/chapter2>; rel="previous"; Link: <http://example.com/TheBook/chapter2>; rel="previous";
title="previous chapter" title="previous chapter"
indicates that "chapter2" is previous to this resource in a logical indicates that "chapter2" is previous to this resource in a logical
navigation path. navigation path.
skipping to change at page 12, line 46 skipping to change at page 13, line 19
Note that link-values can convey multiple links between the same link Note that link-values can convey multiple links between the same link
target and link context; for example: target and link context; for example:
Link: <http://example.org/>; Link: <http://example.org/>;
rel="start http://example.net/relation/other" rel="start http://example.net/relation/other"
Here, the link to "http://example.org/" has the registered relation Here, the link to "http://example.org/" has the registered relation
type "start" and the extension relation type type "start" and the extension relation type
"http://example.net/relation/other". "http://example.net/relation/other".
4. IANA Considerations Finally, this header field:
In addition to the actions below, IANA should terminate the Link Link: <https://example.org/>; rel="start",
Relation Application Data Registry, as it has not been used, and <https://example.org/index>; rel="index"
future use is not anticipated.
is equivalent to these:
Link: <https://example.org/>; rel="start"
Link: <https://example.org/index>; rel="index"
4. IANA Considerations
4.1. Link HTTP Header Field Registration 4.1. Link HTTP Header Field Registration
This specification updates the Message Header registry entry for This specification updates the Message Header registry entry for
"Link" in HTTP [RFC3864] to refer to this document. "Link" in HTTP [RFC3864] to refer to this document.
Header field: Link Header field: Link
Applicable protocol: http Applicable protocol: http
Status: standard Status: standard
Author/change controller: Author/change controller:
IETF (iesg@ietf.org) IETF (iesg@ietf.org)
Internet Engineering Task Force Internet Engineering Task Force
Specification document(s): Specification document(s):
[RFC&rfc.number;] [this document]
4.2. Link Relation Type Registry 4.2. Link Relation Type Registry
This specification updates the registration procedures for the Link This specification updates the registration procedures for the Link
Relation Type registry; see Section 2.1.1.1. The Expert(s) and IANA Relation Type registry; see Section 2.1.1.1. The Expert(s) and IANA
are expected interact as outlined below. are expected interact as outlined below.
The Expert(s) will provide registry data to IANA in a mutually-agreed The Expert(s) will provide registry data to IANA in a mutually-agreed
form (e.g. a specific XML format). IANA will publish: form (e.g. a specific XML format). IANA will publish:
skipping to change at page 14, line 13 skipping to change at page 14, line 36
relation relation
All registry data documents MUST include Simplified BSD License text All registry data documents MUST include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions as described in Section 4.e of the Trust Legal Provisions
(<http://trustee.ietf.org/license-info>). (<http://trustee.ietf.org/license-info>).
IANA will direct any incoming requests regarding the registry to this IANA will direct any incoming requests regarding the registry to this
document and, if defined, the processes established by the Expert(s); document and, if defined, the processes established by the Expert(s);
typically, this will mean referring them to the registry Web page. typically, this will mean referring them to the registry Web page.
Note that the Expert(s) are allowed (as per Section 2.1.1.1) to
define additional fields to be collected in the registry.
4.3. Link Relation Application Data Registry
This specification terminates the Link Relation Application Data
Registry, as it has not been used, and future use is not anticipated.
IANA is instructed to remove it.
5. Security Considerations 5. Security Considerations
The content of the Link header field is not secure, private or The content of the Link header field is not secure, private or
integrity-guaranteed, and due caution should be exercised when using integrity-guaranteed. Use of Transport Layer Security (TLS) with
it. Use of Transport Layer Security (TLS) with HTTP ([RFC2818] and HTTP ([RFC2818]) is currently the only end-to-end way to provide
[RFC2817]) is currently the only end-to-end way to provide such these properties.
protection.
Link applications ought to consider the attack vectors opened by Link applications ought to consider the attack vectors opened by
automatically following, trusting, or otherwise using links gathered automatically following, trusting, or otherwise using links gathered
from HTTP headers. In particular, Link header fields that use the from HTTP header fields. In particular, Link header fields that use
"anchor" parameter to associate a link's context with another the "anchor" parameter to associate a link's context with another
resource are to be treated with due caution. resource are to be treated with due caution.
The Link header field makes extensive use of IRIs and URIs. See The Link header field makes extensive use of IRIs and URIs. See
[RFC3987] for security considerations relating to IRIs. See [RFC3987] Section 8 for security considerations relating to IRIs.
[RFC3986] for security considerations relating to URIs. See See [RFC3986] Section 7 for security considerations relating to URIs.
[RFC7230] for security considerations relating to HTTP headers. See [RFC7230] Section 9 for security considerations relating to HTTP
header fields.
6. Internationalisation Considerations 6. Internationalisation Considerations
Link targets may need to be converted to URIs in order to express Link targets may need to be converted to URIs in order to express
them in serialisations that do not support IRIs. This includes the them in serialisations that do not support IRIs. This includes the
Link HTTP header field. Link HTTP header field.
Similarly, the anchor parameter of the Link header field does not Similarly, the anchor parameter of the Link header field does not
support IRIs, and therefore IRIs must be converted to URIs before support IRIs, and therefore IRIs must be converted to URIs before
inclusion there. inclusion there.
skipping to change at page 15, line 14 skipping to change at page 15, line 43
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-httpbis-rfc5987bis] [I-D.ietf-httpbis-rfc5987bis]
Reschke, J., "Indicating Character Encoding and Language Reschke, J., "Indicating Character Encoding and Language
for HTTP Header Field Parameters", draft-ietf-httpbis- for HTTP Header Field Parameters", draft-ietf-httpbis-
rfc5987bis-05 (work in progress), February 2017. rfc5987bis-05 (work in progress), February 2017.
[I-D.leiba-rfc2119-update]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", draft-leiba-rfc2119-update-02 (work in
progress), March 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
DOI 10.17487/RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
DOI 10.17487/RFC3864, September 2004, DOI 10.17487/RFC3864, September 2004,
<http://www.rfc-editor.org/info/rfc3864>. <http://www.rfc-editor.org/info/rfc3864>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66, RFC
RFC 3986, DOI 10.17487/RFC3986, January 2005, 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>. <http://www.rfc-editor.org/info/rfc3986>.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987,
January 2005, <http://www.rfc-editor.org/info/rfc3987>. January 2005, <http://www.rfc-editor.org/info/rfc3987>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
September 2009, <http://www.rfc-editor.org/info/rfc5646>. September 2009, <http://www.rfc-editor.org/info/rfc5646>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13, RFC
RFC 6838, DOI 10.17487/RFC6838, January 2013, 6838, DOI 10.17487/RFC6838, January 2013,
<http://www.rfc-editor.org/info/rfc6838>. <http://www.rfc-editor.org/info/rfc6838>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing", RFC
RFC 7230, DOI 10.17487/RFC7230, June 2014, 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>. <http://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI
DOI 10.17487/RFC7231, June 2014, 10.17487/RFC7231, June 2014,
<http://www.rfc-editor.org/info/rfc7231>. <http://www.rfc-editor.org/info/rfc7231>.
[W3C.CR-css3-mediaqueries-20090915] [W3C.REC-css3-mediaqueries-20120619]
Lie, H., Celik, T., Glazman, D., and A. Kesteren, "Media Rivoal, F., "Media Queries", World Wide Web Consortium
Queries", World Wide Web Consortium CR CR-css3- Recommendation REC-css3-mediaqueries-20120619, June 2012,
mediaqueries-20090915, September 2009, <http://www.w3.org/TR/2012/
<http://www.w3.org/TR/2009/CR-css3-mediaqueries-20090915>. REC-css3-mediaqueries-20120619>.
7.2. Informative References 7.2. Informative References
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
HTTP/1.1", RFC 2817, DOI 10.17487/RFC2817, May 2000, Extensions (MIME) Part Two: Media Types", RFC 2046, DOI
<http://www.rfc-editor.org/info/rfc2817>. 10.17487/RFC2046, November 1996,
<http://www.rfc-editor.org/info/rfc2046>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/
DOI 10.17487/RFC2818, May 2000, RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>. <http://www.rfc-editor.org/info/rfc2818>.
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
Syndication Format", RFC 4287, DOI 10.17487/RFC4287, Syndication Format", RFC 4287, DOI 10.17487/RFC4287,
December 2005, <http://www.rfc-editor.org/info/rfc4287>. December 2005, <http://www.rfc-editor.org/info/rfc4287>.
[W3C.REC-html5-20141028] [W3C.REC-html5-20141028]
Hickson, I., Berjon, R., Faulkner, S., Leithead, T., Hickson, I., Berjon, R., Faulkner, S., Leithead, T.,
Navara, E., O&#039;Connor, T., and S. Pfeiffer, "HTML5", Navara, E., O&#039;Connor, T., and S. Pfeiffer, "HTML5",
World Wide Web Consortium Recommendation REC- World Wide Web Consortium Recommendation REC-
skipping to change at page 17, line 23 skipping to change at page 18, line 23
of the design decisions in this document are driven by a desire to of the design decisions in this document are driven by a desire to
stay compatible with it. stay compatible with it.
In HTML, the link element can be mapped to links as specified here by 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 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 the relation type, as in the Link header field. The context of the
link is the URI associated with the entire HTML document. HTML also link is the URI associated with the entire HTML document. HTML also
defines several attributes on links that can be seen as target defines several attributes on links that can be seen as target
attributes, including "media", "hreflang", "type" and "sizes". attributes, including "media", "hreflang", "type" and "sizes".
HTML5 ([W3C.REC-html5-20141028]) Section 4.8 defines modern HTML Section 4.8 of HTML5 ([W3C.REC-html5-20141028]) defines modern HTML
links. That document links to the Microformats Wiki as a registry; links. That document links to the Microformats Wiki as a registry;
over time, the IANA registry ought to mirror its contents, and over time, the IANA registry ought to mirror its contents, and
ideally eventually replace it (although that depends on the HTML ideally eventually replace it (although that depends on the HTML
community). community).
Surveys of existing HTML content have shown that unregistered link Surveys of existing HTML content have shown that unregistered link
relation types that are not URIs are (perhaps inevitably) common. relation types that are not URIs are (perhaps inevitably) common.
Consuming HTML implementations ought not consider such unregistered Consuming HTML implementations ought not consider such unregistered
short links to be errors, but rather relation types with a local short links to be errors, but rather relation types with a local
scope (i.e., their meaning is specific and perhaps private to that scope (i.e., their meaning is specific and perhaps private to that
skipping to change at page 18, line 26 skipping to change at page 19, line 26
serialised in an Atom document. serialised in an Atom document.
Note also that while the Link header field allows multiple relations 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, 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. a single link-value may map to several atom:link elements.
As with HTML, atom:link defines some attributes that are not As with HTML, atom:link defines some attributes that are not
explicitly mirrored in the Link header field syntax, but they can explicitly mirrored in the Link header field syntax, but they can
also be used as link-extensions to maintain fidelity. also be used as link-extensions to maintain fidelity.
Appendix B. Algorithm for Parsing Link Headers Appendix B. Algorithms for Parsing Link Header Fields
Given a HTTP header field-value "field_value" as a string assuming This appendix outlines a set of non-normative algorithms: for parsing
ASCII encoding, the following algorithm can be used to parse it into the Link header(s) out of a header set, parsing a link header field
the model described by this specification: value, and algorithms for parsing generic parts of the field value.
1. Let "links" be an empty list. These algorithms are more permissive than the ABNF defining the
syntax might suggest; the error handling embodied in them is a
reasonable approach, but not one that is required. As such they are
advisory only, and in cases where there is disagreement, the correct
behaviour is defined by the body of this specification.
2. Create "link_strings" by splitting "field_value" on "," B.1. Parsing a Header Set for Links
characters, excepting "," characters within quoted strings as per
[RFC7230], Section 3.2.6, or which form part of link's URI-
Reference (i.e. between "<" and ">" characters where the "<" is
immediately preceded by OWS and either a "," character or the
beginning of the "field_value" string).
3. For each "link_string" in "link_strings": This algorithm can be used to parse the Link header fields that a
HTTP header set contains. Given a "header_set" of (string
"field_name", string "field_value") pairs, assuming ASCII encoding,
it returns a list of link objects.
1. Let "target_string" be the string between the first "<" and 1. Let "field_values" be a list containing the members of
first ">" characters in "link_string". If they do not "header_set" whose "field_name" is a case-insensitive match for
appear, or do not appear in that order, fail parsing. "link".
2. Let "rest" be the remaining characters (if any) after the 2. Let "links" be an empty list.
first ">" character in "link_string".
3. Split "rest" into an array of strings "parameter_strings", 3. For each "field_value" in "field_values":
on the ";" character, excepting ";" characters within quoted
strings as per [RFC7230], Section 3.2.6.
4. Let "link_parameters" be an empty array. 1. Let "value_links" be the result of _Parsing A Link Field
Value_ (Appendix B.2) from "field_value".
5. For each item "parameter" in "parameter_strings": 2. Append each member of "value_links" to "links".
1. Remove OWS from the beginning and end of "parameter". 4. Return "links".
2. Skip this item if "parameter" matches the empty string B.2. Parsing a Link Field Value
("").
3. Split "parameter" into "param_name" and "param_value" on This algorithm parses zero or more comma-separated link-values from a
the first "=" character. If "parameter" does not Link header field. Given a string "field_value", assuming ASCII
contain "=", let "param_name" be "parameter" and encoding, it returns a list of link objects.
"param_value" be null.
4. Remove OWS from the end of "param_name" and the 1. Let "links" be an empty list.
beginning of "param_value".
5. Case-normalise "param_name" to lowercase. 2. While "field_value" has content:
6. If the first and last characters of "param_value" are 1. Consume any leading OWS.
both DQUOTE:
1. Remove the first and last characters of 2. If the first character is not "<", return "links".
"param_value".
2. Replace quoted-pairs within "param_value" with the 3. Discard the first character ("<").
octet following the backslash, as per [RFC7230],
Section 3.2.6.
7. If the last character of "param_name" is an asterisk 4. Consume up to but not including the first ">" character or
("*"), decode "param_value" according to end of "field_value" and let the result be "target_string".
[I-D.ietf-httpbis-rfc5987bis]. Skip this item if an
unrecoverable error is encountered.
8. Append the tuple ("param_name", "param_value") to 5. If the next character is not ">", return "links".
"link_parameters".
6. Let "target" be the result of relatively resolving (as per 6. Discard the leading ">" character.
7. Let "link_parameters", be the result of _Parsing Parameters_
(Appendix B.3) from "field_value" (consuming zero or more
characters of it).
8. Let "target" be the result of relatively resolving (as per
[RFC3986], Section 5.2) "target_string". Note that any base [RFC3986], Section 5.2) "target_string". Note that any base
URI carried in the payload body is NOT used. URI carried in the payload body is NOT used.
7. Let "relations_string" be the second item of the first tuple 9. Let "relations_string" be the second item of the first tuple
of "link_parameters" whose first item matches the string of "link_parameters" whose first item matches the string
"rel", or the empty string ("") if it is not present. "rel", or the empty string ("") if it is not present.
8. Split "relations_string" into an array of strings 10. Split "relations_string" on RWS (removing it in the process)
"relation_types", on RWS (removing all whitespace in the into a list of strings "relation_types".
process).
9. Let "context_string" be the second item of the first tuple 11. Let "context_string" be the second item of the first tuple
of "link_parameters" whose first item matches the string of "link_parameters" whose first item matches the string
"anchor". If it is not present, "context_string" is the "anchor". If it is not present, "context_string" is the URL
identity of the representation carrying the Link header of the representation carrying the Link header [RFC7231],
[RFC7231], Section 3.1.4.1, serialised as a URI. Where the Section 3.1.4.1, serialised as a URI. Where the URL is
identity is "anonymous" "context_string" is null. anonymous, "context_string" is null.
10. Let "context" be the result of relatively resolving (as per 12. Let "context" be the result of relatively resolving (as per
[RFC3986], Section 5.2) "context_string", unless [RFC3986], Section 5.2) "context_string", unless
"context_string" is null in which case "context" is null. "context_string" is null in which case "context" is null.
Note that any base URI carried in the payload body is NOT Note that any base URI carried in the payload body is NOT
used. used.
11. Let "target_attributes" be an empty array. 13. Let "target_attributes" be an empty list.
12. For each tuple ("param_name", "param_value") of 14. For each tuple ("param_name", "param_value") of
"link_parameters": "link_parameters":
1. If "param_name" matches "rel" or "anchor", skip this 1. If "param_name" matches "rel" or "anchor", skip this
tuple. tuple.
2. If "param_name" matches "media", "title", "title*" or 2. If "param_name" matches "media", "title", "title*" or
"type" and "target_attributes" already contains a tuple "type" and "target_attributes" already contains a tuple
whose first element matches the value of "param_name", whose first element matches the value of "param_name",
skip this tuple. skip this tuple.
3. Append ("param_name", "param_value") to 3. Append ("param_name", "param_value") to
"target_attributes". "target_attributes".
13. Let "star_param_names" be the set of "param_name"s in the 15. Let "star_param_names" be the set of "param_name"s in the
("param_name", "param_value") tuples of "link_parameters" ("param_name", "param_value") tuples of "link_parameters"
where the last character of "param_name" is an asterisk where the last character of "param_name" is an asterisk
("*"). ("*").
14. For each "star_param_name" in "star_param_names": 16. For each "star_param_name" in "star_param_names":
1. Let "base_param_name" be "star_param_name" with the last 1. Let "base_param_name" be "star_param_name" with the last
character removed. character removed.
2. If the implementation does not choose to support an 2. If the implementation does not choose to support an
internationalised form of a parameter named internationalised form of a parameter named
"base_param_name" for any reason (including, but not "base_param_name" for any reason (including, but not
limited to, it being prohibited by the parameter's limited to, it being prohibited by the parameter's
specification), remove all tuples from "link_parameters" specification), remove all tuples from "link_parameters"
whose first member is "star_param_name" and skip to the whose first member is "star_param_name" and skip to the
next "star_param_name". next "star_param_name".
3. Remove all tuples from "link_parameters" whose first 3. Remove all tuples from "link_parameters" whose first
member is "base_param_name". member is "base_param_name".
4. Change the first member of all tuples in 4. Change the first member of all tuples in
"link_parameters" whose first member is "link_parameters" whose first member is
"star_param_name" to "base_param_name". "star_param_name" to "base_param_name".
15. For each "relation_type" in "relation_types": 17. For each "relation_type" in "relation_types":
1. Case-normalise "relation_type" to lowercase. 1. Case-normalise "relation_type" to lowercase.
2. Append a link object to "links" with the target 2. Append a link object to "links" with the target
"target", relation type of "relation_type", context of "target", relation type of "relation_type", context of
"context", and target attributes "target_attributes". "context", and target attributes "target_attributes".
4. Return "links". 3. Return "links".
B.3. Parsing Parameters
This algorithm parses the parameters from a header field value.
Given an ASCII string "input", it returns a list of (string
"parameter_name", string "parameter_value") tuples that it contains.
"input" is modified to remove the parsed parameters.
1. Let "parameters" be an empty list.
2. While "input" has content:
1. Consume any leading OWS.
2. If the first character is not ";", return "parameters".
3. Discard the leading ";" character.
4. Consume any leading OWS.
5. Consume up to but not including the first BWS, "=", ";", ","
character or end of "input" and let the result be
"parameter_name".
6. Consume any leading BWS.
7. If the next character is "=":
1. Discard the leading "=" character.
2. Consume any leading BWS.
3. If the next character is DQUOTE, let "parameter_value"
be the result of _Parsing a Quoted String_
(Appendix B.4) from "input" (consuming zero or more
characters of it).
4. Else, consume the contents up to but not including the
first ";", "," character or end of "input" and let the
results be "parameter_value".
5. If the last character of "parameter_name" is an asterisk
("*"), decode "parameter_value" according to
[I-D.ietf-httpbis-rfc5987bis]. Continue processing
"input" if an unrecoverable error is encountered.
8. Else:
1. Let "parameter_value" be an empty string.
9. Case-normalise "parameter_name" to lowercase.
10. Append ("parameter_name", "parameter_value") to
"parameters".
11. Consume any leading OWS.
12. If the next character is "," or the end of "input", stop
processing "input" and return "parameters".
B.4. Parsing a Quoted String
This algorithm parses a quoted string, as per [RFC7230],
Section 3.2.6. Given an ASCII string "input", it returns an unquoted
string. "input" is modified to remove the parsed string.
1. Let "output" be an empty string.
2. If the first character of "input" is not DQUOTE, return "output".
3. Discard the first character.
4. While "input" has content:
1. If the first character is a backslash ("\"):
1. Discard the first character.
2. If there is no more "input", return "output".
3. Else, consume the first character and append it to
"output".
2. Else, if the first character is DQUOTE, discard it and return
"output".
3. Else, consume the first character and append it to "output".
5. Return "output".
Appendix C. Changes from RFC5988 Appendix C. Changes from RFC5988
This specification has the following differences from its This specification has the following differences from its
predecessor, RFC5988: predecessor, RFC5988:
o The initial relation type registrations were removed, since o The initial relation type registrations were removed, since
they've already been registered by 5988. they've already been registered by 5988.
o The introduction has been shortened. o The introduction has been shortened.
 End of changes. 83 change blocks. 
159 lines changed or deleted 280 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/