idnits 2.17.1 draft-reschke-http-jfv-07.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: ---------------------------------------------------------------------------- No issues found here. 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.) ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 289: '... 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 (October 24, 2017) is 2374 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 423 -- Looks like a reference, but probably isn't: '2' on line 425 ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** 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-01 -- Obsolete informational reference (is this intentional?): RFC 7235 (Obsoleted by RFC 9110) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Reschke 3 Internet-Draft greenbytes 4 Intended status: Standards Track October 24, 2017 5 Expires: April 27, 2018 7 A JSON Encoding for HTTP Header Field Values 8 draft-reschke-http-jfv-07 10 Abstract 12 This document establishes a convention for use of JSON-encoded field 13 values in HTTP header fields. 15 Editorial Note (To be removed by RFC Editor before publication) 17 Distribution of this document is unlimited. Although this is not a 18 work item of the HTTPbis Working Group, comments should be sent to 19 the Hypertext Transfer Protocol (HTTP) mailing list at ietf-http- 20 wg@w3.org [1], which may be joined by sending a message with subject 21 "subscribe" to ietf-http-wg-request@w3.org [2]. 23 Discussions of the HTTPbis Working Group are archived at 24 . 26 XML versions and latest edits for this document are available from 27 . 29 The changes in this draft are summarized in Appendix E.10. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 27, 2018. 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Data Model and Format . . . . . . . . . . . . . . . . . . . . 4 67 3. Sender Requirements . . . . . . . . . . . . . . . . . . . . . 5 68 4. Recipient Requirements . . . . . . . . . . . . . . . . . . . 5 69 5. Using this Format in Header Field Definitions . . . . . . . . 5 70 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 6 71 7. Interoperability Considerations . . . . . . . . . . . . . . . 6 72 7.1. Encoding and Characters . . . . . . . . . . . . . . . . . 6 73 7.2. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 7.3. Object Constraints . . . . . . . . . . . . . . . . . . . 7 75 8. Internationalization Considerations . . . . . . . . . . . . . 7 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 79 10.2. Informative References . . . . . . . . . . . . . . . . . 8 80 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 10 82 A.1. Content-Length . . . . . . . . . . . . . . . . . . . . . 10 83 A.2. Content-Disposition . . . . . . . . . . . . . . . . . . . 10 84 A.3. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 11 85 A.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 12 86 Appendix B. Use of JSON Field Value Encoding in the Wild . . . . 13 87 B.1. W3C Reporting API Specification . . . . . . . . . . . . . 14 88 B.2. W3C Clear Site Data Specification . . . . . . . . . . . . 14 89 B.3. W3C Feature Policy Specification . . . . . . . . . . . . 14 90 Appendix C. Relation to HTTP 'Key' Header Field . . . . . . . . 14 91 Appendix D. Discussion . . . . . . . . . . . . . . . . . . . . . 14 92 Appendix E. Change Log (to be removed by RFC Editor before 93 publication) . . . . . . . . . . . . . . . . . . . . 15 94 E.1. Since draft-reschke-http-jfv-00 . . . . . . . . . . . . . 15 95 E.2. Since draft-reschke-http-jfv-01 . . . . . . . . . . . . . 15 96 E.3. Since draft-reschke-http-jfv-02 . . . . . . . . . . . . . 15 97 E.4. Since draft-reschke-http-jfv-03 . . . . . . . . . . . . . 15 98 E.5. Since draft-reschke-http-jfv-04 . . . . . . . . . . . . . 15 99 E.6. Since draft-ietf-httpbis-jfv-00 . . . . . . . . . . . . . 15 100 E.7. Since draft-ietf-httpbis-jfv-01 . . . . . . . . . . . . . 15 101 E.8. Since draft-ietf-httpbis-jfv-02 . . . . . . . . . . . . . 16 102 E.9. Since draft-reschke-http-jfv-05 . . . . . . . . . . . . . 16 103 E.10. Since draft-reschke-http-jfv-06 . . . . . . . . . . . . . 16 104 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16 105 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 107 1. Introduction 109 Defining syntax for new HTTP header fields ([RFC7230], Section 3.2) 110 is non-trivial. Among the commonly encountered problems are: 112 o There is no common syntax for complex field values. Several well- 113 known header fields do use a similarly looking syntax, but it is 114 hard to write generic parsing code that will both correctly handle 115 valid field values but also reject invalid ones. 117 o The HTTP message format allows header fields to repeat, so field 118 syntax needs to be designed in a way that these cases are either 119 meaningful, or can be unambiguously detected and rejected. 121 o HTTP/1.1 does not define a character encoding scheme ([RFC6365], 122 Section 2), so header fields are either stuck with US-ASCII 123 ([RFC0020]), or need out-of-band information to decide what 124 encoding scheme is used. Furthermore, APIs usually assume a 125 default encoding scheme in order to map from octet sequences to 126 strings (for instance, [XMLHttpRequest] uses the IDL type 127 "ByteString", effectively resulting in the ISO-8859-1 character 128 encoding scheme [ISO-8859-1] being used). 130 (See Section 8.3.1 of [RFC7231] for a summary of considerations for 131 new header fields.) 133 This specification addresses the issues listed above by defining both 134 a generic JSON-based ([RFC7159]) data model and a concrete wire 135 format that can be used in definitions of new header fields, where 136 the goals were: 138 o to be compatible with header field recombination when fields occur 139 multiple times in a single message (Section 3.2.2 of [RFC7230]), 140 and 142 o not to use any problematic characters in the field value (non- 143 ASCII characters and certain whitespace characters). 145 Note: [HSTRUCT], a work item of the IETF HTTP Working Group, is a 146 different attempt to address this set of problems -- it tries to 147 identify and formalize common field structures in existing header 148 fields; the syntax defined over there would usually lead to a more 149 compact notation. 151 2. Data Model and Format 153 In HTTP, header fields with the same field name can occur multiple 154 times within a single message (Section 3.2.2 of [RFC7230]). When 155 this happens, recipients are allowed to combine the field values 156 using commas as delimiter. This rule matches nicely JSON's array 157 format (Section 5 of [RFC7159]). Thus, the basic data model used 158 here is the JSON array. 160 Header field definitions that need only a single value can restrict 161 themselves to arrays of length 1, and are encouraged to define error 162 handling in case more values are received (such as "first wins", 163 "last wins", or "abort with fatal error message"). 165 JSON arrays are mapped to field values by creating a sequence of 166 serialized member elements, separated by commas and optionally 167 whitespace. This is equivalent to using the full JSON array format, 168 while leaving out the "begin-array" ('[') and "end-array" (']') 169 delimiters. 171 The ABNF character names and classes below are used (copied from 172 [RFC5234], Appendix B.1): 174 CR = %x0D ; carriage return 175 HTAB = %x09 ; horizontal tab 176 LF = %x0A ; line feed 177 SP = %x20 ; space 178 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 ([RFC7159], 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 194 json-field-item = JSON-Text 195 ; see [RFC7159], Section 2, 196 ; post-processed so that only VCHAR characters 197 ; are used 199 3. Sender Requirements 201 To map a JSON array to an HTTP header field value, process each array 202 element separately by: 204 1. generating the JSON representation, 206 2. stripping all JSON control characters (CR, HTAB, LF), or 207 replacing them by space ("SP") characters, 209 3. replacing all remaining non-VSPACE characters by the equivalent 210 backslash-escape sequence ([RFC7159], Section 7). 212 The resulting list of strings is transformed into an HTTP field value 213 by combining them using comma (%x2C) plus optional SP as delimiter, 214 and encoding the resulting string into an octet sequence using the 215 US-ASCII character encoding scheme ([RFC0020]). 217 4. Recipient Requirements 219 To map a set of HTTP header field instances to a JSON array: 221 1. combine all header field instances into a single field as per 222 Section 3.2.2 of [RFC7230], 224 2. add a leading begin-array ("[") octet and a trailing end-array 225 ("]") octet, then 227 3. run the resulting octet sequence through a JSON parser. 229 The result of the parsing operation is either an error (in which case 230 the header field values needs to be considered invalid), or a JSON 231 array. 233 5. Using this Format in Header Field Definitions 235 Specifications defining new HTTP header fields need to take the 236 considerations listed in Section 8.3.1 of [RFC7231] into account. 237 Many of these will already be accounted for by using the format 238 defined in this specification. 240 Readers of HTTP-related specifications frequently expect an ABNF 241 definition of the field value syntax. This is not really needed 242 here, as the actual syntax is JSON text, as defined in Section 2 of 243 [RFC7159]. 245 A very simple way to use this JSON encoding thus is just to cite this 246 specification -- specifically the "json-field-value" ABNF production 247 defined in Section 2 -- and otherwise not to talk about the details 248 of the field syntax at all. 250 An alternative approach is just to repeat the ABNF-related parts from 251 Section 2. 253 This frees the specification from defining the concrete on-the-wire 254 syntax. What's left is defining the field value in terms of a JSON 255 array. An important aspect is the question of extensibility, e.g. 256 how recipients ought to treat unknown field names. In general, a 257 "must ignore" approach will allow protocols to evolve without 258 versioning or even using entire new field names. 260 6. Deployment Considerations 262 This JSON-based syntax will only apply to newly introduced header 263 fields, thus backwards compatibility is not a problem. That being 264 said, it is conceivable that there is existing code that might trip 265 over double quotes not being used for HTTP's quoted-string syntax 266 (Section 3.2.6 of [RFC7230]). 268 7. Interoperability Considerations 270 The "I-JSON Message Format" specification ([RFC7493]) addresses known 271 JSON interoperability pain points. This specification borrows from 272 the requirements made over there: 274 7.1. Encoding and Characters 276 This specification requires that field values use only US-ASCII 277 characters, and thus by definition use a subset of UTF-8 (Section 2.1 278 of [RFC7493]). 280 7.2. Numbers 282 Be aware of the issues around number precision, as discussed in 283 Section 2.2 of [RFC7493]. 285 7.3. Object Constraints 287 As described in Section 4 of [RFC7159], JSON parser implementations 288 differ in the handling of duplicate object names. Therefore, senders 289 MUST NOT use duplicate object names, and recipients SHOULD either 290 treat field values with duplicate names as invalid (consistent with 291 [RFC7493], Section 2.3) or use the lexically last value (consistent 292 with [ECMA-262], Section 24.3.1.1). 294 Furthermore, ordering of object members is not significant and can 295 not be relied upon. 297 8. Internationalization Considerations 299 In HTTP/1.1, header field values are represented by octet sequences, 300 usually used to transmit ASCII characters, with restrictions on the 301 use of certain control characters, and no associated default 302 character encoding, nor a way to describe it ([RFC7230], 303 Section 3.2). HTTP/2 does not change this. 305 This specification maps all characters which can cause problems to 306 JSON escape sequences, thereby solving the HTTP header field 307 internationalization problem. 309 Future specifications of HTTP might change to allow non-ASCII 310 characters natively. In that case, header fields using the syntax 311 defined by this specification would have a simple migration path (by 312 just stopping to require escaping of non-ASCII characters). 314 9. Security Considerations 316 Using JSON-shaped field values is believed to not introduce any new 317 threads beyond those described in Section 12 of [RFC7159], namely the 318 risk of recipients using the wrong tools to parse them. 320 Other than that, any syntax that makes extensions easy can be used to 321 smuggle information through field values; however, this concern is 322 shared with other widely used formats, such as those using parameters 323 in the form of name/value pairs. 325 10. References 327 10.1. Normative References 329 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 330 RFC 20, DOI 10.17487/RFC0020, October 1969, 331 . 333 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 334 Specifications: ABNF", STD 68, RFC 5234, 335 DOI 10.17487/RFC5234, January 2008, 336 . 338 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 339 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 340 2014, . 342 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 343 Protocol (HTTP/1.1): Message Syntax and Routing", 344 RFC 7230, DOI 10.17487/RFC7230, June 2014, 345 . 347 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 348 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 349 DOI 10.17487/RFC7231, June 2014, 350 . 352 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 353 DOI 10.17487/RFC7493, March 2015, 354 . 356 10.2. Informative References 358 [CLEARSITE] 359 West, M., "Clear Site Data", W3C Working Draft WD-clear- 360 site-data-20160720, July 2016, 361 . 363 Latest version available at . 366 [ECMA-262] 367 Ecma International, "ECMA-262 6th Edition, The ECMAScript 368 2015 Language Specification", Standard ECMA-262, June 369 2015, . 371 [FEATUREPOL] 372 Clelland, I., "Clear Site Data", W3C Draft Community Group 373 Report , June 2017, 374 . 376 [HSTRUCT] Kamp, P-H., "HTTP Header Common Structure", draft-ietf- 377 httpbis-header-structure-01 (work in progress), April 378 2017. 380 [ISO-8859-1] 381 International Organization for Standardization, 382 "Information technology -- 8-bit single-byte coded graphic 383 character sets -- Part 1: Latin alphabet No. 1", ISO/ 384 IEC 8859-1:1998, 1998. 386 [KEY] Fielding, R. and M. Nottingham, "The Key HTTP Response 387 Header Field", draft-ietf-httpbis-key-01 (work in 388 progress), March 2016. 390 [REPORTING] 391 Grigorik, I. and M. West, "Reporting API 1", W3C Group 392 Note NOTE-reporting-1-20160607, June 2016, 393 . 395 Latest version available at . 398 [RFC6266] Reschke, J., "Use of the Content-Disposition Header Field 399 in the Hypertext Transfer Protocol (HTTP)", RFC 6266, 400 DOI 10.17487/RFC6266, June 2011, 401 . 403 [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in 404 Internationalization in the IETF", BCP 166, RFC 6365, 405 DOI 10.17487/RFC6365, September 2011, 406 . 408 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 409 Protocol (HTTP/1.1): Authentication", RFC 7235, 410 DOI 10.17487/RFC7235, June 2014, 411 . 413 [RFC8187] Reschke, J., "Indicating Character Encoding and Language 414 for HTTP Header Field Parameters", RFC 8187, 415 DOI 10.17487/RFC8187, September 2017, 416 . 418 [XMLHttpRequest] 419 WhatWG, "XMLHttpRequest", . 421 10.3. URIs 423 [1] mailto:ietf-http-wg@w3.org 425 [2] mailto:ietf-http-wg-request@w3.org?subject=subscribe 427 Appendix A. Examples 429 This section shows how some of the existing HTTP header fields would 430 look like if they would use the format defined by this specification. 432 A.1. Content-Length 434 "Content-Length" is defined in Section 3.3.2 of [RFC7230], with the 435 field value's ABNF being: 437 Content-Length = 1*DIGIT 439 So the field value is similar to a JSON number ([RFC7159], 440 Section 6). 442 Content-Length is restricted to a single field instance, as it 443 doesn't use the list production (as per Section 3.2.2 of [RFC7230]). 444 However, in practice multiple instances do occur, and the definition 445 of the header field does indeed discuss how to handle these cases. 447 If Content-Length was defined using the JSON format discussed here, 448 the ABNF would be something like: 450 Content-Length = #number 451 ; number: [RFC7159], Section 6 453 ...and the prose definition would: 455 o restrict all numbers to be non-negative integers without 456 fractions, and 458 o require that the array of values is of length 1 (but allow the 459 case where the array is longer, but all members represent the same 460 value) 462 A.2. Content-Disposition 464 Content-Disposition field values, defined in [RFC6266], consist of a 465 "disposition type" (a string), plus multiple parameters, of which at 466 least one ("filename") sometime needs to carry non-ASCII characters. 468 For instance, the first example in Section 5 of [RFC6266]: 470 Attachment; filename=example.html 472 has a disposition type of "Attachment", with filename parameter value 473 "example.html". A JSON representation of this information might be: 475 { 476 "Attachment": { 477 "filename" : "example.html" 478 } 479 } 481 which would translate to a header field value of: 483 { "Attachment": { "filename" : "example.html" } } 485 The third example in Section 5 of [RFC6266] uses a filename parameter 486 containing non-US-ASCII characters: 488 attachment; filename*=UTF-8''%e2%82%ac%20rates 490 Note that in this case, the "filename*" parameter uses the encoding 491 defined in [RFC8187], representing a filename starting with the 492 Unicode character U+20AC (EURO SIGN), followed by " rates". If the 493 definition of Content-Disposition would have used the format proposed 494 here, the workaround involving the "parameter*" syntax would not have 495 been needed at all. 497 The JSON representation of this value could then be: 499 { "attachment": { "filename" : "\u20AC rates" } } 501 A.3. WWW-Authenticate 503 The WWW-Authenticate header field value is defined in Section 4.1 of 504 [RFC7235] as a list of "challenges": 506 WWW-Authenticate = 1#challenge 508 ...where a challenge consists of a scheme with optional parameters: 510 challenge = auth-scheme [ 1*SP ( token68 / #auth-param ) ] 512 An example for a complex header field value given in the definition 513 of the header field is: 515 Newauth realm="apps", type=1, title="Login to \"apps\"", 516 Basic realm="simple" 518 (line break added for readability) 520 A possible JSON representation of this field value would be the array 521 below: 523 [ 524 { 525 "Newauth" : { 526 "realm": "apps", 527 "type" : 1, 528 "title" : "Login to \"apps\"" 529 } 530 }, 531 { 532 "Basic" : { 533 "realm": "simple" 534 } 535 } 536 ] 538 ...which would translate to a header field value of: 540 { "Newauth" : { "realm": "apps", "type" : 1, 541 "title": "Login to \"apps\"" }}, 542 { "Basic" : { "realm": "simple"}} 544 A.4. Accept-Encoding 546 The Accept-Encoding header field value is defined in Section 5.3.4 of 547 [RFC7231] as a list of codings, each of which allowing a weight 548 parameter 'q': 550 Accept-Encoding = #( codings [ weight ] ) 551 codings = content-coding / "identity" / "*" 552 weight = OWS ";" OWS "q=" qvalue 553 qvalue = ( "0" [ "." 0*3DIGIT ] ) 554 / ( "1" [ "." 0*3("0") ] ) 556 An example for a complex header field value given in the definition 557 of the header field is: 559 gzip;q=1.0, identity; q=0.5, *;q=0 561 Due to the defaulting rules for the quality value ([RFC7231], 562 Section 5.3.1), this could also be written as: 564 gzip, identity; q=0.5, *; q=0 566 A JSON representation could be: 568 [ 569 { 570 "gzip" : { 571 } 572 }, 573 { 574 "identity" : { 575 "q": 0.5 576 } 577 }, 578 { 579 "*" : { 580 "q": 0 581 } 582 } 583 ] 585 ...which would translate to a header field value of: 587 {"gzip": {}}, {"identity": {"q": 0.5}}, {"*": {"q": 0}} 589 In this example, the part about "gzip" appears unnecessarily verbose, 590 as the value is just an empty object. A simpler notation would 591 collapse members like these to string literals: 593 "gzip", {"identity": {"q": 0.5}}, {"*": {"q": 0}} 595 If this is desirable, the header field definition could allow both 596 string literals and objects, and define that a mere string literal 597 would be mapped to a member whose name is given by the string 598 literal, and the value is an empty object. 600 For what it's worth, one of the most common cases for 'Accept- 601 Encoding' would become: 603 "gzip", "deflate" 605 which would be only a small overhead over the original format. 607 Appendix B. Use of JSON Field Value Encoding in the Wild 609 Since work started on this document, various specifications have 610 adopted this format. At least one of these moved away after the HTTP 611 Working Group decided to focus on [HSTRUCT] (see thread starting at 612 ). 615 The sections below summarize the current usage of this format. 617 B.1. W3C Reporting API Specification 619 Defined in W3C Note "Reporting API 1" (Section 3.1 of [REPORTING]). 620 Still in use in latest editor copy as of June 2017. 622 B.2. W3C Clear Site Data Specification 624 Defined in W3C Working Draft "Clear Site Data" (Section 2.1 of 625 [CLEARSITE]). Latest Editor's Draft at replaces the use of JSON with a 627 custom syntax that happens to be somewhat compatible with an array of 628 JSON strings (see for feedback). 631 B.3. W3C Feature Policy Specification 633 Defined in W3C Draft Community Group Report "Feature Policy" 634 (Section 6.1 of [FEATUREPOL]). Previously relied on this document, 635 now replicates the syntax into a custom ABNF defined in a separate 636 section (Section 5.1 of [FEATUREPOL]). 638 Appendix C. Relation to HTTP 'Key' Header Field 640 [KEY] aims to improve the cacheability of responses that vary based 641 on certain request header fields, addressing lack of granularity in 642 the existing "Vary" response header field ([RFC7231], Section 7.1.4). 643 If the JSON-based format described by this document gains popularity, 644 it might be useful to add a JSON-aware "Key Parameter" (see 645 Section 2.3 of [KEY]). 647 Appendix D. Discussion 649 This approach uses a default of "JSON array", using implicit array 650 markers. An alternative would be a default of "JSON object". This 651 would simplify the syntax for non-list-typed header fields, but all 652 the benefits of having the same data model for both types of header 653 fields would be gone. A hybrid approach might make sense, as long as 654 it doesn't require any heuristics on the recipient's side. 656 Note: a concrete proposal was made by Kazuho Oku in 657 . 660 [[CREF1: Use of generic libs vs compactness of field values..]] 662 Appendix E. Change Log (to be removed by RFC Editor before publication) 664 E.1. Since draft-reschke-http-jfv-00 666 Editorial fixes + working on the TODOs. 668 E.2. Since draft-reschke-http-jfv-01 670 Mention slightly increased risk of smuggling information in header 671 field values. 673 E.3. Since draft-reschke-http-jfv-02 675 Mention Kazuho Oku's proposal for abbreviated forms. 677 Added a bit of text about the motivation for a concrete JSON subset 678 (ack Cory Benfield). 680 Expand I18N section. 682 E.4. Since draft-reschke-http-jfv-03 684 Mention relation to KEY header field. 686 E.5. Since draft-reschke-http-jfv-04 688 Between June and December 2016, this was a work item of the HTTP 689 working group (see ). Work (if any) continues now on 691 . 693 Changes made while this was a work item of the HTTP Working Group: 695 E.6. Since draft-ietf-httpbis-jfv-00 697 Added example for "Accept-Encoding" (inspired by Kazuho's feedback), 698 showing a potential way to optimize the format when default values 699 apply. 701 E.7. Since draft-ietf-httpbis-jfv-01 703 Add interop discussion, building on I-JSON and ECMA-262 (see 704 ). 706 E.8. Since draft-ietf-httpbis-jfv-02 708 Move non-essential parts into appendix. 710 Updated XHR reference. 712 E.9. Since draft-reschke-http-jfv-05 714 Add meat to "Using this Format in Header Field Definitions". 716 Add a few lines on the relation to "Key". 718 Summarize current use of the format. 720 E.10. Since draft-reschke-http-jfv-06 722 RFC 5987 is obsoleted by RFC 8187. 724 Upcate CLEARSITE comment. 726 Acknowledgements 728 Thanks go to the Hypertext Transfer Protocol Working Group 729 participants. 731 Author's Address 733 Julian F. Reschke 734 greenbytes GmbH 735 Hafenweg 16 736 Muenster, NW 48155 737 Germany 739 EMail: julian.reschke@greenbytes.de 740 URI: http://greenbytes.de/tech/webdav/