draft-reschke-http-jfv-11.txt   draft-reschke-http-jfv-latest.txt 
Network Working Group J. Reschke Network Working Group J. Reschke
Internet-Draft greenbytes Internet-Draft greenbytes
Intended status: Informational November 20, 2019 Intended status: Informational July 1, 2020
Expires: May 23, 2020 Expires: January 2, 2021
A JSON Encoding for HTTP Header Field Values A JSON Encoding for HTTP Header Field Values
draft-reschke-http-jfv-11 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 header fields. values in HTTP header 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.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
the Hypertext Transfer Protocol (HTTP) mailing list at ietf-http- the Hypertext Transfer Protocol (HTTP) mailing list at ietf-http-
wg@w3.org [1], which may be joined by sending a message with subject wg@w3.org [1], which may be joined by sending a message with subject
"subscribe" to ietf-http-wg-request@w3.org [2]. "subscribe" to ietf-http-wg-request@w3.org [2].
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 E.14. The changes in this draft are summarized in Appendix E.15.
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 May 23, 2020. This Internet-Draft will expire on January 2, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
described in the Simplified BSD License. described in the Simplified BSD License.
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 Header Field Definitions . . . . . . . . 5 5. Using this Format in Header Field Definitions . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 8
10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 10 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11
A.1. Content-Length . . . . . . . . . . . . . . . . . . . . . 10 A.1. Content-Length . . . . . . . . . . . . . . . . . . . . . 11
A.2. Content-Disposition . . . . . . . . . . . . . . . . . . . 10 A.2. Content-Disposition . . . . . . . . . . . . . . . . . . . 11
A.3. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 11 A.3. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 12
A.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 12 A.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 13
Appendix B. Use of JSON Field Value Encoding in the Wild . . . . 13 Appendix B. Use of JSON Field Value Encoding in the Wild . . . . 14
B.1. W3C Reporting API Specification . . . . . . . . . . . . . 14 B.1. W3C Reporting API Specification . . . . . . . . . . . . . 15
B.2. W3C Clear Site Data Specification . . . . . . . . . . . . 14 B.2. W3C Clear Site Data Specification . . . . . . . . . . . . 15
B.3. W3C Feature Policy Specification . . . . . . . . . . . . 14 B.3. W3C Feature Policy Specification . . . . . . . . . . . . 15
Appendix C. Relation to HTTP 'Key' Header Field . . . . . . . . 14 Appendix C. Relation to HTTP 'Key' Header Field . . . . . . . . 15
Appendix D. Discussion . . . . . . . . . . . . . . . . . . . . . 14 Appendix D. Discussion . . . . . . . . . . . . . . . . . . . . . 15
Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 15 Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 15
E.1. Since draft-reschke-http-jfv-00 . . . . . . . . . . . . . 15 E.1. Since draft-reschke-http-jfv-00 . . . . . . . . . . . . . 16
E.2. Since draft-reschke-http-jfv-01 . . . . . . . . . . . . . 15 E.2. Since draft-reschke-http-jfv-01 . . . . . . . . . . . . . 16
E.3. Since draft-reschke-http-jfv-02 . . . . . . . . . . . . . 15 E.3. Since draft-reschke-http-jfv-02 . . . . . . . . . . . . . 16
E.4. Since draft-reschke-http-jfv-03 . . . . . . . . . . . . . 15 E.4. Since draft-reschke-http-jfv-03 . . . . . . . . . . . . . 16
E.5. Since draft-reschke-http-jfv-04 . . . . . . . . . . . . . 15 E.5. Since draft-reschke-http-jfv-04 . . . . . . . . . . . . . 16
E.6. Since draft-ietf-httpbis-jfv-00 . . . . . . . . . . . . . 15 E.6. Since draft-ietf-httpbis-jfv-00 . . . . . . . . . . . . . 16
E.7. Since draft-ietf-httpbis-jfv-01 . . . . . . . . . . . . . 15 E.7. Since draft-ietf-httpbis-jfv-01 . . . . . . . . . . . . . 16
E.8. Since draft-ietf-httpbis-jfv-02 . . . . . . . . . . . . . 16 E.8. Since draft-ietf-httpbis-jfv-02 . . . . . . . . . . . . . 16
E.9. Since draft-reschke-http-jfv-05 . . . . . . . . . . . . . 16 E.9. Since draft-reschke-http-jfv-05 . . . . . . . . . . . . . 17
E.10. Since draft-reschke-http-jfv-06 . . . . . . . . . . . . . 16 E.10. Since draft-reschke-http-jfv-06 . . . . . . . . . . . . . 17
E.11. Since draft-reschke-http-jfv-07 . . . . . . . . . . . . . 16 E.11. Since draft-reschke-http-jfv-07 . . . . . . . . . . . . . 17
E.12. Since draft-reschke-http-jfv-08 . . . . . . . . . . . . . 16 E.12. Since draft-reschke-http-jfv-08 . . . . . . . . . . . . . 17
E.13. Since draft-reschke-http-jfv-09 . . . . . . . . . . . . . 16 E.13. Since draft-reschke-http-jfv-09 . . . . . . . . . . . . . 17
E.14. Since draft-reschke-http-jfv-10 . . . . . . . . . . . . . 16 E.14. Since draft-reschke-http-jfv-10 . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17 E.15. Since draft-reschke-http-jfv-11 . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Defining syntax for new HTTP header fields ([RFC7230], Section 3.2) Defining syntax for new HTTP header fields ([RFC7230], Section 3.2)
is non-trivial. Among the commonly encountered problems are: is non-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 header fields do use a similarly looking syntax, but it is known header fields do use a similarly looking syntax, but it is
hard to write generic parsing code that will both correctly handle hard to write generic parsing code that will both correctly handle
valid field values but also reject invalid ones. valid field values but also reject invalid ones.
skipping to change at page 8, line 44 skipping to change at page 9, line 6
Latest version available at <https://www.w3.org/TR/clear- Latest version available at <https://www.w3.org/TR/clear-
site-data/>. site-data/>.
[ECMA-262] [ECMA-262]
Ecma International, "ECMA-262 6th Edition, The ECMAScript 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/>.
[FEATUREPOL] [FEATUREPOL]
Clelland, I., "Feature Policy", W3C Draft Community Group Clelland, I., "Feature Policy", W3C Editor's Draft ,
Report , October 2019, <https://w3c.github.io/webappsec-feature-policy/>.
<https://wicg.github.io/feature-policy/>.
[HSTRUCT] Nottingham, M. and P-H. Kamp, "Structured Headers for [HSTRUCT] Nottingham, M. and P-H. Kamp, "Structured Field Values for
HTTP", draft-ietf-httpbis-header-structure-14 (work in HTTP", draft-ietf-httpbis-header-structure-19 (work in
progress), October 2019. progress), June 2020.
[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/
IEC 8859-1:1998, 1998. IEC 8859-1:1998, 1998.
[KEY] Fielding, R. and M. Nottingham, "The Key HTTP Response [KEY] Fielding, R. and M. Nottingham, "The Key HTTP Response
Header Field", draft-ietf-httpbis-key-01 (work in Header Field", draft-ietf-httpbis-key-01 (work in
progress), March 2016. progress), March 2016.
skipping to change at page 14, line 21 skipping to change at page 15, line 21
B.2. W3C Clear Site Data Specification B.2. W3C Clear Site Data Specification
Used in earlier versions of "Clear Site Data". The current version Used in earlier versions of "Clear Site Data". The current version
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).
B.3. W3C Feature Policy Specification B.3. W3C Feature Policy Specification
Originally defined in W3C Draft Community Group Report "Feature Originally defined in W3C document "Feature Policy" ([FEATUREPOL]),
Policy" ([FEATUREPOL]), but now replaced with a custom syntax (see but now replaced with a custom syntax.
<https://github.com/WICG/feature-policy/pull/83>).
Appendix C. Relation to HTTP 'Key' Header Field Appendix C. Relation to HTTP 'Key' Header Field
[KEY] aims to improve the cacheability of responses that vary based [KEY] aims to improve the cacheability of responses that vary based
on certain request header fields, addressing lack of granularity in on certain request header fields, addressing lack of granularity in
the existing "Vary" response header field ([RFC7231], Section 7.1.4). the existing "Vary" response header field ([RFC7231], Section 7.1.4).
If the JSON-based format described by this document gains popularity, If the JSON-based format described by this document gains popularity,
it might be useful to add a JSON-aware "Key Parameter" (see it might be useful to add a JSON-aware "Key Parameter" (see
Section 2.3 of [KEY]). Section 2.3 of [KEY]).
skipping to change at page 17, line 5 skipping to change at page 17, line 43
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".
E.14. Since draft-reschke-http-jfv-10 E.14. Since draft-reschke-http-jfv-10
Update HSTRUCT reference. Update HSTRUCT reference.
E.15. Since draft-reschke-http-jfv-11
Update HSTRUCT reference.
Update note about FEATUREPOL.
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. 15 change blocks. 
46 lines changed or deleted 51 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/