< draft-nottingham-rfc5988bis-03.txt   draft-nottingham-rfc5988bis-04.txt >
Network Working Group M. Nottingham Network Working Group M. Nottingham
Internet-Draft November 25, 2016 Internet-Draft February 3, 2017
Obsoletes: 5988 (if approved) Obsoletes: 5988 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: May 29, 2017 Expires: August 7, 2017
Web Linking Web Linking
draft-nottingham-rfc5988bis-03 draft-nottingham-rfc5988bis-04
Abstract Abstract
This specification defines a way to indicate the relationships This specification defines a way to indicate the relationships
between resources on the Web ("links") and the type of those between resources on the Web ("links") and the type of those
relationships ("link relation types"). relationships ("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 May 29, 2017. This Internet-Draft will expire on August 7, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 51 skipping to change at page 2, line 51
4.2. Extension Relation Types . . . . . . . . . . . . . . . . 7 4.2. Extension Relation Types . . . . . . . . . . . . . . . . 7
5. Target Attributes . . . . . . . . . . . . . . . . . . . . . . 8 5. Target Attributes . . . . . . . . . . . . . . . . . . . . . . 8
6. Link Serialisation in HTTP Headers . . . . . . . . . . . . . 8 6. Link Serialisation in HTTP Headers . . . . . . . . . . . . . 8
6.1. Link Target . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Link Target . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Link Context . . . . . . . . . . . . . . . . . . . . . . 9 6.2. Link Context . . . . . . . . . . . . . . . . . . . . . . 9
6.3. Relation Type . . . . . . . . . . . . . . . . . . . . . . 9 6.3. Relation Type . . . . . . . . . . . . . . . . . . . . . . 9
6.4. Target Attributes . . . . . . . . . . . . . . . . . . . . 10 6.4. Target Attributes . . . . . . . . . . . . . . . . . . . . 10
6.4.1. Serialisation-Defined Attributes . . . . . . . . . . 10 6.4.1. Serialisation-Defined Attributes . . . . . . . . . . 10
6.4.2. Extension Attributes . . . . . . . . . . . . . . . . 11 6.4.2. Extension Attributes . . . . . . . . . . . . . . . . 11
6.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 12 6.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7.1. Link HTTP Header Field Registration . . . . . . . . . . . 13 7.1. Link HTTP Header Field Registration . . . . . . . . . . . 13
7.2. Link Relation Type Registry . . . . . . . . . . . . . . . 13 7.2. Link Relation Type Registry . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Internationalisation Considerations . . . . . . . . . . . . . 14 9. Internationalisation Considerations . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Notes on Other Link Serialisations . . . . . . . . . 17 Appendix A. Notes on Other Link Serialisations . . . . . . . . . 17
A.1. Link Serialisation in HTML . . . . . . . . . . . . . . . 17 A.1. Link Serialisation in HTML . . . . . . . . . . . . . . . 17
A.2. Link Serialisation in Atom . . . . . . . . . . . . . . . 18 A.2. Link Serialisation in Atom . . . . . . . . . . . . . . . 17
Appendix B. Algorithm for Parsing Link Headers . . . . . . . . . 18 Appendix B. Algorithm for Parsing Link Headers . . . . . . . . . 18
Appendix C. Changes from RFC5988 . . . . . . . . . . . . . . . . 21 Appendix C. Changes from RFC5988 . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
This specification defines a way to indicate the relationships This specification defines a way to indicate the relationships
between resources on the Web ("links") and the type of those between resources on the Web ("links") and the type of those
relationships ("link relation types"). relationships ("link relation types").
skipping to change at page 5, line 40 skipping to change at page 5, line 40
has special meaning in HTML for historical reasons. has special meaning in HTML for historical reasons.
There are two kinds of relation types: registered and extension. There are two kinds of relation types: registered and extension.
4.1. Registered Relation Types 4.1. Registered Relation Types
Well-defined relation types can be registered as tokens for Well-defined relation types can be registered as tokens for
convenience and/or to promote reuse by other applications, using the convenience and/or to promote reuse by other applications, using the
procedure in Section 4.1.1. procedure in Section 4.1.1.
Registered relation type names MUST conform to the reg-rel-type rule, Registered relation type names MUST conform to the reg-rel-type rule
and MUST be compared character-by-character in a case-insensitive (see Section 6.3), and MUST be compared character-by-character in a
fashion. They SHOULD be appropriate to the specificity of the case-insensitive fashion. They SHOULD be appropriate to the
relation type; i.e., if the semantics are highly specific to a specificity of the relation type; i.e., if the semantics are highly
particular application, the name should reflect that, so that more specific to a particular application, the name should reflect that,
general names are available for less specific use. so that more general names are available for less specific use.
Registered relation types MUST NOT constrain the media type of the Registered relation types MUST NOT constrain the media type of the
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 must be HTTP methods, request and response media types that must 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
skipping to change at page 7, line 11 skipping to change at page 7, line 11
(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.
4.1.2. Registration Request Processing 4.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 [RFC5226]).
The goal of the registry is to reflect common use of HTTP 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). architecturally dubious).
The Expert(s) MUST clearly identify any issues which cause a The Expert(s) MUST clearly identify any issues which cause a
registration to be refused. Advice about the syntax or semantics of registration to be refused. Advice about the syntax or semantics of
a proposed link relation type can be given, but if it does not block a proposed link relation type can be given, but if it does not block
registration, this SHOULD be explicitly stated. registration, this SHOULD be explicitly stated.
skipping to change at page 7, line 41 skipping to change at page 7, line 41
identifies the relation type. Although the URI can point to a identifies the relation type. Although the URI can point to a
resource that contains a definition of the semantics of the relation resource that contains a definition of the semantics of the relation
type, clients SHOULD NOT automatically access that resource to avoid type, clients SHOULD NOT automatically access that resource to avoid
overburdening its server. overburdening its server.
The URI used for an extension relation type SHOULD be under the The URI used for an extension relation type SHOULD be under the
control of the person or party defining it, or be delegated to them. control of the person or party defining it, or be delegated to them.
When extension relation types are compared, they MUST be compared as When extension relation types are compared, they MUST be compared as
strings (after converting to URIs if serialised in a different strings (after converting to URIs if serialised in a different
format, such as a XML QNames [W3C.REC-xml-names-20091208]) in a case- format) in a case-insensitive fashion, character-by-character.
insensitive fashion, character-by-character. Because of this, all- Because of this, all-lowercase URIs SHOULD be used for extension
lowercase URIs SHOULD be used for extension relations. relations.
Note that while extension relation types are required to be URIs, a Note that while extension relation types are required to be URIs, a
serialisation of links can specify that they are expressed in another serialisation of links can specify that they are expressed in another
form, as long as they can be converted to URIs. form, as long as they can be converted to URIs.
5. Target Attributes 5. Target Attributes
_Target attributes_ are a set 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.
This specification does not attempt to coordinate the name of target They can be defined both by individual link relation types and by
attributes, their cardinality or use; they are defined both by link serialisations.
individual link relations and by link serialisations.
Serialisations SHOULD coordinate their target attributes to avoid This specification does not attempt to coordinate the name of target
conflicts in semantics or syntax. Relation types MAY define attributes, their cardinality or use. Serialisations SHOULD
additional target attributes specific to them. coordinate their target attributes to avoid conflicts in semantics or
syntax.
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 Their serialisation into Unicode or a subset thereof, to maximise o The serialisation of their values into Unicode or a subset
their chances of portability across link serialisations. thereof, to maximise their chances of portability across link
serialisations.
o The semantics and error handling of multiple occurrences of the o The semantics and error handling of multiple occurrences of the
attribute on a given link. target attribute on a given link.
This specification does define target attributes for use in the Link This specification does define target attributes for use in the Link
HTTP header field in Section 6.4. HTTP header field in Section 6.4.
6. Link Serialisation in HTTP Headers 6. Link Serialisation in HTTP Headers
The Link header field provides a means for serialising one or more The Link header field provides a means for serialising one or more
links into HTTP headers. links into HTTP headers.
The ABNF for the field value is given below: The ABNF for the field value is given below:
skipping to change at page 9, line 30 skipping to change at page 9, line 30
is identity of the representation it is associated with, as defined is identity of the representation it is associated with, as defined
in [RFC7231], Section 3.1.4.1, serialised as a URI. in [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: ~~~ abnf2616 URI- The ABNF for the "anchor" parameter's value is:
Reference ~~~
URI-Reference
Consuming implementations can choose to ignore links with an anchor Consuming implementations can choose to ignore links with an anchor
parameter. For example, the application in use might not allow the parameter. For example, the application in use might not allow the
link context to be assigned to a different resource. In such cases, link context to be assigned to a different resource. In such cases,
the entire link is to be ignored; consuming implementations MUST NOT the entire link is to be ignored; consuming implementations MUST NOT
process the link without applying the anchor. process the link 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 instance, this is the case on a 404 response to a available). For instance, this is the case on a 404 response to a
skipping to change at page 10, line 9 skipping to change at page 10, line 12
NOT appear more than once in a given link-value; occurrences after NOT appear more than once in a given link-value; occurrences after
the first MUST be ignored by parsers. the first MUST be ignored by parsers.
The "rev" parameter has been used in the past to indicate that the The "rev" parameter has been used in the past to indicate that the
semantics of the relationship are in the reverse direction. That is, 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 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 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: ~~~ abnf2616 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
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 headers, and MUST be quoted if they contain a semicolon (";")
or comma (",") (as these characters are used as delimiters in the or comma (",") (as these characters are used as delimiters in the
skipping to change at page 10, line 45 skipping to change at page 10, line 49
link. link.
The "hreflang" attribute, when present, is a hint indicating what the The "hreflang" attribute, when present, is a hint indicating what the
language of the result of dereferencing the link should be. Note language 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-Language header field of a HTTP response obtained by actually Content-Language header field of a HTTP response obtained by actually
following the link. Multiple "hreflang" attributes on a single link- following the link. Multiple "hreflang" attributes on a single link-
value indicate that multiple languages are available from the value indicate that multiple languages are available from the
indicated resource. indicated resource.
The ABNF for the "hreflang" parameter's value is: ~~~ abnf2616 The ABNF for the "hreflang" parameter's value is:
Language-Tag ~~~
Language-Tag
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: ~~~ abnf2616 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
skipping to change at page 11, line 37 skipping to change at page 11, line 43
attribute. 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: ~~~ abnf2616 type-name The ABNF for the "type" parameter's value is:
"/" subtype-name ~~~
type-name "/" subtype-name
6.4.2. Extension Attributes 6.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; processors SHOULD use the value of the name ending
skipping to change at page 13, line 48 skipping to change at page 14, line 5
Each published document will be at a URL agreed to by IANA and the 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 Expert(s), and IANA will set HTTP response headers on them as
(reasonably) requested by the Expert(s). (reasonably) requested by the Expert(s).
Additionally, the HTML generated by IANA will: Additionally, the HTML generated by IANA will:
o Take directions from the Expert(s) as to the content of the HTML o Take directions from the Expert(s) as to the content of the HTML
page's introductory text page's introductory text
o Include a stable HTML fragment identifier for each registered o Include a stable HTML fragment identifier for each registered link
header field 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>).
8. Security Considerations 8. 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, and due caution should be exercised when using
it. Use of Transport Layer Security (TLS) with HTTP ([RFC2818] and it. Use of Transport Layer Security (TLS) with HTTP ([RFC2818] and
skipping to change at page 14, line 46 skipping to change at page 15, line 4
inclusion there. inclusion there.
Relation types are defined as URIs, not IRIs, to aid in their Relation types are defined as URIs, not IRIs, to aid in their
comparison. It is not expected that they will be displayed to end comparison. It is not expected that they will be displayed to end
users. users.
Note that registered Relation Names are required to be lower-case Note that registered Relation Names are required to be lower-case
ASCII letters. ASCII letters.
10. References 10. References
10.1. Normative References 10.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-03 (work in progress), July 2016. rfc5987bis-04 (work in progress), November 2016.
[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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/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, RFC Resource Identifier (URI): Generic Syntax", STD 66,
3986, DOI 10.17487/RFC3986, January 2005, RFC 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, RFC Specifications and Registration Procedures", BCP 13,
6838, DOI 10.17487/RFC6838, January 2013, RFC 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", RFC Protocol (HTTP/1.1): Message Syntax and Routing",
7230, DOI 10.17487/RFC7230, June 2014, RFC 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, DOI Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
10.17487/RFC7231, June 2014, DOI 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.CR-css3-mediaqueries-20090915]
Lie, H., Celik, T., Glazman, D., and A. Kesteren, "Media Lie, H., Celik, T., Glazman, D., and A. Kesteren, "Media
Queries", World Wide Web Consortium CR CR-css3- Queries", World Wide Web Consortium CR CR-css3-
mediaqueries-20090915, September 2009, mediaqueries-20090915, September 2009,
<http://www.w3.org/TR/2009/CR-css3-mediaqueries-20090915>. <http://www.w3.org/TR/2009/CR-css3-mediaqueries-20090915>.
10.2. Informative References 10.2. Informative References
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2068, DOI 10.17487/RFC2068, January 1997, RFC 2068, DOI 10.17487/RFC2068, January 1997,
<http://www.rfc-editor.org/info/rfc2068>. <http://www.rfc-editor.org/info/rfc2068>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/ Transfer Protocol -- HTTP/1.1", RFC 2616,
RFC2616, June 1999, DOI 10.17487/RFC2616, June 1999,
<http://www.rfc-editor.org/info/rfc2616>. <http://www.rfc-editor.org/info/rfc2616>.
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC 2817, DOI 10.17487/RFC2817, May 2000, HTTP/1.1", RFC 2817, DOI 10.17487/RFC2817, May 2000,
<http://www.rfc-editor.org/info/rfc2817>. <http://www.rfc-editor.org/info/rfc2817>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
RFC2818, May 2000, DOI 10.17487/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-html-rdfa-20150317] [W3C.REC-html-rdfa-20150317]
Sporny, M., "HTML+RDFa 1.1 - Second Edition", World Wide Sporny, M., "HTML+RDFa 1.1 - Second Edition", World Wide
Web Consortium Recommendation REC-html-rdfa-20150317, Web Consortium Recommendation REC-html-rdfa-20150317,
March 2015, March 2015,
<http://www.w3.org/TR/2015/REC-html-rdfa-20150317>. <http://www.w3.org/TR/2015/REC-html-rdfa-20150317>.
[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-
html5-20141028, October 2014, html5-20141028, October 2014,
<http://www.w3.org/TR/2014/REC-html5-20141028>. <http://www.w3.org/TR/2014/REC-html5-20141028>.
[W3C.REC-xml-names-20091208]
Bray, T., Hollander, D., Layman, A., Tobin, R., and H.
Thompson, "Namespaces in XML 1.0 (Third Edition)", World
Wide Web Consortium Recommendation REC-xml-names-20091208,
December 2009,
<http://www.w3.org/TR/2009/REC-xml-names-20091208>.
Appendix A. Notes on Other Link Serialisations Appendix A. Notes on Other Link Serialisations
Header fields (Section 6) are only one serialisation of links; other Header fields (Section 6) are only one serialisation of links; other
specifications have defined alternative serialisations. specifications have defined alternative serialisations.
A.1. Link Serialisation in HTML A.1. Link Serialisation in HTML
HTML [W3C.REC-html5-20141028] motivated the original syntax of the HTML motivated the original syntax of the Link header field, and many
Link header field, and many of the design decisions in this document of the design decisions in this document are driven by a desire to
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. link is the URI associated with the entire HTML document. HTML also
defines several attributes on links that can be seen as target
All of the link relation types defined by HTML have been included in attributes, including "media", "hreflang", "type" and "sizes".
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:
o As absolute URIs,
o using the RDFa [W3C.REC-html-rdfa-20150317] convention of mapping
token prefixes to URIs (in a manner similar to XML name spaces).
Individual applications of linking will therefore need to define how HTML5 ([W3C.REC-html5-20141028]) Section 4.8 defines modern HTML
their extension links should be serialised into HTML. links. That document links to the Microformats Wiki as a registry;
over time, the IANA registry ought to mirror its contents, and
ideally eventually replace it (although that depends on the HTML
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
document). document).
HTML also defines several attributes on links that can be seen as
target attributes, including "media", "hreflang", "type" and "sizes".
Finally, the HTML specification gives a special meaning when the Finally, the HTML specification gives a special meaning when the
"alternate" and "stylesheet" relation types coincide in the same "alternate" relation types coincides with other relation types in the
link. Such links ought to be serialised in the Link header field same link. Such links ought to be serialised in the Link header
using a single list of relation-types (e.g., rel="alternate field using a single list of relation-types (e.g., rel="alternate
stylesheet") to preserve this relationship. stylesheet") to preserve this relationship.
A.2. Link Serialisation in Atom A.2. Link Serialisation in Atom
Atom [RFC4287] is a link serialisation that conveys links in the Atom [RFC4287] is a link serialisation that conveys links in the
atom:link element, with the "href" attribute indicating the link atom:link element, with the "href" attribute indicating the link
target and the "rel" attribute containing the relation type. The target and the "rel" attribute containing the relation type. The
context of the link is either a feed locator or an entry ID, context of the link is either a feed locator or an entry ID,
depending on where it appears; generally, feed-level links are depending on where it appears; generally, feed-level links are
obvious candidates for transmission as a Link header field. obvious candidates for transmission as a Link header field.
 End of changes. 37 change blocks. 
85 lines changed or deleted 75 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/