idnits 2.17.1
draft-reschke-http-jfv-14.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== There are 6 instances of lines with non-ascii characters in the document.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (22 April 2021) is 1099 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
-- Looks like a reference, but probably isn't: '17' on line 273
-- Looks like a reference, but probably isn't: '42' on line 273
== Missing Reference: 'CLEARSITE' is mentioned on line 542, but not defined
== Missing Reference: 'FEATUREPOL' is mentioned on line 547, but not defined
== Missing Reference: 'REPORTING' is mentioned on line 534, but not defined
== Outdated reference: A later version (-19) exists of
draft-ietf-httpbis-semantics-15
Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group J. F. Reschke
3 Internet-Draft greenbytes
4 Intended status: Informational 22 April 2021
5 Expires: 24 October 2021
7 A JSON Encoding for HTTP Field Values
8 draft-reschke-http-jfv-14
10 Abstract
12 This document establishes a convention for use of JSON-encoded field
13 values in new HTTP fields.
15 Editorial Note
17 This note is to be removed before publishing as an RFC.
19 Distribution of this document is unlimited. Although this is not a
20 work item of the HTTPbis Working Group, comments should be sent to
21 the Hypertext Transfer Protocol (HTTP) mailing list at ietf-http-
22 wg@w3.org (mailto:ietf-http-wg@w3.org), which may be joined by
23 sending a message with subject "subscribe" to ietf-http-wg-
24 request@w3.org (mailto:ietf-http-wg-
25 request@w3.org?subject=subscribe).
27 Discussions of the HTTPbis Working Group are archived at
28 .
30 XML versions and latest edits for this document are available from
31 .
33 The changes in this draft are summarized in Appendix D.17.
35 Status of This Memo
37 This Internet-Draft is submitted in full conformance with the
38 provisions of BCP 78 and BCP 79.
40 Internet-Drafts are working documents of the Internet Engineering
41 Task Force (IETF). Note that other groups may also distribute
42 working documents as Internet-Drafts. The list of current Internet-
43 Drafts is at https://datatracker.ietf.org/drafts/current/.
45 Internet-Drafts are draft documents valid for a maximum of six months
46 and may be updated, replaced, or obsoleted by other documents at any
47 time. It is inappropriate to use Internet-Drafts as reference
48 material or to cite them other than as "work in progress."
49 This Internet-Draft will expire on 24 October 2021.
51 Copyright Notice
53 Copyright (c) 2021 IETF Trust and the persons identified as the
54 document authors. All rights reserved.
56 This document is subject to BCP 78 and the IETF Trust's Legal
57 Provisions Relating to IETF Documents (https://trustee.ietf.org/
58 license-info) in effect on the date of publication of this document.
59 Please review these documents carefully, as they describe your rights
60 and restrictions with respect to this document. Code Components
61 extracted from this document must include Simplified BSD License text
62 as described in Section 4.e of the Trust Legal Provisions and are
63 provided without warranty as described in the Simplified BSD License.
65 Table of Contents
67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
68 1.1. Relation to "Structured Field Values for HTTP"
69 (RFC8941) . . . . . . . . . . . . . . . . . . . . . . . . 4
70 2. Data Model and Format . . . . . . . . . . . . . . . . . . . . 4
71 3. Sender Requirements . . . . . . . . . . . . . . . . . . . . . 5
72 3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5
73 4. Recipient Requirements . . . . . . . . . . . . . . . . . . . 6
74 4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6
75 5. Using this Format in Field Definitions . . . . . . . . . . . 7
76 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 7
77 7. Interoperability Considerations . . . . . . . . . . . . . . . 7
78 7.1. Encoding and Characters . . . . . . . . . . . . . . . . . 7
79 7.2. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 8
80 7.3. Object Constraints . . . . . . . . . . . . . . . . . . . 8
81 8. Internationalization Considerations . . . . . . . . . . . . . 8
82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
84 10.1. Normative References . . . . . . . . . . . . . . . . . . 9
85 10.2. Informative References . . . . . . . . . . . . . . . . . 9
86 10.3. Specifications Using This Syntax (at some point of
87 time) . . . . . . . . . . . . . . . . . . . . . . . . . 10
88 Appendix A. Comparison with Structured Fields . . . . . . . . . 10
89 A.1. Base Types . . . . . . . . . . . . . . . . . . . . . . . 10
90 A.2. Structures . . . . . . . . . . . . . . . . . . . . . . . 11
91 Appendix B. Use of JSON Field Value Encoding in the Wild . . . . 11
92 B.1. W3C Reporting API Specification . . . . . . . . . . . . . 12
93 B.2. W3C Clear Site Data Specification . . . . . . . . . . . . 12
94 B.3. W3C Feature Policy Specification . . . . . . . . . . . . 12
95 Appendix C. Implementations . . . . . . . . . . . . . . . . . . 12
96 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 12
97 D.1. Since draft-reschke-http-jfv-00 . . . . . . . . . . . . . 12
98 D.2. Since draft-reschke-http-jfv-01 . . . . . . . . . . . . . 12
99 D.3. Since draft-reschke-http-jfv-02 . . . . . . . . . . . . . 13
100 D.4. Since draft-reschke-http-jfv-03 . . . . . . . . . . . . . 13
101 D.5. Since draft-reschke-http-jfv-04 . . . . . . . . . . . . . 13
102 D.6. Since draft-ietf-httpbis-jfv-00 . . . . . . . . . . . . . 13
103 D.7. Since draft-ietf-httpbis-jfv-01 . . . . . . . . . . . . . 13
104 D.8. Since draft-ietf-httpbis-jfv-02 . . . . . . . . . . . . . 13
105 D.9. Since draft-reschke-http-jfv-05 . . . . . . . . . . . . . 13
106 D.10. Since draft-reschke-http-jfv-06 . . . . . . . . . . . . . 14
107 D.11. Since draft-reschke-http-jfv-07 . . . . . . . . . . . . . 14
108 D.12. Since draft-reschke-http-jfv-08 . . . . . . . . . . . . . 14
109 D.13. Since draft-reschke-http-jfv-09 . . . . . . . . . . . . . 14
110 D.14. Since draft-reschke-http-jfv-10 . . . . . . . . . . . . . 14
111 D.15. Since draft-reschke-http-jfv-11 . . . . . . . . . . . . . 14
112 D.16. Since draft-reschke-http-jfv-12 . . . . . . . . . . . . . 15
113 D.17. Since draft-reschke-http-jfv-13 . . . . . . . . . . . . . 15
114 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
115 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
117 1. Introduction
119 Defining syntax for new HTTP fields ([HTTP], Section 5) is non-
120 trivial. Among the commonly encountered problems are:
122 * There is no common syntax for complex field values. Several well-
123 known fields do use a similarly looking syntax, but it is hard to
124 write generic parsing code that will both correctly handle valid
125 field values but also reject invalid ones.
127 * The HTTP message format allows field lines to repeat, so field
128 syntax needs to be designed in a way that these cases are either
129 meaningful, or can be unambiguously detected and rejected.
131 * HTTP does not define a character encoding scheme ([RFC6365],
132 Section 2), so fields are either stuck with US-ASCII ([RFC0020]),
133 or need out-of-band information to decide what encoding scheme is
134 used. Furthermore, APIs usually assume a default encoding scheme
135 in order to map from octet sequences to strings (for instance,
136 [XMLHttpRequest] uses the IDL type "ByteString", effectively
137 resulting in the ISO-8859-1 character encoding scheme [ISO-8859-1]
138 being used).
140 (See Section 16.3 of [HTTP] for a summary of considerations for new
141 fields.)
142 This specification addresses the issues listed above by defining both
143 a generic JSON-based ([RFC8259]) data model and a concrete wire
144 format that can be used in definitions of new fields, where the goals
145 were:
147 * to be compatible with field recombination when field lines occur
148 multiple times in a single message (Section 5.3 of [HTTP]), and
150 * not to use any problematic characters in the field value (non-
151 ASCII characters and certain whitespace characters).
153 1.1. Relation to "Structured Field Values for HTTP" ([RFC8941])
155 "Structured Field Values for HTTP", an IETF RFC on the Standards
156 Track, is a different approach to this set of problems. It uses a
157 more compact notation, similar to what is used in existing header
158 fields, and avoids several potential interoperability problems
159 inherent to the use of JSON.
161 In general, that format is preferred for newly defined fields. The
162 JSON-based format defined by this document might however be useful in
163 case the data that needs to be transferred is already in JSON format,
164 or features not covered by "Structured Field Values" are needed.
166 See Appendix A for more details.
168 2. Data Model and Format
170 In HTTP, field lines with the same field name can occur multiple
171 times within a single message (Section 5.3 of [HTTP]). When this
172 happens, recipients are allowed to combine the field line values
173 using commas as delimiter, forming a combined "field value". This
174 rule matches nicely JSON's array format (Section 5 of [RFC8259]).
175 Thus, the basic data model used here is the JSON array.
177 Field definitions that need only a single value can restrict
178 themselves to arrays of length 1, and are encouraged to define error
179 handling in case more values are received (such as "first wins",
180 "last wins", or "abort with fatal error message").
182 JSON arrays are mapped to field values by creating a sequence of
183 serialized member elements, separated by commas and optionally
184 whitespace. This is equivalent to using the full JSON array format,
185 while leaving out the "begin-array" ('[') and "end-array" (']')
186 delimiters.
188 The ABNF character names and classes below are used (copied from
189 [RFC5234], Appendix B.1):
191 CR = %x0D ; carriage return
192 HTAB = %x09 ; horizontal tab
193 LF = %x0A ; line feed
194 SP = %x20 ; space
195 VCHAR = %x21-7E ; visible (printing) characters
197 Characters in JSON strings that are not allowed or discouraged in
198 HTTP field values - that is, not in the "VCHAR" definition - need to
199 be represented using JSON's "backslash" escaping mechanism
200 ([RFC8259], Section 7).
202 The control characters CR, LF, and HTAB do not appear inside JSON
203 strings, but can be used outside (line breaks, indentation etc.).
204 These characters need to be either stripped or replaced by space
205 characters (ABNF "SP").
207 Formally, using the HTTP specification's ABNF extensions defined in
208 Section 5.6.1 of [HTTP]:
210 json-field-value = #json-field-item
211 json-field-item = JSON-Text
212 ; see [RFC8259], Section 2,
213 ; post-processed so that only VCHAR characters
214 ; are used
216 3. Sender Requirements
218 To map a JSON array to an HTTP field value, process each array
219 element separately by:
221 1. generating the JSON representation,
223 2. stripping all JSON control characters (CR, HTAB, LF), or
224 replacing them by space ("SP") characters,
226 3. replacing all remaining non-VSPACE characters by the equivalent
227 backslash-escape sequence ([RFC8259], Section 7).
229 The resulting list of strings is transformed into an HTTP field value
230 by combining them using comma (%x2C) plus optional SP as delimiter,
231 and encoding the resulting string into an octet sequence using the
232 US-ASCII character encoding scheme ([RFC0020]).
234 3.1. Example
236 With the JSON data below, containing the non-ASCII characters "ü"
237 (LATIN SMALL LETTER U WITH DIAERESIS, U+00FC) and "€" (EURO SIGN,
238 U+20AC):
240 [
241 {
242 "destination": "Münster",
243 "price": 123,
244 "currency": "€"
245 }
246 ]
248 The generated field value would be:
250 { "destination": "M\u00FCnster", "price": 123, "currency": "\u20AC" }
252 4. Recipient Requirements
254 To map a set of HTTP field line values to a JSON array:
256 1. combine all field line values into a single field value as per
257 Section 5.3 of [HTTP],
259 2. add a leading begin-array ("[") octet and a trailing end-array
260 ("]") octet, then
262 3. run the resulting octet sequence through a JSON parser.
264 The result of the parsing operation is either an error (in which case
265 the field values needs to be considered invalid), or a JSON array.
267 4.1. Example
269 An HTTP message containing the field lines:
271 Example: "\u221E"
272 Example: {"date":"2012-08-25"}
273 Example: [17,42]
275 would be parsed into the JSON array below:
277 [
278 "∞",
279 {
280 "date": "2012-08-25"
281 },
282 [
283 17,
284 42
285 ]
286 ]
288 5. Using this Format in Field Definitions
290 Specifications defining new HTTP fields need to take the
291 considerations listed in Section 16.3 of [HTTP] into account. Many
292 of these will already be accounted for by using the format defined in
293 this specification.
295 Readers of HTTP-related specifications frequently expect an ABNF
296 definition of the field value syntax. This is not really needed
297 here, as the actual syntax is JSON text, as defined in Section 2 of
298 [RFC8259].
300 A very simple way to use this JSON encoding thus is just to cite this
301 specification - specifically the "json-field-value" ABNF production
302 defined in Section 2 - and otherwise not to talk about the details of
303 the field syntax at all.
305 An alternative approach is just to repeat the ABNF-related parts from
306 Section 2.
308 This frees the specification from defining the concrete on-the-wire
309 syntax. What's left is defining the field value in terms of a JSON
310 array. An important aspect is the question of extensibility, e.g.
311 how recipients ought to treat unknown field names. In general, a
312 "must ignore" approach will allow protocols to evolve without
313 versioning or even using entire new field names.
315 6. Deployment Considerations
317 This JSON-based syntax will only apply to newly introduced fields,
318 thus backwards compatibility is not a problem. That being said, it
319 is conceivable that there is existing code that might trip over
320 double quotes not being used for HTTP's quoted-string syntax
321 (Section 5.6.4 of [HTTP]).
323 7. Interoperability Considerations
325 The "I-JSON Message Format" specification ([RFC7493]) addresses known
326 JSON interoperability pain points. This specification borrows from
327 the requirements made over there:
329 7.1. Encoding and Characters
331 This specification requires that field values use only US-ASCII
332 characters, and thus by definition uses a subset of UTF-8
333 (Section 2.1 of [RFC7493]).
335 Furthermore, escape sequences in JSON strings (Section 7 of
336 [RFC8259]) - both in object member names and string values - are not
337 allowed to represent non-Unicode code points such as unpaired
338 surrogates or Noncharacters (see "General Structure" in [UNICODE]).
340 7.2. Numbers
342 Be aware of the issues around number precision, as discussed in
343 Section 2.2 of [RFC7493].
345 7.3. Object Constraints
347 As described in Section 4 of [RFC8259], JSON parser implementations
348 differ in the handling of duplicate object names. Therefore, senders
349 are not allowed to use duplicate object names, and recipients are
350 advised to either treat field values with duplicate names as invalid
351 (consistent with [RFC7493], Section 2.3) or use the lexically last
352 value (consistent with [ECMA-262], Section 24.3.1.1).
354 Furthermore, ordering of object members is not significant and can
355 not be relied upon.
357 8. Internationalization Considerations
359 In current versions of HTTP, field values are represented by octet
360 sequences, usually used to transmit ASCII characters, with
361 restrictions on the use of certain control characters, and no
362 associated default character encoding, nor a way to describe it
363 ([HTTP], Section 5).
365 This specification maps all characters which can cause problems to
366 JSON escape sequences, thereby solving the HTTP field
367 internationalization problem.
369 Future specifications of HTTP might change to allow non-ASCII
370 characters natively. In that case, fields using the syntax defined
371 by this specification would have a simple migration path (by just
372 stopping to require escaping of non-ASCII characters).
374 9. Security Considerations
376 Using JSON-shaped field values is believed to not introduce any new
377 threads beyond those described in Section 12 of [RFC8259], namely the
378 risk of recipients using the wrong tools to parse them.
380 Other than that, any syntax that makes extensions easy can be used to
381 smuggle information through field values; however, this concern is
382 shared with other widely used formats, such as those using parameters
383 in the form of name/value pairs.
385 10. References
387 10.1. Normative References
389 [HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
390 Ed., "HTTP Semantics", Work in Progress, Internet-Draft,
391 draft-ietf-httpbis-semantics-15, 30 March 2021,
392 .
395 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,
396 RFC 20, DOI 10.17487/RFC0020, October 1969,
397 .
399 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
400 Specifications: ABNF", STD 68, RFC 5234,
401 DOI 10.17487/RFC5234, January 2008,
402 .
404 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
405 DOI 10.17487/RFC7493, March 2015,
406 .
408 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
409 Interchange Format", RFC 8259, DOI 10.17487/RFC8259,
410 December 2017, .
412 [UNICODE] The Unicode Consortium, "The Unicode Standard",
413 .
415 10.2. Informative References
417 [ECMA-262] Ecma International, "ECMA-262 6th Edition, The ECMAScript
418 2015 Language Specification", Standard ECMA-262, June
419 2015, .
421 [ISO-8859-1]
422 International Organization for Standardization,
423 "Information technology -- 8-bit single-byte coded graphic
424 character sets -- Part 1: Latin alphabet No. 1", ISO/
425 IEC 8859-1:1998, 1998.
427 [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
428 Internationalization in the IETF", BCP 166, RFC 6365,
429 DOI 10.17487/RFC6365, September 2011,
430 .
432 [RFC8941] Nottingham, M. and P-H. Kamp, "Structured Field Values for
433 HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021,
434 .
436 [XMLHttpRequest]
437 WhatWG, "XMLHttpRequest", .
439 10.3. Specifications Using This Syntax (at some point of time)
441 [CLEARSITE]
442 West, M., "Clear Site Data", W3C Working Draft WD-clear-
443 site-data-20171130, 30 November 2017,
444 .
445 Latest version available at .
448 [FEATUREPOL]
449 Clelland, I., "Feature Policy", W3C Editor's Draft ,
450 .
452 [REPORTING]
453 Creager, D., Grigorik, I., Meyer, P., and M. West,
454 "Reporting API", W3C Working Draft WD-reporting-
455 1-20180925, 25 September 2018,
456 .
457 Latest version available at .
460 Appendix A. Comparison with Structured Fields
462 A.1. Base Types
464 +==========+==================================+==================+
465 | Type | in Structured Fields | in JSON-based |
466 | | | Fields |
467 +==========+==================================+==================+
468 | Integer | [RFC8941], Section 3.3.1 | [RFC8259], |
469 | | | Section 6 |
470 | +----------------------------------+------------------+
471 | | (restricted to 15 digits) | |
472 +==========+----------------------------------+------------------+
473 | Decimal | [RFC8941], Section 3.3.2 | [RFC8259], |
474 | | | Section 6 |
475 | +----------------------------------+------------------+
476 | | (a fixed point decimal | |
477 | | restricted to 12 + 3 digits) | |
478 +==========+----------------------------------+------------------+
479 | String | [RFC8941], Section 3.3.3 | [RFC8259], |
480 | | | Section 7 |
481 | +----------------------------------+------------------+
482 | | (only ASCII supported, non-ASCII | |
483 | | requires using Byte Sequences) | |
484 +==========+----------------------------------+------------------+
485 | Token | [RFC8941], Section 3.3.4 | not available |
486 +==========+----------------------------------+------------------+
487 | Byte | [RFC8941], Section 3.3.5 | not available |
488 | Sequence +----------------------------------+------------------+
489 | | | (usually mapped |
490 | | | to strings using |
491 | | | base64 encoding) |
492 +==========+----------------------------------+------------------+
493 | Boolean | [RFC8941], Section 3.3.6 | [RFC8259], |
494 | | | Section 3 |
495 +==========+----------------------------------+------------------+
497 Table 1
499 Structured Fields provide more data types (such as "token" or "byte
500 sequence"). Numbers are restricted, avoiding the JSON interop
501 problems described in Section 7.2. Strings are limited to ASCII,
502 requiring the use of byte sequences should non-ASCII characters be
503 needed.
505 A.2. Structures
507 Structured Fields define Lists ([RFC8941], Section 3.1), similar to
508 JSON arrays ([RFC8259], Section 5), and Dictionaries ([RFC8941],
509 Section 3.2), similar to JSON objects ([RFC8259], Section 4).
511 In addition, most items in Structured Fields can be parametrized
512 ([RFC8941], Section 3.1.2), attaching a dictionary-like structure to
513 the value. To emulate this in JSON based field, an additional
514 nesting of objects would be needed.
516 Finally, nesting of data structures is intentionally limited to two
517 levels (see Appendix A.1 of [RFC8941] for the motivation).
519 Appendix B. Use of JSON Field Value Encoding in the Wild
521 This section is to be removed before publishing as an RFC.
523 Since work started on this document, various specifications have
524 adopted this format. At least one of these moved away after the HTTP
525 Working Group decided to focus on [RFC8941] (see thread starting at
526 ).
529 The sections below summarize the current usage of this format.
531 B.1. W3C Reporting API Specification
533 Defined in W3C Working Draft "Reporting API" (Section 3.1 of
534 [REPORTING]). Still in use in latest working draft dated September
535 2018.
537 B.2. W3C Clear Site Data Specification
539 Used in earlier versions of "Clear Site Data". The current version
540 replaces the use of JSON with a custom syntax that happens to be
541 somewhat compatible with an array of JSON strings (see Section 3.1 of
542 [CLEARSITE] and for feedback).
545 B.3. W3C Feature Policy Specification
547 Originally defined in W3C document "Feature Policy" ([FEATUREPOL]),
548 but switched to use of Structured Header Fields ([RFC8941]).
550 Appendix C. Implementations
552 This section is to be removed before publishing as an RFC.
554 See for a proof-of-concept
555 (in development).
557 Appendix D. Change Log
559 This section is to be removed before publishing as an RFC.
561 D.1. Since draft-reschke-http-jfv-00
563 Editorial fixes + working on the TODOs.
565 D.2. Since draft-reschke-http-jfv-01
567 Mention slightly increased risk of smuggling information in header
568 field values.
570 D.3. Since draft-reschke-http-jfv-02
572 Mention Kazuho Oku's proposal for abbreviated forms.
574 Added a bit of text about the motivation for a concrete JSON subset
575 (ack Cory Benfield).
577 Expand I18N section.
579 D.4. Since draft-reschke-http-jfv-03
581 Mention relation to KEY header field.
583 D.5. Since draft-reschke-http-jfv-04
585 Between June and December 2016, this was a work item of the HTTP
586 working group (see ). Work (if any) continues now on
588 .
590 Changes made while this was a work item of the HTTP Working Group:
592 D.6. Since draft-ietf-httpbis-jfv-00
594 Added example for "Accept-Encoding" (inspired by Kazuho's feedback),
595 showing a potential way to optimize the format when default values
596 apply.
598 D.7. Since draft-ietf-httpbis-jfv-01
600 Add interop discussion, building on I-JSON and ECMA-262 (see
601 ).
603 D.8. Since draft-ietf-httpbis-jfv-02
605 Move non-essential parts into appendix.
607 Updated XHR reference.
609 D.9. Since draft-reschke-http-jfv-05
611 Add meat to "Using this Format in Header Field Definitions".
613 Add a few lines on the relation to "Key".
615 Summarize current use of the format.
617 D.10. Since draft-reschke-http-jfv-06
619 RFC 5987 is obsoleted by RFC 8187.
621 Update CLEARSITE comment.
623 D.11. Since draft-reschke-http-jfv-07
625 Update JSON and HSTRUCT references.
627 FEATUREPOL doesn't use JSON syntax anymore.
629 D.12. Since draft-reschke-http-jfv-08
631 Update HSTRUCT reference.
633 Update notes about CLEARSITE and FEATUREPOL.
635 D.13. Since draft-reschke-http-jfv-09
637 Update HSTRUCT and FEATUREPOL references.
639 Update note about REPORTING.
641 Changed category to "informational".
643 D.14. Since draft-reschke-http-jfv-10
645 Update HSTRUCT reference.
647 D.15. Since draft-reschke-http-jfv-11
649 Update HSTRUCT reference.
651 Update note about FEATUREPOL (now using Structured Fields).
653 Reference [HTTP] instead if RFC723* and adjust (header) field
654 terminology accordingly.
656 Remove discussion about the relation to KEY (as that spec is dormant:
657 ).
659 Remove appendices "Examples" and "Discussion".
661 Mark "Use of JSON Field Value Encoding in the Wild" for removal in
662 RFC.
664 D.16. Since draft-reschke-http-jfv-12
666 Update HTTP reference and update terminology some more.
668 Update HSTRUCT reference (now RFC 8941).
670 D.17. Since draft-reschke-http-jfv-13
672 Update HTTP reference.
674 Mention test implementation.
676 Clarify that Unicode unpaired surrogates or Noncharacters must not be
677 sent.
679 Rewrite text about [RFC8941], add appendix comparing both formats.
681 And send/receive examples.
683 Acknowledgements
685 Thanks go to the Hypertext Transfer Protocol Working Group
686 participants.
688 Author's Address
690 Julian F. Reschke
691 greenbytes GmbH
692 Hafenweg 16
693 48155 Münster
694 Germany
696 Email: julian.reschke@greenbytes.de
697 URI: http://greenbytes.de/tech/webdav/