| 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.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/