< draft-nottingham-rfc5988bis-06.txt   draft-nottingham-rfc5988bis-07.txt >
Network Working Group M. Nottingham Network Working Group M. Nottingham
Internet-Draft June 6, 2017 Internet-Draft July 18, 2017
Obsoletes: 5988 (if approved) Obsoletes: 5988 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: December 8, 2017 Expires: January 19, 2018
Web Linking Web Linking
draft-nottingham-rfc5988bis-06 draft-nottingham-rfc5988bis-07
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 December 8, 2017. This Internet-Draft will expire on January 19, 2018.
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 3, line 6 skipping to change at page 3, line 6
3.3. Relation Type . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . 12 3.4.2. Extension Attributes . . . . . . . . . . . . . . . . 12
3.5. Link Header Field Examples . . . . . . . . . . . . . . . 12 3.5. Link Header Field Examples . . . . . . . . . . . . . . . 12
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 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 4.3. Link Relation Application Data Registry . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. Internationalisation Considerations . . . . . . . . . . . . . 15 6. Internationalisation Considerations . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . 15 7.1. Normative References . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . 17 7.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Notes on Other Link Serialisations . . . . . . . . . 18 Appendix A. Notes on Other Link Serialisations . . . . . . . . . 17
A.1. Link Serialisation in HTML . . . . . . . . . . . . . . . 18 A.1. Link Serialisation in HTML . . . . . . . . . . . . . . . 17
A.2. Link Serialisation in Atom . . . . . . . . . . . . . . . 18 A.2. Link Serialisation in Atom . . . . . . . . . . . . . . . 17
Appendix B. Algorithms for Parsing Link Header Fields . . . . . 19 Appendix B. Algorithms for Parsing Link Header Fields . . . . . 18
B.1. Parsing a Header Set for Links . . . . . . . . . . . . . 19 B.1. Parsing a Header Set for Links . . . . . . . . . . . . . 18
B.2. Parsing a Link Field Value . . . . . . . . . . . . . . . 20 B.2. Parsing a Link Field Value . . . . . . . . . . . . . . . 19
B.3. Parsing Parameters . . . . . . . . . . . . . . . . . . . 22 B.3. Parsing Parameters . . . . . . . . . . . . . . . . . . . 21
B.4. Parsing a Quoted String . . . . . . . . . . . . . . . . . 23 B.4. Parsing a Quoted String . . . . . . . . . . . . . . . . . 22
Appendix C. Changes from RFC5988 . . . . . . . . . . . . . . . . 24 Appendix C. Changes from RFC5988 . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
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").
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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119],[I-D.leiba-rfc2119-update] when, and only when, they 14 [RFC2119],[RFC8174] when, and only when, they appear in all
appear in all capitals, as shown here. 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
skipping to change at page 6, line 43 skipping to change at page 6, line 43
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) can 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 otherwise. 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 using the Specification Required policy
(appointed by the IESG or their delegate), with a Specification (see Section 4.6 of [RFC8126]), which implies review and approval by
Required (using terminology from Section 4.1 of [RFC5226]). a designated expert.
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 expert(s)
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.
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 semantics of a proposed registration to be refused. Advice about the semantics of a proposed
link relation type can be given, but if it does not block link relation type can be given, but if it does not block
registration, this SHOULD be explicitly stated. registration, this SHOULD be explicitly stated.
When a request is approved, the Expert(s) will inform IANA, and the When a request is approved, the expert(s) will inform IANA, and the
registration will be processed. The IESG is the final arbiter of any registration will be processed. The IESG is the final arbiter of any
objection. objection.
2.1.2. Extension Relation Types 2.1.2. Extension Relation Types
Applications that don't wish to register a relation type can use an Applications that don't wish to register a relation type can use an
extension relation type, which is a URI [RFC3986] that uniquely extension relation type, which is a URI [RFC3986] that uniquely
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
skipping to change at page 8, line 49 skipping to change at page 8, line 49
3. Link Serialisation in HTTP Headers 3. 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: The ABNF for the field value is:
Link = #link-value Link = #link-value
link-value = "<" URI-Reference ">" *( OWS ";" OWS link-param ) link-value = "<" URI-Reference ">" *( OWS ";" OWS link-param )
link-param = token BWS "=" BWS ( token / quoted-string ) link-param = token BWS [ "=" BWS ( token / quoted-string ) ]
Note that any "link-param" can be generated with values using either Note that any "link-param" can be generated with values using either
the "token" or the "quoted-string" syntax, and therefore recipients the "token" or the "quoted-string" syntax, and therefore recipients
MUST be able to parse both forms. Individual "link-param"s specify MUST be able to parse both forms. In other words, the following
their syntax in terms of the value after any necessary unquoting (as parameters are equivalent:
per [RFC7230], Section 3.2.6).
x=y
x="y"
Individual "link-param"s specify their syntax in terms of the value
after any necessary unquoting (as per [RFC7230], Section 3.2.6).
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
skipping to change at page 13, line 48 skipping to change at page 13, line 48
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):
[this document] [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.
are expected interact as outlined below.
The Expert(s) will provide registry data to IANA in a mutually-agreed
form (e.g. a specific XML format). IANA will publish:
o The raw registry data
o The registry data, transformed into HTML
o The registry data alternative formats provided by the Expert(s)
(if any)
If IANA's internal processes require making changes to registry data
and/or adding registry entries, IANA will inform the Expert(s) of
this in a mutually agreed way.
Each published document will be at a URL mutually agreed to by IANA
and the Expert(s), and IANA will set HTTP response headers on them as
(reasonably) requested by the Expert(s).
Additionally, the HTML generated by IANA will:
o Take directions from the Expert(s) as to the content of the HTML
page's introductory text
o Include a stable HTML fragment identifier for each registered link
relation
All registry data documents MUST include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions
(<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 Note that the expert(s) are allowed (as per Section 2.1.1.1) to
define additional fields to be collected in the registry. define additional fields to be collected in the registry.
4.3. Link Relation Application Data Registry 4.3. Link Relation Application Data Registry
This specification terminates the Link Relation Application Data This specification removes the Link Relation Application Data
Registry, as it has not been used, and future use is not anticipated. Registry, as it has not been used, and future use is not anticipated.
IANA is instructed to remove it. 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. Use of Transport Layer Security (TLS) with integrity-guaranteed. Use of Transport Layer Security (TLS) with
HTTP ([RFC2818]) is currently the only end-to-end way to provide HTTP ([RFC2818]) is currently the only end-to-end way to provide
these properties. these properties.
skipping to change at page 15, line 43 skipping to change at page 15, line 14
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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, 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, RFC Resource Identifier (URI): Generic Syntax", STD 66, 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
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<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, 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", RFC Protocol (HTTP/1.1): Message Syntax and Routing", 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, DOI Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 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>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<http://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[W3C.REC-css3-mediaqueries-20120619] [W3C.REC-css3-mediaqueries-20120619]
Rivoal, F., "Media Queries", World Wide Web Consortium Rivoal, F., "Media Queries", World Wide Web Consortium
Recommendation REC-css3-mediaqueries-20120619, June 2012, Recommendation REC-css3-mediaqueries-20120619, June 2012,
<http://www.w3.org/TR/2012/ <http://www.w3.org/TR/2012/
REC-css3-mediaqueries-20120619>. REC-css3-mediaqueries-20120619>.
7.2. Informative References 7.2. Informative References
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, DOI Extensions (MIME) Part Two: Media Types", RFC 2046, DOI
skipping to change at page 24, line 39 skipping to change at page 23, line 39
o Terminology was changed from "target IRI" and "context IRI" to o Terminology was changed from "target IRI" and "context IRI" to
"link target" and "link context" respectively. "link target" and "link context" respectively.
o Made assigning a URI to registered relation types serialisation- o Made assigning a URI to registered relation types serialisation-
specific. specific.
o Removed misleading statement that the link header field is o Removed misleading statement that the link header field is
semantically equivalent to HTML and Atom links. semantically equivalent to HTML and Atom links.
o More carefully defined how the Experts and IANA should interact.
o More carefully defined and used "link serialisations" and "link o More carefully defined and used "link serialisations" and "link
applications." applications."
o Clarified the cardinality of target attributes (generically and o Clarified the cardinality of target attributes (generically and
for "type"). for "type").
o Corrected the default link context for the Link header field, to o Corrected the default link context for the Link header field, to
be dependent upon the identity of the representation (as per be dependent upon the identity of the representation (as per
RFC7231). RFC7231).
skipping to change at page 25, line 14 skipping to change at page 24, line 11
o The value space of target attributes and their definition has been o The value space of target attributes and their definition has been
specified. specified.
o The ABNF has been updated to be compatible with [RFC7230]. In o The ABNF has been updated to be compatible with [RFC7230]. In
particular, whitespace is now explicit. particular, whitespace is now explicit.
o Some parameters on the HTTP header field can now appear as a o Some parameters on the HTTP header field can now appear as a
token. token.
o Parameters on the HTTP header can now be value-less.
o Handling of quoted strings is now defined by [RFC7230]. o Handling of quoted strings is now defined by [RFC7230].
o The "type" header field parameter now needs to be quoted (as o The "type" header field parameter now needs to be quoted (as
"token" does not allow "/"). "token" does not allow "/").
Author's Address Author's Address
Mark Nottingham Mark Nottingham
EMail: mnot@mnot.net EMail: mnot@mnot.net
 End of changes. 25 change blocks. 
78 lines changed or deleted 51 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/