idnits 2.17.1 draft-reschke-http-jfv-10.txt: -(483): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 2 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.) ** There are 3 instances of too long lines in the document, the longest one being 152 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 285: '... MUST NOT use duplicate object names...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (14 October 2019) is 1646 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-header-structure-13 -- Obsolete informational reference (is this intentional?): RFC 7235 (Obsoleted by RFC 9110) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 2 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 14 October 2019 5 Expires: 16 April 2020 7 A JSON Encoding for HTTP Header Field Values 8 draft-reschke-http-jfv-10 10 Abstract 12 This document establishes a convention for use of JSON-encoded field 13 values in HTTP header 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 http://lists.w3.org/Archives/Public/ietf-http-wg/. 30 XML versions and latest edits for this document are available from 31 http://greenbytes.de/tech/webdav/#draft-reschke-http-jfv. 33 The changes in this draft are summarized in Appendix E.13. 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 16 April 2020. 51 Copyright Notice 53 Copyright (c) 2019 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 2. Data Model and Format . . . . . . . . . . . . . . . . . . . . 4 69 3. Sender Requirements . . . . . . . . . . . . . . . . . . . . . 5 70 4. Recipient Requirements . . . . . . . . . . . . . . . . . . . 5 71 5. Using this Format in Header Field Definitions . . . . . . . . 5 72 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 6 73 7. Interoperability Considerations . . . . . . . . . . . . . . . 6 74 7.1. Encoding and Characters . . . . . . . . . . . . . . . . . 6 75 7.2. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 7.3. Object Constraints . . . . . . . . . . . . . . . . . . . 6 77 8. Internationalization Considerations . . . . . . . . . . . . . 7 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 81 10.2. Informative References . . . . . . . . . . . . . . . . . 8 82 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 9 83 A.1. Content-Length . . . . . . . . . . . . . . . . . . . . . 9 84 A.2. Content-Disposition . . . . . . . . . . . . . . . . . . . 10 85 A.3. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 11 86 A.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 12 87 Appendix B. Use of JSON Field Value Encoding in the 88 Wild . . . . . . . . . . . . . . . . . . . . . . . . . . 13 89 B.1. W3C Reporting API Specification . . . . . . . . . . . . . 13 90 B.2. W3C Clear Site Data Specification . . . . . . . . . . . . 13 91 B.3. W3C Feature Policy Specification . . . . . . . . . . . . 13 92 Appendix C. Relation to HTTP 'Key' Header Field . . . . . . . . 14 93 Appendix D. Discussion . . . . . . . . . . . . . . . . . . . . . 14 94 Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 14 95 E.1. Since draft-reschke-http-jfv-00 . . . . . . . . . . . . . 14 96 E.2. Since draft-reschke-http-jfv-01 . . . . . . . . . . . . . 14 97 E.3. Since draft-reschke-http-jfv-02 . . . . . . . . . . . . . 14 98 E.4. Since draft-reschke-http-jfv-03 . . . . . . . . . . . . . 15 99 E.5. Since draft-reschke-http-jfv-04 . . . . . . . . . . . . . 15 100 E.6. Since draft-ietf-httpbis-jfv-00 . . . . . . . . . . . . . 15 101 E.7. Since draft-ietf-httpbis-jfv-01 . . . . . . . . . . . . . 15 102 E.8. Since draft-ietf-httpbis-jfv-02 . . . . . . . . . . . . . 15 103 E.9. Since draft-reschke-http-jfv-05 . . . . . . . . . . . . . 15 104 E.10. Since draft-reschke-http-jfv-06 . . . . . . . . . . . . . 15 105 E.11. Since draft-reschke-http-jfv-07 . . . . . . . . . . . . . 15 106 E.12. Since draft-reschke-http-jfv-08 . . . . . . . . . . . . . 16 107 E.13. Since draft-reschke-http-jfv-09 . . . . . . . . . . . . . 16 108 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16 109 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 111 1. Introduction 113 Defining syntax for new HTTP header fields ([RFC7230], Section 3.2) 114 is non-trivial. Among the commonly encountered problems are: 116 * There is no common syntax for complex field values. Several well- 117 known header fields do use a similarly looking syntax, but it is 118 hard to write generic parsing code that will both correctly handle 119 valid field values but also reject invalid ones. 121 * The HTTP message format allows header fields to repeat, so field 122 syntax needs to be designed in a way that these cases are either 123 meaningful, or can be unambiguously detected and rejected. 125 * HTTP/1.1 does not define a character encoding scheme ([RFC6365], 126 Section 2), so header fields are either stuck with US-ASCII 127 ([RFC0020]), or need out-of-band information to decide what 128 encoding scheme is used. Furthermore, APIs usually assume a 129 default encoding scheme in order to map from octet sequences to 130 strings (for instance, [XMLHttpRequest] uses the IDL type 131 "ByteString", effectively resulting in the ISO-8859-1 character 132 encoding scheme [ISO-8859-1] being used). 134 (See Section 8.3.1 of [RFC7231] for a summary of considerations for 135 new header fields.) 137 This specification addresses the issues listed above by defining both 138 a generic JSON-based ([RFC8259]) data model and a concrete wire 139 format that can be used in definitions of new header fields, where 140 the goals were: 142 * to be compatible with header field recombination when fields occur 143 multiple times in a single message (Section 3.2.2 of [RFC7230]), 144 and 146 * not to use any problematic characters in the field value (non- 147 ASCII characters and certain whitespace characters). 149 | *Note:*[HSTRUCT], a work item of the IETF HTTP Working Group, 150 | is a different attempt to address this set of problems -- it 151 | tries to identify and formalize common field structures in 152 | existing header fields; the syntax defined over there would 153 | usually lead to a more compact notation. 155 2. Data Model and Format 157 In HTTP, header fields with the same field name can occur multiple 158 times within a single message (Section 3.2.2 of [RFC7230]). When 159 this happens, recipients are allowed to combine the field values 160 using commas as delimiter. This rule matches nicely JSON's array 161 format (Section 5 of [RFC8259]). Thus, the basic data model used 162 here is the JSON array. 164 Header field definitions that need only a single value can restrict 165 themselves to arrays of length 1, and are encouraged to define error 166 handling in case more values are received (such as "first wins", 167 "last wins", or "abort with fatal error message"). 169 JSON arrays are mapped to field values by creating a sequence of 170 serialized member elements, separated by commas and optionally 171 whitespace. This is equivalent to using the full JSON array format, 172 while leaving out the "begin-array" ('[') and "end-array" (']') 173 delimiters. 175 The ABNF character names and classes below are used (copied from 176 [RFC5234], Appendix B.1): 178 CR = %x0D ; carriage return HTAB = %x09 ; horizontal tab LF = %x0A ; line feed SP = %x20 ; space VCHAR = %x21-7E ; visible (printing) characters 180 Characters in JSON strings that are not allowed or discouraged in 181 HTTP header field values -- that is, not in the "VCHAR" definition -- 182 need to be represented using JSON's "backslash" escaping mechanism 183 ([RFC8259], Section 7). 185 The control characters CR, LF, and HTAB do not appear inside JSON 186 strings, but can be used outside (line breaks, indentation etc.). 187 These characters need to be either stripped or replaced by space 188 characters (ABNF "SP"). 190 Formally, using the HTTP specification's ABNF extensions defined in 191 Section 7 of [RFC7230]: 193 json-field-value = #json-field-item json-field-item = JSON-Text ; see [RFC8259], Section 2, ; post-processed so that only VCHAR characters ; are used 195 3. Sender Requirements 197 To map a JSON array to an HTTP header field value, process each array 198 element separately by: 200 1. generating the JSON representation, 202 2. stripping all JSON control characters (CR, HTAB, LF), or 203 replacing them by space ("SP") characters, 205 3. replacing all remaining non-VSPACE characters by the equivalent 206 backslash-escape sequence ([RFC8259], Section 7). 208 The resulting list of strings is transformed into an HTTP field value 209 by combining them using comma (%x2C) plus optional SP as delimiter, 210 and encoding the resulting string into an octet sequence using the 211 US-ASCII character encoding scheme ([RFC0020]). 213 4. Recipient Requirements 215 To map a set of HTTP header field instances to a JSON array: 217 1. combine all header field instances into a single field as per 218 Section 3.2.2 of [RFC7230], 220 2. add a leading begin-array ("[") octet and a trailing end-array 221 ("]") octet, then 223 3. run the resulting octet sequence through a JSON parser. 225 The result of the parsing operation is either an error (in which case 226 the header field values needs to be considered invalid), or a JSON 227 array. 229 5. Using this Format in Header Field Definitions 231 Specifications defining new HTTP header fields need to take the 232 considerations listed in Section 8.3.1 of [RFC7231] into account. 233 Many of these will already be accounted for by using the format 234 defined in this specification. 236 Readers of HTTP-related specifications frequently expect an ABNF 237 definition of the field value syntax. This is not really needed 238 here, as the actual syntax is JSON text, as defined in Section 2 of 239 [RFC8259]. 241 A very simple way to use this JSON encoding thus is just to cite this 242 specification -- specifically the "json-field-value" ABNF production 243 defined in Section 2 -- and otherwise not to talk about the details 244 of the field syntax at all. 246 An alternative approach is just to repeat the ABNF-related parts from 247 Section 2. 249 This frees the specification from defining the concrete on-the-wire 250 syntax. What's left is defining the field value in terms of a JSON 251 array. An important aspect is the question of extensibility, e.g. 252 how recipients ought to treat unknown field names. In general, a 253 "must ignore" approach will allow protocols to evolve without 254 versioning or even using entire new field names. 256 6. Deployment Considerations 258 This JSON-based syntax will only apply to newly introduced header 259 fields, thus backwards compatibility is not a problem. That being 260 said, it is conceivable that there is existing code that might trip 261 over double quotes not being used for HTTP's quoted-string syntax 262 (Section 3.2.6 of [RFC7230]). 264 7. Interoperability Considerations 266 The "I-JSON Message Format" specification ([RFC7493]) addresses known 267 JSON interoperability pain points. This specification borrows from 268 the requirements made over there: 270 7.1. Encoding and Characters 272 This specification requires that field values use only US-ASCII 273 characters, and thus by definition use a subset of UTF-8 (Section 2.1 274 of [RFC7493]). 276 7.2. Numbers 278 Be aware of the issues around number precision, as discussed in 279 Section 2.2 of [RFC7493]. 281 7.3. Object Constraints 283 As described in Section 4 of [RFC8259], JSON parser implementations 284 differ in the handling of duplicate object names. Therefore, senders 285 MUST NOT use duplicate object names, and recipients SHOULD either 286 treat field values with duplicate names as invalid (consistent with 287 [RFC7493], Section 2.3) or use the lexically last value (consistent 288 with [ECMA-262], Section 24.3.1.1). 290 Furthermore, ordering of object members is not significant and can 291 not be relied upon. 293 8. Internationalization Considerations 295 In HTTP/1.1, header field values are represented by octet sequences, 296 usually used to transmit ASCII characters, with restrictions on the 297 use of certain control characters, and no associated default 298 character encoding, nor a way to describe it ([RFC7230], 299 Section 3.2). HTTP/2 does not change this. 301 This specification maps all characters which can cause problems to 302 JSON escape sequences, thereby solving the HTTP header field 303 internationalization problem. 305 Future specifications of HTTP might change to allow non-ASCII 306 characters natively. In that case, header fields using the syntax 307 defined by this specification would have a simple migration path (by 308 just stopping to require escaping of non-ASCII characters). 310 9. Security Considerations 312 Using JSON-shaped field values is believed to not introduce any new 313 threads beyond those described in Section 12 of [RFC8259], namely the 314 risk of recipients using the wrong tools to parse them. 316 Other than that, any syntax that makes extensions easy can be used to 317 smuggle information through field values; however, this concern is 318 shared with other widely used formats, such as those using parameters 319 in the form of name/value pairs. 321 10. References 323 10.1. Normative References 325 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 326 RFC 20, DOI 10.17487/RFC0020, October 1969, 327 . 329 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 330 Specifications: ABNF", STD 68, RFC 5234, 331 DOI 10.17487/RFC5234, January 2008, 332 . 334 [RFC7230] Fielding, R., Ed. and J. F. Reschke, Ed., "Hypertext 335 Transfer Protocol (HTTP/1.1): Message Syntax and Routing", 336 RFC 7230, DOI 10.17487/RFC7230, June 2014, 337 . 339 [RFC7231] Fielding, R., Ed. and J. F. Reschke, Ed., "Hypertext 340 Transfer Protocol (HTTP/1.1): Semantics and Content", 341 RFC 7231, DOI 10.17487/RFC7231, June 2014, 342 . 344 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 345 DOI 10.17487/RFC7493, March 2015, 346 . 348 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 349 Interchange Format", RFC 8259, DOI 10.17487/RFC8259, 350 December 2017, . 352 10.2. Informative References 354 [CLEARSITE] 355 West, M., "Clear Site Data", W3C Working Draft WD-clear- 356 site-data-20171130, 30 November 2017, 357 . 358 Latest version available at https://www.w3.org/TR/clear- 359 site-data/. 361 [ECMA-262] Ecma International, "ECMA-262 6th Edition, The ECMAScript 362 2015 Language Specification", Standard ECMA-262, June 363 2015, . 365 [FEATUREPOL] 366 Clelland, I., "Feature Policy", W3C Draft Community Group 367 Report , 3 October 2019, 368 . 370 [HSTRUCT] Nottingham, M. and P-H. Kamp, "Structured Headers for 371 HTTP", Internet-Draft, draft-ietf-httpbis-header- 372 structure-13, August 2019, 373 . 376 [ISO-8859-1] 377 International Organization for Standardization, 378 "Information technology -- 8-bit single-byte coded graphic 379 character sets -- Part 1: Latin alphabet No. 1", ISO/ 380 IEC 8859-1:1998, 1998. 382 [KEY] Fielding, R. and M. Nottingham, "The Key HTTP Response 383 Header Field", Internet-Draft, draft-ietf-httpbis-key-01, 384 March 2016, 385 . 387 [REPORTING] 388 Creager, D., Grigorik, I., Meyer, P., and M. West, 389 "Reporting API", W3C Working Draft WD-reporting- 390 1-20180925, 25 September 2018, 391 . 392 Latest version available at https://www.w3.org/TR/ 393 reporting-1/. 395 [RFC6266] Reschke, J. F., "Use of the Content-Disposition Header 396 Field in the Hypertext Transfer Protocol (HTTP)", 397 RFC 6266, DOI 10.17487/RFC6266, June 2011, 398 . 400 [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in 401 Internationalization in the IETF", BCP 166, RFC 6365, 402 DOI 10.17487/RFC6365, September 2011, 403 . 405 [RFC7235] Fielding, R., Ed. and J. F. Reschke, Ed., "Hypertext 406 Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, 407 DOI 10.17487/RFC7235, June 2014, 408 . 410 [RFC8187] Reschke, J. F., "Indicating Character Encoding and 411 Language for HTTP Header Field Parameters", RFC 8187, 412 DOI 10.17487/RFC8187, September 2017, 413 . 415 [XMLHttpRequest] 416 WhatWG, "XMLHttpRequest", October 2019, 417 . 419 Appendix A. Examples 421 This section shows how some of the existing HTTP header fields would 422 look like if they would use the format defined by this specification. 424 A.1. Content-Length 426 "Content-Length" is defined in Section 3.3.2 of [RFC7230], with the 427 field value's ABNF being: 429 Content-Length = 1*DIGIT 431 So the field value is similar to a JSON number ([RFC8259], 432 Section 6). 434 Content-Length is restricted to a single field instance, as it 435 doesn't use the list production (as per Section 3.2.2 of [RFC7230]). 436 However, in practice multiple instances do occur, and the definition 437 of the header field does indeed discuss how to handle these cases. 439 If Content-Length was defined using the JSON format discussed here, 440 the ABNF would be something like: 442 Content-Length = #number ; number: [RFC8259], Section 6 444 ...and the prose definition would: 446 * restrict all numbers to be non-negative integers without 447 fractions, and 449 * require that the array of values is of length 1 (but allow the 450 case where the array is longer, but all members represent the same 451 value) 453 A.2. Content-Disposition 455 Content-Disposition field values, defined in [RFC6266], consist of a 456 "disposition type" (a string), plus multiple parameters, of which at 457 least one ("filename") sometime needs to carry non-ASCII characters. 459 For instance, the first example in Section 5 of [RFC6266]: 461 Attachment; filename=example.html 463 has a disposition type of "Attachment", with filename parameter value 464 "example.html". A JSON representation of this information might be: 466 { 467 "Attachment": { 468 "filename" : "example.html" 469 } 470 } 472 which would translate to a header field value of: 474 { "Attachment": { "filename" : "example.html" } } 476 The third example in Section 5 of [RFC6266] uses a filename parameter 477 containing non-US-ASCII characters: 479 attachment; filename*=UTF-8''%e2%82%ac%20rates 481 Note that in this case, the "filename*" parameter uses the encoding 482 defined in [RFC8187], representing a filename starting with the 483 Unicode character "€" (EURO SIGN, U+20AC), followed by " rates". If 484 the definition of Content-Disposition would have used the format 485 proposed here, the workaround involving the "parameter*" syntax would 486 not have been needed at all. 488 The JSON representation of this value could then be: 490 { "attachment": { "filename" : "\u20AC rates" } } 492 A.3. WWW-Authenticate 494 The WWW-Authenticate header field value is defined in Section 4.1 of 495 [RFC7235] as a list of "challenges": 497 WWW-Authenticate = 1#challenge 499 ...where a challenge consists of a scheme with optional parameters: 501 challenge = auth-scheme [ 1*SP ( token68 / #auth-param ) ] 503 An example for a complex header field value given in the definition 504 of the header field is: 506 Newauth realm="apps", type=1, title="Login to \"apps\"", 507 Basic realm="simple" 509 (line break added for readability) 511 A possible JSON representation of this field value would be the array 512 below: 514 [ 515 { 516 "Newauth" : { 517 "realm": "apps", 518 "type" : 1, 519 "title" : "Login to \"apps\"" 520 } 521 }, 522 { 523 "Basic" : { 524 "realm": "simple" 525 } 526 } 527 ] 529 ...which would translate to a header field value of: 531 { "Newauth" : { "realm": "apps", "type" : 1, 532 "title": "Login to \"apps\"" }}, 533 { "Basic" : { "realm": "simple"}} 535 A.4. Accept-Encoding 537 The Accept-Encoding header field value is defined in Section 5.3.4 of 538 [RFC7231] as a list of codings, each of which allowing a weight 539 parameter 'q': 541 Accept-Encoding = #( codings [ weight ] ) codings = content-coding / "identity" / "*" weight = OWS ";" OWS "q=" qvalue qvalue = ( "0" [ "." 0*3DIGIT ] ) / ( "1" [ "." 0*3("0") ] ) 543 An example for a complex header field value given in the definition 544 of the header field is: 546 gzip;q=1.0, identity; q=0.5, *;q=0 548 Due to the defaulting rules for the quality value ([RFC7231], 549 Section 5.3.1), this could also be written as: 551 gzip, identity; q=0.5, *; q=0 553 A JSON representation could be: 555 [ 556 { 557 "gzip" : { 558 } 559 }, 560 { 561 "identity" : { 562 "q": 0.5 563 } 564 }, 565 { 566 "*" : { 567 "q": 0 568 } 569 } 570 ] 572 ...which would translate to a header field value of: 574 {"gzip": {}}, {"identity": {"q": 0.5}}, {"*": {"q": 0}} 576 In this example, the part about "gzip" appears unnecessarily verbose, 577 as the value is just an empty object. A simpler notation would 578 collapse members like these to string literals: 580 "gzip", {"identity": {"q": 0.5}}, {"*": {"q": 0}} 582 If this is desirable, the header field definition could allow both 583 string literals and objects, and define that a mere string literal 584 would be mapped to a member whose name is given by the string 585 literal, and the value is an empty object. 587 For what it's worth, one of the most common cases for 'Accept- 588 Encoding' would become: 590 "gzip", "deflate" 592 which would be only a small overhead over the original format. 594 Appendix B. Use of JSON Field Value Encoding in the Wild 596 Since work started on this document, various specifications have 597 adopted this format. At least one of these moved away after the HTTP 598 Working Group decided to focus on [HSTRUCT] (see thread starting at 599 https://lists.w3.org/Archives/Public/ietf-http- 600 wg/2016OctDec/0505.html). 602 The sections below summarize the current usage of this format. 604 B.1. W3C Reporting API Specification 606 Defined in W3C Working Draft "Reporting API" (Section 3.1 of 607 [REPORTING]). Still in use in latest working draft dated September 608 2018. 610 B.2. W3C Clear Site Data Specification 612 Used in earlier versions of "Clear Site Data". The current version 613 replaces the use of JSON with a custom syntax that happens to be 614 somewhat compatible with an array of JSON strings (see Section 3.1 of 615 [CLEARSITE] and https://lists.w3.org/Archives/Public/ietf-http- 616 wg/2017AprJun/0214.html for feedback). 618 B.3. W3C Feature Policy Specification 620 Originally defined in W3C Draft Community Group Report "Feature 621 Policy" ([FEATUREPOL]), but now replaced with a custom syntax (see 622 https://github.com/WICG/feature-policy/pull/83). 624 Appendix C. Relation to HTTP 'Key' Header Field 626 [KEY] aims to improve the cacheability of responses that vary based 627 on certain request header fields, addressing lack of granularity in 628 the existing "Vary" response header field ([RFC7231], Section 7.1.4). 629 If the JSON-based format described by this document gains popularity, 630 it might be useful to add a JSON-aware "Key Parameter" (see 631 Section 2.3 of [KEY]). 633 Appendix D. Discussion 635 This approach uses a default of "JSON array", using implicit array 636 markers. An alternative would be a default of "JSON object". This 637 would simplify the syntax for non-list-typed header fields, but all 638 the benefits of having the same data model for both types of header 639 fields would be gone. A hybrid approach might make sense, as long as 640 it doesn't require any heuristics on the recipient's side. 642 | *Note:* a concrete proposal was made by Kazuho Oku in 643 | https://lists.w3.org/Archives/Public/ietf-http- 644 | wg/2016JanMar/0155.html. 646 // Use of generic libs vs compactness of field values.. 648 Appendix E. Change Log 650 This section is to be removed before publishing as an RFC. 652 E.1. Since draft-reschke-http-jfv-00 654 Editorial fixes + working on the TODOs. 656 E.2. Since draft-reschke-http-jfv-01 658 Mention slightly increased risk of smuggling information in header 659 field values. 661 E.3. Since draft-reschke-http-jfv-02 663 Mention Kazuho Oku's proposal for abbreviated forms. 665 Added a bit of text about the motivation for a concrete JSON subset 666 (ack Cory Benfield). 668 Expand I18N section. 670 E.4. Since draft-reschke-http-jfv-03 672 Mention relation to KEY header field. 674 E.5. Since draft-reschke-http-jfv-04 676 Between June and December 2016, this was a work item of the HTTP 677 working group (see https://datatracker.ietf.org/doc/draft-ietf- 678 httpbis-jfv/). Work (if any) continues now on 679 https://datatracker.ietf.org/doc/draft-reschke-http-jfv/. 681 Changes made while this was a work item of the HTTP Working Group: 683 E.6. Since draft-ietf-httpbis-jfv-00 685 Added example for "Accept-Encoding" (inspired by Kazuho's feedback), 686 showing a potential way to optimize the format when default values 687 apply. 689 E.7. Since draft-ietf-httpbis-jfv-01 691 Add interop discussion, building on I-JSON and ECMA-262 (see 692 https://github.com/httpwg/http-extensions/issues/225). 694 E.8. Since draft-ietf-httpbis-jfv-02 696 Move non-essential parts into appendix. 698 Updated XHR reference. 700 E.9. Since draft-reschke-http-jfv-05 702 Add meat to "Using this Format in Header Field Definitions". 704 Add a few lines on the relation to "Key". 706 Summarize current use of the format. 708 E.10. Since draft-reschke-http-jfv-06 710 RFC 5987 is obsoleted by RFC 8187. 712 Update CLEARSITE comment. 714 E.11. Since draft-reschke-http-jfv-07 716 Update JSON and HSTRUCT references. 718 FEATUREPOL doesn't use JSON syntax anymore. 720 E.12. Since draft-reschke-http-jfv-08 722 Update HSTRUCT reference. 724 Update notes about CLEARSITE and FEATUREPOL. 726 E.13. Since draft-reschke-http-jfv-09 728 Update HSTRUCT and FEATUREPOL references. 730 Update note about REPORTING. 732 Changed category to "informational". 734 Acknowledgements 736 Thanks go to the Hypertext Transfer Protocol Working Group 737 participants. 739 Author's Address 741 Julian F. Reschke 742 greenbytes GmbH 743 Hafenweg 16 744 48155 Münster 745 Germany 747 Email: julian.reschke@greenbytes.de 748 URI: http://greenbytes.de/tech/webdav/