draft-reschke-http-jfv-13.txt   draft-reschke-http-jfv-latest.txt 
Network Working Group J. F. Reschke Network Working Group J. F. Reschke
Internet-Draft greenbytes Internet-Draft greenbytes
Intended status: Informational February 22, 2021 Intended status: Informational April 16, 2021
Expires: August 26, 2021 Expires: October 18, 2021
A JSON Encoding for HTTP Field Values A JSON Encoding for HTTP Field Values
draft-reschke-http-jfv-13 draft-reschke-http-jfv-latest
Abstract Abstract
This document establishes a convention for use of JSON-encoded field This document establishes a convention for use of JSON-encoded field
values in HTTP fields. values in new HTTP fields.
Editorial Note Editorial Note
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
Distribution of this document is unlimited. Although this is not a Distribution of this document is unlimited. Although this is not a
work item of the HTTPbis Working Group, comments should be sent to work item of the HTTPbis Working Group, comments should be sent to
the Hypertext Transfer Protocol (HTTP) mailing list at ietf-http- the Hypertext Transfer Protocol (HTTP) mailing list at ietf-http-
wg@w3.org (mailto:ietf-http-wg@w3.org), which may be joined by wg@w3.org (mailto:ietf-http-wg@w3.org), which may be joined by
sending a message with subject "subscribe" to ietf-http-wg- sending a message with subject "subscribe" to ietf-http-wg-
request@w3.org (mailto:ietf-http-wg- request@w3.org (mailto:ietf-http-wg-
request@w3.org?subject=subscribe). request@w3.org?subject=subscribe).
Discussions of the HTTPbis Working Group are archived at Discussions of the HTTPbis Working Group are archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>. <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
XML versions and latest edits for this document are available from XML versions and latest edits for this document are available from
<http://greenbytes.de/tech/webdav/#draft-reschke-http-jfv>. <http://greenbytes.de/tech/webdav/#draft-reschke-http-jfv>.
The changes in this draft are summarized in Appendix B.16. The changes in this draft are summarized in Appendix C.17.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 August 26, 2021. This Internet-Draft will expire on October 18, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Data Model and Format . . . . . . . . . . . . . . . . . . . . 4 2. Data Model and Format . . . . . . . . . . . . . . . . . . . . 4
3. Sender Requirements . . . . . . . . . . . . . . . . . . . . . 5 3. Sender Requirements . . . . . . . . . . . . . . . . . . . . . 5
4. Recipient Requirements . . . . . . . . . . . . . . . . . . . 5 4. Recipient Requirements . . . . . . . . . . . . . . . . . . . 5
5. Using this Format in Field Definitions . . . . . . . . . . . 5 5. Using this Format in Field Definitions . . . . . . . . . . . 5
6. Deployment Considerations . . . . . . . . . . . . . . . . . . 6 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 6
7. Interoperability Considerations . . . . . . . . . . . . . . . 6 7. Interoperability Considerations . . . . . . . . . . . . . . . 6
7.1. Encoding and Characters . . . . . . . . . . . . . . . . . 6 7.1. Encoding and Characters . . . . . . . . . . . . . . . . . 6
7.2. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.2. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.3. Object Constraints . . . . . . . . . . . . . . . . . . . 7 7.3. Object Constraints . . . . . . . . . . . . . . . . . . . 7
8. Internationalization Considerations . . . . . . . . . . . . . 7 8. Internationalization Considerations . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 8
10.3. Specifications Using This Syntax (at some point of 10.3. Specifications Using This Syntax (at some point of
time) . . . . . . . . . . . . . . . . . . . . . . . . . 8 time) . . . . . . . . . . . . . . . . . . . . . . . . . 9
Appendix A. Use of JSON Field Value Encoding in the Wild . . . . 9 Appendix A. Use of JSON Field Value Encoding in the Wild . . . . 9
A.1. W3C Reporting API Specification . . . . . . . . . . . . . 9 A.1. W3C Reporting API Specification . . . . . . . . . . . . . 9
A.2. W3C Clear Site Data Specification . . . . . . . . . . . . 9 A.2. W3C Clear Site Data Specification . . . . . . . . . . . . 10
A.3. W3C Feature Policy Specification . . . . . . . . . . . . 10 A.3. W3C Feature Policy Specification . . . . . . . . . . . . 10
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 10 Appendix B. Implementations . . . . . . . . . . . . . . . . . . 10
B.1. Since draft-reschke-http-jfv-00 . . . . . . . . . . . . . 10 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 10
B.2. Since draft-reschke-http-jfv-01 . . . . . . . . . . . . . 10 C.1. Since draft-reschke-http-jfv-00 . . . . . . . . . . . . . 10
B.3. Since draft-reschke-http-jfv-02 . . . . . . . . . . . . . 10 C.2. Since draft-reschke-http-jfv-01 . . . . . . . . . . . . . 10
B.4. Since draft-reschke-http-jfv-03 . . . . . . . . . . . . . 10 C.3. Since draft-reschke-http-jfv-02 . . . . . . . . . . . . . 10
B.5. Since draft-reschke-http-jfv-04 . . . . . . . . . . . . . 10 C.4. Since draft-reschke-http-jfv-03 . . . . . . . . . . . . . 10
B.6. Since draft-ietf-httpbis-jfv-00 . . . . . . . . . . . . . 10 C.5. Since draft-reschke-http-jfv-04 . . . . . . . . . . . . . 11
B.7. Since draft-ietf-httpbis-jfv-01 . . . . . . . . . . . . . 11 C.6. Since draft-ietf-httpbis-jfv-00 . . . . . . . . . . . . . 11
B.8. Since draft-ietf-httpbis-jfv-02 . . . . . . . . . . . . . 11 C.7. Since draft-ietf-httpbis-jfv-01 . . . . . . . . . . . . . 11
B.9. Since draft-reschke-http-jfv-05 . . . . . . . . . . . . . 11 C.8. Since draft-ietf-httpbis-jfv-02 . . . . . . . . . . . . . 11
B.10. Since draft-reschke-http-jfv-06 . . . . . . . . . . . . . 11 C.9. Since draft-reschke-http-jfv-05 . . . . . . . . . . . . . 11
B.11. Since draft-reschke-http-jfv-07 . . . . . . . . . . . . . 11 C.10. Since draft-reschke-http-jfv-06 . . . . . . . . . . . . . 11
B.12. Since draft-reschke-http-jfv-08 . . . . . . . . . . . . . 11 C.11. Since draft-reschke-http-jfv-07 . . . . . . . . . . . . . 11
B.13. Since draft-reschke-http-jfv-09 . . . . . . . . . . . . . 11 C.12. Since draft-reschke-http-jfv-08 . . . . . . . . . . . . . 12
B.14. Since draft-reschke-http-jfv-10 . . . . . . . . . . . . . 12 C.13. Since draft-reschke-http-jfv-09 . . . . . . . . . . . . . 12
B.15. Since draft-reschke-http-jfv-11 . . . . . . . . . . . . . 12 C.14. Since draft-reschke-http-jfv-10 . . . . . . . . . . . . . 12
B.16. Since draft-reschke-http-jfv-12 . . . . . . . . . . . . . 12 C.15. Since draft-reschke-http-jfv-11 . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 C.16. Since draft-reschke-http-jfv-12 . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 C.17. Since draft-reschke-http-jfv-13 . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Defining syntax for new HTTP fields ([HTTP], Section 5) is non- Defining syntax for new HTTP fields ([HTTP], Section 5) is non-
trivial. Among the commonly encountered problems are: trivial. Among the commonly encountered problems are:
o There is no common syntax for complex field values. Several well- o There is no common syntax for complex field values. Several well-
known fields do use a similarly looking syntax, but it is hard to known fields do use a similarly looking syntax, but it is hard to
write generic parsing code that will both correctly handle valid write generic parsing code that will both correctly handle valid
field values but also reject invalid ones. field values but also reject invalid ones.
skipping to change at page 4, line 5 skipping to change at page 4, line 8
a generic JSON-based ([RFC8259]) data model and a concrete wire a generic JSON-based ([RFC8259]) data model and a concrete wire
format that can be used in definitions of new fields, where the goals format that can be used in definitions of new fields, where the goals
were: were:
o to be compatible with field recombination when field lines occur o to be compatible with field recombination when field lines occur
multiple times in a single message (Section 5.3 of [HTTP]), and multiple times in a single message (Section 5.3 of [HTTP]), and
o not to use any problematic characters in the field value (non- o not to use any problematic characters in the field value (non-
ASCII characters and certain whitespace characters). ASCII characters and certain whitespace characters).
| *Note:* [RFC8941], a work item of the IETF HTTP Working Group, | *Note:* "Structured Field Values for HTTP" ([RFC8941]), an IETF
| is a different attempt to address this set of problems - it | RFC on the Standards Track, is a different approach to this set
| tries to identify and formalize common field structures in | of problems. It uses a more compact notation, similar to what
| existing fields; the syntax defined over there would usually | is used in existing header fields, and avoids several potential
| lead to a more compact notation. | interoperability problems inherent to the use of JSON. In
| general, that format is preferrable over the one defined here.
2. Data Model and Format 2. Data Model and Format
In HTTP, field lines with the same field name can occur multiple In HTTP, field lines with the same field name can occur multiple
times within a single message (Section 5.3 of [HTTP]). When this times within a single message (Section 5.3 of [HTTP]). When this
happens, recipients are allowed to combine the field line values happens, recipients are allowed to combine the field line values
using commas as delimiter, forming a combined "field value". This using commas as delimiter, forming a combined "field value". This
rule matches nicely JSON's array format (Section 5 of [RFC8259]). rule matches nicely JSON's array format (Section 5 of [RFC8259]).
Thus, the basic data model used here is the JSON array. Thus, the basic data model used here is the JSON array.
skipping to change at page 6, line 42 skipping to change at page 6, line 42
7. Interoperability Considerations 7. Interoperability Considerations
The "I-JSON Message Format" specification ([RFC7493]) addresses known The "I-JSON Message Format" specification ([RFC7493]) addresses known
JSON interoperability pain points. This specification borrows from JSON interoperability pain points. This specification borrows from
the requirements made over there: the requirements made over there:
7.1. Encoding and Characters 7.1. Encoding and Characters
This specification requires that field values use only US-ASCII This specification requires that field values use only US-ASCII
characters, and thus by definition use a subset of UTF-8 (Section 2.1 characters, and thus by definition uses a subset of UTF-8
of [RFC7493]). (Section 2.1 of [RFC7493]).
Furthermore, escape sequences in JSON strings (Section 7 of
[RFC8259]) - both in object member names and string values - MUST NOT
represent non-Unicode code points such as unpaired surrogates or
Noncharacters (see "General Structure" in [UNICODE]).
7.2. Numbers 7.2. Numbers
Be aware of the issues around number precision, as discussed in Be aware of the issues around number precision, as discussed in
Section 2.2 of [RFC7493]. Section 2.2 of [RFC7493].
7.3. Object Constraints 7.3. Object Constraints
As described in Section 4 of [RFC8259], JSON parser implementations As described in Section 4 of [RFC8259], JSON parser implementations
differ in the handling of duplicate object names. Therefore, senders differ in the handling of duplicate object names. Therefore, senders
skipping to change at page 8, line 7 skipping to change at page 8, line 7
smuggle information through field values; however, this concern is smuggle information through field values; however, this concern is
shared with other widely used formats, such as those using parameters shared with other widely used formats, such as those using parameters
in the form of name/value pairs. in the form of name/value pairs.
10. References 10. References
10.1. Normative References 10.1. Normative References
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", Work in Progress, Internet-Draft, Ed., "HTTP Semantics", Work in Progress, Internet-Draft,
draft-ietf-httpbis-semantics-14, January 13, 2021, draft-ietf-httpbis-semantics-15, March 30, 2021,
<https://tools.ietf.org/html/draft-ietf-httpbis-semantics- <https://tools.ietf.org/html/draft-ietf-httpbis-semantics-
14>. 15>.
[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969, RFC 20, DOI 10.17487/RFC0020, October 1969,
<https://www.rfc-editor.org/info/rfc20>. <https://www.rfc-editor.org/info/rfc20>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
DOI 10.17487/RFC7493, March 2015, DOI 10.17487/RFC7493, March 2015,
<https://www.rfc-editor.org/info/rfc7493>. <https://www.rfc-editor.org/info/rfc7493>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 8259, DOI 10.17487/RFC8259, Interchange Format", RFC 8259, DOI 10.17487/RFC8259,
December 2017, <https://www.rfc-editor.org/info/rfc8259>. December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[UNICODE] The Unicode Consortium, "The Unicode Standard",
<http://www.unicode.org/versions/latest/>.
10.2. Informative References 10.2. Informative References
[ECMA-262] Ecma International, "ECMA-262 6th Edition, The ECMAScript [ECMA-262] Ecma International, "ECMA-262 6th Edition, The ECMAScript
2015 Language Specification", Standard ECMA-262, June 2015 Language Specification", Standard ECMA-262, June
2015, <http://www.ecma-international.org/ecma-262/6.0/>. 2015, <http://www.ecma-international.org/ecma-262/6.0/>.
[ISO-8859-1] [ISO-8859-1]
International Organization for Standardization, International Organization for Standardization,
"Information technology -- 8-bit single-byte coded graphic "Information technology -- 8-bit single-byte coded graphic
character sets -- Part 1: Latin alphabet No. 1", ISO/ character sets -- Part 1: Latin alphabet No. 1", ISO/
skipping to change at page 10, line 10 skipping to change at page 10, line 18
replaces the use of JSON with a custom syntax that happens to be replaces the use of JSON with a custom syntax that happens to be
somewhat compatible with an array of JSON strings (see Section 3.1 of somewhat compatible with an array of JSON strings (see Section 3.1 of
[CLEARSITE] and <https://lists.w3.org/Archives/Public/ietf-http- [CLEARSITE] and <https://lists.w3.org/Archives/Public/ietf-http-
wg/2017AprJun/0214.html> for feedback). wg/2017AprJun/0214.html> for feedback).
A.3. W3C Feature Policy Specification A.3. W3C Feature Policy Specification
Originally defined in W3C document "Feature Policy" ([FEATUREPOL]), Originally defined in W3C document "Feature Policy" ([FEATUREPOL]),
but switched to use of Structured Header Fields ([RFC8941]). but switched to use of Structured Header Fields ([RFC8941]).
Appendix B. Change Log Appendix B. Implementations
This section is to be removed before publishing as an RFC. This section is to be removed before publishing as an RFC.
B.1. Since draft-reschke-http-jfv-00 See <https://github.com/reschke/json-fields> for a proof-of-concept
(in development).
Appendix C. Change Log
This section is to be removed before publishing as an RFC.
C.1. Since draft-reschke-http-jfv-00
Editorial fixes + working on the TODOs. Editorial fixes + working on the TODOs.
B.2. Since draft-reschke-http-jfv-01 C.2. Since draft-reschke-http-jfv-01
Mention slightly increased risk of smuggling information in header Mention slightly increased risk of smuggling information in header
field values. field values.
B.3. Since draft-reschke-http-jfv-02 C.3. Since draft-reschke-http-jfv-02
Mention Kazuho Oku's proposal for abbreviated forms. Mention Kazuho Oku's proposal for abbreviated forms.
Added a bit of text about the motivation for a concrete JSON subset Added a bit of text about the motivation for a concrete JSON subset
(ack Cory Benfield). (ack Cory Benfield).
Expand I18N section. Expand I18N section.
B.4. Since draft-reschke-http-jfv-03 C.4. Since draft-reschke-http-jfv-03
Mention relation to KEY header field. Mention relation to KEY header field.
B.5. Since draft-reschke-http-jfv-04 C.5. Since draft-reschke-http-jfv-04
Between June and December 2016, this was a work item of the HTTP Between June and December 2016, this was a work item of the HTTP
working group (see <https://datatracker.ietf.org/doc/draft-ietf- working group (see <https://datatracker.ietf.org/doc/draft-ietf-
httpbis-jfv/>). Work (if any) continues now on httpbis-jfv/>). Work (if any) continues now on
<https://datatracker.ietf.org/doc/draft-reschke-http-jfv/>. <https://datatracker.ietf.org/doc/draft-reschke-http-jfv/>.
Changes made while this was a work item of the HTTP Working Group: Changes made while this was a work item of the HTTP Working Group:
B.6. Since draft-ietf-httpbis-jfv-00 C.6. Since draft-ietf-httpbis-jfv-00
Added example for "Accept-Encoding" (inspired by Kazuho's feedback), Added example for "Accept-Encoding" (inspired by Kazuho's feedback),
showing a potential way to optimize the format when default values showing a potential way to optimize the format when default values
apply. apply.
B.7. Since draft-ietf-httpbis-jfv-01 C.7. Since draft-ietf-httpbis-jfv-01
Add interop discussion, building on I-JSON and ECMA-262 (see Add interop discussion, building on I-JSON and ECMA-262 (see
<https://github.com/httpwg/http-extensions/issues/225>). <https://github.com/httpwg/http-extensions/issues/225>).
B.8. Since draft-ietf-httpbis-jfv-02 C.8. Since draft-ietf-httpbis-jfv-02
Move non-essential parts into appendix. Move non-essential parts into appendix.
Updated XHR reference. Updated XHR reference.
B.9. Since draft-reschke-http-jfv-05 C.9. Since draft-reschke-http-jfv-05
Add meat to "Using this Format in Header Field Definitions". Add meat to "Using this Format in Header Field Definitions".
Add a few lines on the relation to "Key". Add a few lines on the relation to "Key".
Summarize current use of the format. Summarize current use of the format.
B.10. Since draft-reschke-http-jfv-06 C.10. Since draft-reschke-http-jfv-06
RFC 5987 is obsoleted by RFC 8187. RFC 5987 is obsoleted by RFC 8187.
Update CLEARSITE comment. Update CLEARSITE comment.
B.11. Since draft-reschke-http-jfv-07 C.11. Since draft-reschke-http-jfv-07
Update JSON and HSTRUCT references. Update JSON and HSTRUCT references.
FEATUREPOL doesn't use JSON syntax anymore. FEATUREPOL doesn't use JSON syntax anymore.
B.12. Since draft-reschke-http-jfv-08 C.12. Since draft-reschke-http-jfv-08
Update HSTRUCT reference. Update HSTRUCT reference.
Update notes about CLEARSITE and FEATUREPOL. Update notes about CLEARSITE and FEATUREPOL.
B.13. Since draft-reschke-http-jfv-09 C.13. Since draft-reschke-http-jfv-09
Update HSTRUCT and FEATUREPOL references. Update HSTRUCT and FEATUREPOL references.
Update note about REPORTING. Update note about REPORTING.
Changed category to "informational". Changed category to "informational".
B.14. Since draft-reschke-http-jfv-10 C.14. Since draft-reschke-http-jfv-10
Update HSTRUCT reference. Update HSTRUCT reference.
B.15. Since draft-reschke-http-jfv-11 C.15. Since draft-reschke-http-jfv-11
Update HSTRUCT reference. Update HSTRUCT reference.
Update note about FEATUREPOL (now using Structured Fields). Update note about FEATUREPOL (now using Structured Fields).
Reference [HTTP] instead if RFC723* and adjust (header) field Reference [HTTP] instead if RFC723* and adjust (header) field
terminology accordingly. terminology accordingly.
Remove discussion about the relation to KEY (as that spec is dormant: Remove discussion about the relation to KEY (as that spec is dormant:
<https://datatracker.ietf.org/doc/draft-ietf-httpbis-key/>). <https://datatracker.ietf.org/doc/draft-ietf-httpbis-key/>).
Remove appendices "Examples" and "Discussion". Remove appendices "Examples" and "Discussion".
Mark "Use of JSON Field Value Encoding in the Wild" for removal in Mark "Use of JSON Field Value Encoding in the Wild" for removal in
RFC. RFC.
B.16. Since draft-reschke-http-jfv-12 C.16. Since draft-reschke-http-jfv-12
Update HTTP reference and update terminology some more. Update HTTP reference and update terminology some more.
Update HSTRUCT reference (now RFC 8941). Update HSTRUCT reference (now RFC 8941).
C.17. Since draft-reschke-http-jfv-13
Update HTTP reference.
Mention test implementation.
Clarify that Unicode unpaired surrogates or Noncharacters must not be
sent.
Rewrite text about [RFC8941].
Acknowledgements Acknowledgements
Thanks go to the Hypertext Transfer Protocol Working Group Thanks go to the Hypertext Transfer Protocol Working Group
participants. participants.
Author's Address Author's Address
Julian F. Reschke Julian F. Reschke
greenbytes GmbH greenbytes GmbH
Hafenweg 16 Hafenweg 16
 End of changes. 32 change blocks. 
54 lines changed or deleted 83 lines changed or added

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