idnits 2.17.1 draft-handrews-json-schema-validation-00.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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 19, 2017) is 2350 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2673 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) -- Obsolete informational reference (is this intentional?): RFC 4329 (Obsoleted by RFC 9239) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Wright, Ed. 3 Internet-Draft 4 Intended status: Informational H. Andrews, Ed. 5 Expires: May 23, 2018 Cloudflare, Inc. 6 G. Luff 7 November 19, 2017 9 JSON Schema Validation: A Vocabulary for Structural Validation of JSON 10 draft-handrews-json-schema-validation-00 12 Abstract 14 JSON Schema (application/schema+json) has several purposes, one of 15 which is JSON instance validation. This document specifies a 16 vocabulary for JSON Schema to describe the meaning of JSON documents, 17 provide hints for user interfaces working with JSON data, and to make 18 assertions about what a valid document must look like. 20 Note to Readers 22 The issues list for this draft can be found at . 25 For additional information, see . 27 To provide feedback, use this issue tracker, the communication 28 methods listed on the homepage, or email the document editors. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on May 23, 2018. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 66 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1.1. Keyword Independence . . . . . . . . . . . . . . . . 5 69 3.2. Assertions . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.2.1. Assertions and Instance Primitive Types . . . . . . . 6 71 3.3. Annotations . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.3.1. Negated Schemas . . . . . . . . . . . . . . . . . . . 7 73 3.3.2. Annotations and Short-Circuit Validation . . . . . . 7 74 4. Interoperability Considerations . . . . . . . . . . . . . . . 7 75 4.1. Validation of String Instances . . . . . . . . . . . . . 7 76 4.2. Validation of Numeric Instances . . . . . . . . . . . . . 7 77 4.3. Regular Expressions . . . . . . . . . . . . . . . . . . . 7 78 5. Meta-Schema . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 6. Validation Keywords . . . . . . . . . . . . . . . . . . . . . 8 80 6.1. Validation Keywords for Any Instance Type . . . . . . . . 8 81 6.1.1. type . . . . . . . . . . . . . . . . . . . . . . . . 8 82 6.1.2. enum . . . . . . . . . . . . . . . . . . . . . . . . 9 83 6.1.3. const . . . . . . . . . . . . . . . . . . . . . . . . 9 84 6.2. Validation Keywords for Numeric Instances (number and 85 integer) . . . . . . . . . . . . . . . . . . . . . . . . 9 86 6.2.1. multipleOf . . . . . . . . . . . . . . . . . . . . . 9 87 6.2.2. maximum . . . . . . . . . . . . . . . . . . . . . . . 9 88 6.2.3. exclusiveMaximum . . . . . . . . . . . . . . . . . . 9 89 6.2.4. minimum . . . . . . . . . . . . . . . . . . . . . . . 9 90 6.2.5. exclusiveMinimum . . . . . . . . . . . . . . . . . . 10 91 6.3. Validation Keywords for Strings . . . . . . . . . . . . . 10 92 6.3.1. maxLength . . . . . . . . . . . . . . . . . . . . . . 10 93 6.3.2. minLength . . . . . . . . . . . . . . . . . . . . . . 10 94 6.3.3. pattern . . . . . . . . . . . . . . . . . . . . . . . 10 96 6.4. Validation Keywords for Arrays . . . . . . . . . . . . . 11 97 6.4.1. items . . . . . . . . . . . . . . . . . . . . . . . . 11 98 6.4.2. additionalItems . . . . . . . . . . . . . . . . . . . 11 99 6.4.3. maxItems . . . . . . . . . . . . . . . . . . . . . . 11 100 6.4.4. minItems . . . . . . . . . . . . . . . . . . . . . . 11 101 6.4.5. uniqueItems . . . . . . . . . . . . . . . . . . . . . 12 102 6.4.6. contains . . . . . . . . . . . . . . . . . . . . . . 12 103 6.5. Validation Keywords for Objects . . . . . . . . . . . . . 12 104 6.5.1. maxProperties . . . . . . . . . . . . . . . . . . . . 12 105 6.5.2. minProperties . . . . . . . . . . . . . . . . . . . . 12 106 6.5.3. required . . . . . . . . . . . . . . . . . . . . . . 12 107 6.5.4. properties . . . . . . . . . . . . . . . . . . . . . 13 108 6.5.5. patternProperties . . . . . . . . . . . . . . . . . . 13 109 6.5.6. additionalProperties . . . . . . . . . . . . . . . . 13 110 6.5.7. dependencies . . . . . . . . . . . . . . . . . . . . 14 111 6.5.8. propertyNames . . . . . . . . . . . . . . . . . . . . 14 112 6.6. Keywords for Applying Subschemas Conditionally . . . . . 15 113 6.6.1. if . . . . . . . . . . . . . . . . . . . . . . . . . 15 114 6.6.2. then . . . . . . . . . . . . . . . . . . . . . . . . 15 115 6.6.3. else . . . . . . . . . . . . . . . . . . . . . . . . 15 116 6.7. Keywords for Applying Subschemas With Boolean Logic . . . 16 117 6.7.1. allOf . . . . . . . . . . . . . . . . . . . . . . . . 16 118 6.7.2. anyOf . . . . . . . . . . . . . . . . . . . . . . . . 16 119 6.7.3. oneOf . . . . . . . . . . . . . . . . . . . . . . . . 16 120 6.7.4. not . . . . . . . . . . . . . . . . . . . . . . . . . 16 121 7. Semantic Validation With "format" . . . . . . . . . . . . . . 16 122 7.1. Foreword . . . . . . . . . . . . . . . . . . . . . . . . 16 123 7.2. Implementation Requirements . . . . . . . . . . . . . . . 17 124 7.3. Defined Formats . . . . . . . . . . . . . . . . . . . . . 17 125 7.3.1. Dates and Times . . . . . . . . . . . . . . . . . . . 17 126 7.3.2. Email Addresses . . . . . . . . . . . . . . . . . . . 18 127 7.3.3. Hostnames . . . . . . . . . . . . . . . . . . . . . . 18 128 7.3.4. IP Addresses . . . . . . . . . . . . . . . . . . . . 19 129 7.3.5. Resource Identifiers . . . . . . . . . . . . . . . . 19 130 7.3.6. uri-template . . . . . . . . . . . . . . . . . . . . 19 131 7.3.7. JSON Pointers . . . . . . . . . . . . . . . . . . . . 19 132 7.3.8. regex . . . . . . . . . . . . . . . . . . . . . . . . 20 133 8. String-Encoding Non-JSON Data . . . . . . . . . . . . . . . . 20 134 8.1. Foreword . . . . . . . . . . . . . . . . . . . . . . . . 20 135 8.2. Implementation Requirements . . . . . . . . . . . . . . . 20 136 8.3. contentEncoding . . . . . . . . . . . . . . . . . . . . . 21 137 8.4. contentMediaType . . . . . . . . . . . . . . . . . . . . 21 138 8.5. Example . . . . . . . . . . . . . . . . . . . . . . . . . 21 139 9. Schema Re-Use With "definitions" . . . . . . . . . . . . . . 22 140 10. Schema Annotations . . . . . . . . . . . . . . . . . . . . . 22 141 10.1. "title" and "description" . . . . . . . . . . . . . . . 23 142 10.2. "default" . . . . . . . . . . . . . . . . . . . . . . . 23 143 10.3. "readOnly" and "writeOnly" . . . . . . . . . . . . . . . 23 144 10.4. "examples" . . . . . . . . . . . . . . . . . . . . . . . 24 145 11. Security Considerations . . . . . . . . . . . . . . . . . . . 24 146 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 147 12.1. Normative References . . . . . . . . . . . . . . . . . . 25 148 12.2. Informative References . . . . . . . . . . . . . . . . . 27 149 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 28 150 Appendix B. ChangeLog . . . . . . . . . . . . . . . . . . . . . 28 151 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 153 1. Introduction 155 JSON Schema can be used to require that a given JSON document (an 156 instance) satisfies a certain number of criteria. These criteria are 157 asserted by using keywords described in this specification. In 158 addition, a set of keywords is also defined to assist in interactive 159 user interface instance generation. 161 This specification will use the concepts, syntax, and terminology 162 defined by the JSON Schema core [json-schema] specification. 164 2. Conventions and Terminology 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in RFC 2119 [RFC2119]. 170 This specification uses the term "container instance" to refer to 171 both array and object instances. It uses the term "children 172 instances" to refer to array elements or object member values. 174 Elements in an array value are said to be unique if no two elements 175 of this array are equal [json-schema]. 177 3. Overview 179 JSON Schema validation applies schemas to locations within the 180 instance, and asserts constraints on the structure of the data at 181 each location. An instance location that satisfies all asserted 182 constraints is then annotated with any keywords that contain non- 183 assertion information, such as descriptive metadata and usage hints. 184 If all locations within the instance satisfy all asserted 185 constraints, then the instance is said to be valid against the 186 schema. 188 Each schema object is independently evaluated against each instance 189 location to which it applies. This greatly simplifies the 190 implementation requirements for validators by ensuring that they do 191 not need to maintain state across the document-wide validation 192 process. 194 3.1. Applicability 196 Validation begins by applying the root schema to the complete 197 instance document. From there, various keywords are used to 198 determine which additional subschemas are applied to either the 199 current location, or a child location. These keywords also define 200 whether and how subschema assertion results are modified and/or 201 combined. Such keywords do not assert conditions on their own. 202 Rather, they control how assertions are applied and evaluated. 204 The keywords in the boolean logic (Section 6.7) and conditional 205 (Section 6.6) sections of this specification apply subschemas to the 206 same location as the parent schema. The former group defines boolean 207 operations on the subschema assertion results, while the latter 208 evaluates one subschema and uses its assertion results to determine 209 which of two other subschemas to apply as well. 211 Several keywords determine which subschemas are applied to array 212 items, object property values, and object property names. They are: 213 "items", "additionalItems", "contains", "properties", 214 "patternProperties", "additionalProperties", and "propertyNames". 215 The "contains" keyword only requires its subschema to be valid 216 against at least one child instance, while the other keywords require 217 that all subschemas are valid against all child instances to which 218 they apply. 220 3.1.1. Keyword Independence 222 Validation keywords typically operate independently, without 223 affecting each other's outcomes. 225 For schema author convenience, there are some exceptions among the 226 keywords that control subschema applicability: 228 "additionalProperties", whose behavior is defined in terms of 229 "properties" and "patternProperties"; and 231 "additionalItems", whose behavior is defined in terms of "items". 233 3.2. Assertions 235 Validation is a process of checking assertions. Each assertion adds 236 constraints that an instance must satisfy in order to successfully 237 validate. 239 Assertion keywords that are absent never restrict validation. In 240 some cases, this no-op behavior is identical to a keyword that exists 241 with certain values, and these values are noted where known. 243 All of the keywords in the general (Section 6.1), numeric 244 (Section 6.2), and string (Section 6.3) sections are assertions, as 245 well as "minItems", "maxItems", "uniqueItems", "minProperties", 246 "maxProperties", and "required". Additionally, "dependencies" is 247 shorthand for a combination of conditional and assertion keywords. 249 The "format", "contentType", and "contentEncoding" keywords can also 250 be implemented as assertions, although that functionality is an 251 optional part of this specification, and the keywords convey 252 additional non-assertion information. 254 3.2.1. Assertions and Instance Primitive Types 256 Most validation assertions only constrain values within a certain 257 primitive type. When the type of the instance is not of the type 258 targeted by the keyword, the instance is considered to conform to the 259 assertion. 261 For example, the "maxLength" keyword will only restrict certain 262 strings (that are too long) from being valid. If the instance is a 263 number, boolean, null, array, or object, then it is valid against 264 this assertion. 266 3.3. Annotations 268 In addition to assertions, this specification provides a small 269 vocabulary of metadata keywords that can be used to annotate the JSON 270 instance with useful information. The Section 7 and Section 8 271 keywords are also useful as annotations as well as being optional 272 assertions, as they convey additional usage guidance for the instance 273 data. 275 A schema that is applicable to a particular location in the instance, 276 against which the instance location is valid, attaches its 277 annotations to that location in the instance. Since many subschemas 278 can be applicable to any single location, annotation keywords need to 279 specify any unusual handling of multiple applicable occurrences of 280 the keyword with different values. The default behavior is simply to 281 collect all values. 283 Additional vocabularies SHOULD make use of this mechanism for 284 applying their own annotations to instances. 286 3.3.1. Negated Schemas 288 Annotations in a subschema contained within a "not", at any depth, 289 including any number of intervening additional "not" subschemas, MUST 290 be ignored. Similarly, annotations within a failing branch of a 291 "oneOf", "anyOf", "then", or "else" MUST be ignored. 293 3.3.2. Annotations and Short-Circuit Validation 295 Annotation keywords MUST be applied to all possible sub-instances. 296 Even if such application can be short-circuited when only assertion 297 evaluation is needed. For instance, the "contains" keyword need only 298 be checked for assertions until at least one array item proves valid. 299 However, when working with annotations, all items in the array must 300 be evaluated to determine all items with which the annotations should 301 be associated. 303 4. Interoperability Considerations 305 4.1. Validation of String Instances 307 It should be noted that the nul character (\u0000) is valid in a JSON 308 string. An instance to validate may contain a string value with this 309 character, regardless of the ability of the underlying programming 310 language to deal with such data. 312 4.2. Validation of Numeric Instances 314 The JSON specification allows numbers with arbitrary precision, and 315 JSON Schema does not add any such bounds. This means that numeric 316 instances processed by JSON Schema can be arbitrarily large and/or 317 have an arbitrarily long decimal part, regardless of the ability of 318 the underlying programming language to deal with such data. 320 4.3. Regular Expressions 322 Two validation keywords, "pattern" and "patternProperties", use 323 regular expressions to express constraints, and the "regex" value for 324 the "format" keyword constrains the instance value to be a regular 325 expression. These regular expressions SHOULD be valid according to 326 the ECMA 262 [ecma262] regular expression dialect. 328 Furthermore, given the high disparity in regular expression 329 constructs support, schema authors SHOULD limit themselves to the 330 following regular expression tokens: 332 individual Unicode characters, as defined by the JSON 333 specification [RFC7159]; 334 simple character classes ([abc]), range character classes ([a-z]); 336 complemented character classes ([^abc], [^a-z]); 338 simple quantifiers: "+" (one or more), "*" (zero or more), "?" 339 (zero or one), and their lazy versions ("+?", "*?", "??"); 341 range quantifiers: "{x}" (exactly x occurrences), "{x,y}" (at 342 least x, at most y, occurrences), {x,} (x occurrences or more), 343 and their lazy versions; 345 the beginning-of-input ("^") and end-of-input ("$") anchors; 347 simple grouping ("(...)") and alternation ("|"). 349 Finally, implementations MUST NOT take regular expressions to be 350 anchored, neither at the beginning nor at the end. This means, for 351 instance, the pattern "es" matches "expression". 353 5. Meta-Schema 355 The current URI for the JSON Schema Validation is . 358 6. Validation Keywords 360 Validation keywords in a schema impose requirements for successful 361 validation of an instance. 363 6.1. Validation Keywords for Any Instance Type 365 6.1.1. type 367 The value of this keyword MUST be either a string or an array. If it 368 is an array, elements of the array MUST be strings and MUST be 369 unique. 371 String values MUST be one of the six primitive types ("null", 372 "boolean", "object", "array", "number", or "string"), or "integer" 373 which matches any number with a zero fractional part. 375 An instance validates if and only if the instance is in any of the 376 sets listed for this keyword. 378 6.1.2. enum 380 The value of this keyword MUST be an array. This array SHOULD have 381 at least one element. Elements in the array SHOULD be unique. 383 An instance validates successfully against this keyword if its value 384 is equal to one of the elements in this keyword's array value. 386 Elements in the array might be of any value, including null. 388 6.1.3. const 390 The value of this keyword MAY be of any type, including null. 392 An instance validates successfully against this keyword if its value 393 is equal to the value of the keyword. 395 6.2. Validation Keywords for Numeric Instances (number and integer) 397 6.2.1. multipleOf 399 The value of "multipleOf" MUST be a number, strictly greater than 0. 401 A numeric instance is valid only if division by this keyword's value 402 results in an integer. 404 6.2.2. maximum 406 The value of "maximum" MUST be a number, representing an inclusive 407 upper limit for a numeric instance. 409 If the instance is a number, then this keyword validates only if the 410 instance is less than or exactly equal to "maximum". 412 6.2.3. exclusiveMaximum 414 The value of "exclusiveMaximum" MUST be number, representing an 415 exclusive upper limit for a numeric instance. 417 If the instance is a number, then the instance is valid only if it 418 has a value strictly less than (not equal to) "exclusiveMaximum". 420 6.2.4. minimum 422 The value of "minimum" MUST be a number, representing an inclusive 423 lower limit for a numeric instance. 425 If the instance is a number, then this keyword validates only if the 426 instance is greater than or exactly equal to "minimum". 428 6.2.5. exclusiveMinimum 430 The value of "exclusiveMinimum" MUST be number, representing an 431 exclusive lower limit for a numeric instance. 433 If the instance is a number, then the instance is valid only if it 434 has a value strictly greater than (not equal to) "exclusiveMinimum". 436 6.3. Validation Keywords for Strings 438 6.3.1. maxLength 440 The value of this keyword MUST be a non-negative integer. 442 A string instance is valid against this keyword if its length is less 443 than, or equal to, the value of this keyword. 445 The length of a string instance is defined as the number of its 446 characters as defined by RFC 7159 [RFC7159]. 448 6.3.2. minLength 450 The value of this keyword MUST be a non-negative integer. 452 A string instance is valid against this keyword if its length is 453 greater than, or equal to, the value of this keyword. 455 The length of a string instance is defined as the number of its 456 characters as defined by RFC 7159 [RFC7159]. 458 Omitting this keyword has the same behavior as a value of 0. 460 6.3.3. pattern 462 The value of this keyword MUST be a string. This string SHOULD be a 463 valid regular expression, according to the ECMA 262 regular 464 expression dialect. 466 A string instance is considered valid if the regular expression 467 matches the instance successfully. Recall: regular expressions are 468 not implicitly anchored. 470 6.4. Validation Keywords for Arrays 472 6.4.1. items 474 The value of "items" MUST be either a valid JSON Schema or an array 475 of valid JSON Schemas. 477 This keyword determines how child instances validate for arrays, and 478 does not directly validate the immediate instance itself. 480 If "items" is a schema, validation succeeds if all elements in the 481 array successfully validate against that schema. 483 If "items" is an array of schemas, validation succeeds if each 484 element of the instance validates against the schema at the same 485 position, if any. 487 Omitting this keyword has the same behavior as an empty schema. 489 6.4.2. additionalItems 491 The value of "additionalItems" MUST be a valid JSON Schema. 493 This keyword determines how child instances validate for arrays, and 494 does not directly validate the immediate instance itself. 496 If "items" is an array of schemas, validation succeeds if every 497 instance element at a position greater than the size of "items" 498 validates against "additionalItems". 500 Otherwise, "additionalItems" MUST be ignored, as the "items" schema 501 (possibly the default value of an empty schema) is applied to all 502 elements. 504 Omitting this keyword has the same behavior as an empty schema. 506 6.4.3. maxItems 508 The value of this keyword MUST be a non-negative integer. 510 An array instance is valid against "maxItems" if its size is less 511 than, or equal to, the value of this keyword. 513 6.4.4. minItems 515 The value of this keyword MUST be a non-negative integer. 517 An array instance is valid against "minItems" if its size is greater 518 than, or equal to, the value of this keyword. 520 Omitting this keyword has the same behavior as a value of 0. 522 6.4.5. uniqueItems 524 The value of this keyword MUST be a boolean. 526 If this keyword has boolean value false, the instance validates 527 successfully. If it has boolean value true, the instance validates 528 successfully if all of its elements are unique. 530 Omitting this keyword has the same behavior as a value of false. 532 6.4.6. contains 534 The value of this keyword MUST be a valid JSON Schema. 536 An array instance is valid against "contains" if at least one of its 537 elements is valid against the given schema. 539 6.5. Validation Keywords for Objects 541 6.5.1. maxProperties 543 The value of this keyword MUST be a non-negative integer. 545 An object instance is valid against "maxProperties" if its number of 546 properties is less than, or equal to, the value of this keyword. 548 6.5.2. minProperties 550 The value of this keyword MUST be a non-negative integer. 552 An object instance is valid against "minProperties" if its number of 553 properties is greater than, or equal to, the value of this keyword. 555 Omitting this keyword has the same behavior as a value of 0. 557 6.5.3. required 559 The value of this keyword MUST be an array. Elements of this array, 560 if any, MUST be strings, and MUST be unique. 562 An object instance is valid against this keyword if every item in the 563 array is the name of a property in the instance. 565 Omitting this keyword has the same behavior as an empty array. 567 6.5.4. properties 569 The value of "properties" MUST be an object. Each value of this 570 object MUST be a valid JSON Schema. 572 This keyword determines how child instances validate for objects, and 573 does not directly validate the immediate instance itself. 575 Validation succeeds if, for each name that appears in both the 576 instance and as a name within this keyword's value, the child 577 instance for that name successfully validates against the 578 corresponding schema. 580 Omitting this keyword has the same behavior as an empty object. 582 6.5.5. patternProperties 584 The value of "patternProperties" MUST be an object. Each property 585 name of this object SHOULD be a valid regular expression, according 586 to the ECMA 262 regular expression dialect. Each property value of 587 this object MUST be a valid JSON Schema. 589 This keyword determines how child instances validate for objects, and 590 does not directly validate the immediate instance itself. Validation 591 of the primitive instance type against this keyword always succeeds. 593 Validation succeeds if, for each instance name that matches any 594 regular expressions that appear as a property name in this keyword's 595 value, the child instance for that name successfully validates 596 against each schema that corresponds to a matching regular 597 expression. 599 Omitting this keyword has the same behavior as an empty object. 601 6.5.6. additionalProperties 603 The value of "additionalProperties" MUST be a valid JSON Schema. 605 This keyword determines how child instances validate for objects, and 606 does not directly validate the immediate instance itself. 608 Validation with "additionalProperties" applies only to the child 609 values of instance names that do not match any names in "properties", 610 and do not match any regular expression in "patternProperties". 612 For all such properties, validation succeeds if the child instance 613 validates against the "additionalProperties" schema. 615 Omitting this keyword has the same behavior as an empty schema. 617 6.5.7. dependencies 619 [[CREF1: Now that "if", "then", and "else" are keywords, it is not 620 clear whether there is any benefit in keeping the schema form of 621 "dependencies". It is frequently misunderstood, and having a form 622 that takes a subschema as well as a form that takes a primitive value 623 is particularly confusing. And it seems to be rarely used. 624 Depending on feedback with "if", "then", and "else", the schema form 625 of this keyword may well be removed in a future draft. Current 626 thought is that the string form (giving property names in an array) 627 is a useful shortcut. ]] 629 This keyword specifies rules that are evaluated if the instance is an 630 object and contains a certain property. 632 This keyword's value MUST be an object. Each property specifies a 633 dependency. Each dependency value MUST be an array or a valid JSON 634 Schema. 636 If the dependency value is a subschema, and the dependency key is a 637 property in the instance, the entire instance must validate against 638 the dependency value. 640 If the dependency value is an array, each element in the array, if 641 any, MUST be a string, and MUST be unique. If the dependency key is 642 a property in the instance, each of the items in the dependency value 643 must be a property that exists in the instance. 645 Omitting this keyword has the same behavior as an empty object. 647 6.5.8. propertyNames 649 The value of "propertyNames" MUST be a valid JSON Schema. 651 If the instance is an object, this keyword validates if every 652 property name in the instance validates against the provided schema. 653 Note the property name that the schema is testing will always be a 654 string. 656 Omitting this keyword has the same behavior as an empty schema. 658 6.6. Keywords for Applying Subschemas Conditionally 660 These keywords work together to implement conditional application of 661 a subschema based on the outcome of another subschema. 663 These keywords MUST NOT interact with each other across subschema 664 boundaries. In other words, an "if" in one branch of an "allOf" MUST 665 NOT have an impact on a "then" or "else" in another branch. 667 6.6.1. if 669 This keyword's value MUST be a valid JSON Schema. 671 Instances that successfully validate against this keyword's subschema 672 MUST also be valid against the subschema value of the "then" keyword, 673 if present. 675 Instances that fail to validate against this keyword's subschema MUST 676 also be valid against the subschema value of the "else" keyword. 678 Validation of the instance against this keyword on its own always 679 succeeds, regardless of the validation outcome of against its 680 subschema. 682 6.6.2. then 684 This keyword's value MUST be a valid JSON Schema. 686 When present alongside of "if", the instance successfully validates 687 against this keyword if it validates against both the "if"'s 688 subschema and this keyword's subschema. 690 When "if" is absent, or the instance fails to validate against its 691 subschema, validation against this keyword always succeeds. 692 Implementations SHOULD avoid attempting to validate against the 693 subschema in these cases. 695 6.6.3. else 697 This keyword's value MUST be a valid JSON Schema. 699 When present alongside of "if", the instance successfully validates 700 against this keyword if it fails to validate against the "if"'s 701 subschema, and successfully validates against this keyword's 702 subschema. 704 When "if" is absent, or the instance successfully validates against 705 its subschema, validation against this keyword always succeeds. 707 Implementations SHOULD avoid attempting to validate against the 708 subschema in these cases. 710 6.7. Keywords for Applying Subschemas With Boolean Logic 712 6.7.1. allOf 714 This keyword's value MUST be a non-empty array. Each item of the 715 array MUST be a valid JSON Schema. 717 An instance validates successfully against this keyword if it 718 validates successfully against all schemas defined by this keyword's 719 value. 721 6.7.2. anyOf 723 This keyword's value MUST be a non-empty array. Each item of the 724 array MUST be a valid JSON Schema. 726 An instance validates successfully against this keyword if it 727 validates successfully against at least one schema defined by this 728 keyword's value. 730 6.7.3. oneOf 732 This keyword's value MUST be a non-empty array. Each item of the 733 array MUST be a valid JSON Schema. 735 An instance validates successfully against this keyword if it 736 validates successfully against exactly one schema defined by this 737 keyword's value. 739 6.7.4. not 741 This keyword's value MUST be a valid JSON Schema. 743 An instance is valid against this keyword if it fails to validate 744 successfully against the schema defined by this keyword. 746 7. Semantic Validation With "format" 748 7.1. Foreword 750 Structural validation alone may be insufficient to validate that an 751 instance meets all the requirements of an application. The "format" 752 keyword is defined to allow interoperable semantic validation for a 753 fixed subset of values which are accurately described by 754 authoritative resources, be they RFCs or other external 755 specifications. 757 The value of this keyword is called a format attribute. It MUST be a 758 string. A format attribute can generally only validate a given set 759 of instance types. If the type of the instance to validate is not in 760 this set, validation for this format attribute and instance SHOULD 761 succeed. 763 7.2. Implementation Requirements 765 The "format" keyword functions as both an annotation (Section 3.3) 766 and as an assertion (Section 3.2). While no special effort is 767 required to implement it as an annotation conveying semantic meaning, 768 implementing validation is non-trivial. 770 Implementations MAY support the "format" keyword as a validation 771 assertion. Should they choose to do so: 773 they SHOULD implement validation for attributes defined below; 775 they SHOULD offer an option to disable validation for this 776 keyword. 778 Implementations MAY add custom format attributes. Save for agreement 779 between parties, schema authors SHALL NOT expect a peer 780 implementation to support this keyword and/or custom format 781 attributes. 783 7.3. Defined Formats 785 7.3.1. Dates and Times 787 These attributes apply to string instances. 789 Date and time format names are derived from RFC 3339, section 5.6 790 [RFC3339]. 792 Implementations supporting formats SHOULD implement support for the 793 following attributes: 795 date-time A string instance is valid against this attribute if it is 796 a valid representation according to the "date-time" production. 798 date A string instance is valid against this attribute if it is a 799 valid representation according to the "full-date" production. 801 time A string instance is valid against this attribute if it is a 802 valid representation according to the "full-time" production. 804 Implementations MAY support additional attributes using the other 805 production names defined in that section. If "full-date" or "full- 806 time" are implemented, the corresponding short form ("date" or "time" 807 respectively) MUST be implemented, and MUST behave identically. 808 Implementations SHOULD NOT define extension attributes with any name 809 matching an RFC 3339 production unless it validates according to the 810 rules of that production. [[CREF2: There is not currently consensus 811 on the need for supporting all RFC 3339 formats, so this approach of 812 reserving the namespace will encourage experimentation without 813 committing to the entire set. Either the format implementation 814 requirements will become more flexible in general, or these will 815 likely either be promoted to fully specified attributes or dropped. 816 ]] 818 7.3.2. Email Addresses 820 These attributes apply to string instances. 822 A string instance is valid against these attributes if it is a valid 823 Internet email address as follows: 825 email As defined by RFC 5322, section 3.4.1 [RFC5322]. 827 idn-email As defined by RFC 6531 [RFC6531] 829 Note that all strings valid against the "email" attribute are also 830 valid against the "idn-email" attribute. 832 7.3.3. Hostnames 834 These attributes apply to string instances. 836 A string instance is valid against these attributes if it is a valid 837 representation for an Internet hostname as follows: 839 hostname As defined by RFC 1034, section 3.1 [RFC1034], including 840 host names produced using the Punycode algorithm specified in RFC 841 5891, section 4.4 [RFC5891]. 843 idn-hostname As defined by either RFC 1034 as for hostname, or an 844 internationalized hostname as defined by RFC 5890, section 2.3.2.3 845 [RFC5890]. 847 Note that all strings valid against the "hostname" attribute are also 848 valid against the "idn-hostname" attribute. 850 7.3.4. IP Addresses 852 These attributes apply to string instances. 854 A string instance is valid against these attributes if it is a valid 855 representation of an IP address as follows: 857 ipv4 An IPv4 address according to the "dotted-quad" ABNF syntax as 858 defined in RFC 2673, section 3.2 [RFC2673]. 860 ipv6 An IPv6 address as defined in RFC 4291, section 2.2 [RFC4291]. 862 7.3.5. Resource Identifiers 864 These attributes apply to string instances. 866 uri A string instance is valid against this attribute if it is a 867 valid URI, according to [RFC3986]. 869 uri-reference A string instance is valid against this attribute if 870 it is a valid URI Reference (either a URI or a relative- 871 reference), according to [RFC3986]. 873 iri A string instance is valid against this attribute if it is a 874 valid IRI, according to [RFC3987]. 876 iri-reference A string instance is valid against this attribute if 877 it is a valid IRI Reference (either an IRI or a relative- 878 reference), according to [RFC3987]. 880 Note that all valid URIs are valid IRIs, and all valid URI References 881 are also valid IRI References. 883 7.3.6. uri-template 885 This attribute applies to string instances. 887 A string instance is valid against this attribute if it is a valid 888 URI Template (of any level), according to [RFC6570]. 890 Note that URI Templates may be used for IRIs; there is no separate 891 IRI Template specification. 893 7.3.7. JSON Pointers 895 These attributes apply to string instances. 897 json-pointer A string instance is valid against this attribute if it 898 is a valid JSON string representation of a JSON Pointer, according 899 to RFC 6901, section 5 [RFC6901]. 901 relative-json-pointer A string instance is valid against this 902 attribute if it is a valid Relative JSON Pointer 903 [relative-json-pointer]. 905 To allow for both absolute and relative JSON Pointers, use "anyOf" or 906 "oneOf" to indicate support for either format. 908 7.3.8. regex 910 This attribute applies to string instances. 912 A regular expression, which SHOULD be valid according to the ECMA 262 913 [ecma262] regular expression dialect. 915 Implementations that validate formats MUST accept at least the subset 916 of ECMA 262 defined in the Regular Expressions (Section 4.3) section 917 of this specification, and SHOULD accept all valid ECMA 262 918 expressions. 920 8. String-Encoding Non-JSON Data 922 8.1. Foreword 924 Properties defined in this section indicate that an instance contains 925 non-JSON data encoded in a JSON string. They describe the type of 926 content and how it is encoded. 928 These properties provide additional information required to interpret 929 JSON data as rich multimedia documents. 931 8.2. Implementation Requirements 933 The content keywords function as both annotations (Section 3.3) and 934 as assertions (Section 3.2). While no special effort is required to 935 implement them as annotations conveying how applications can 936 interpret the data in the string, implementing validation of 937 conformance to the media type and encoding is non-trivial. 939 Implementations MAY support the "contentMediaType" and 940 "contentEncoding" keywords as validation assertions. Should they 941 choose to do so, they SHOULD offer an option to disable validation 942 for these keywords. 944 8.3. contentEncoding 946 If the instance value is a string, this property defines that the 947 string SHOULD be interpreted as binary data and decoded using the 948 encoding named by this property. RFC 2045, Sec 6.1 [RFC2045] lists 949 the possible values for this property. 951 The value of this property MUST be a string. 953 The value of this property SHOULD be ignored if the instance 954 described is not a string. 956 8.4. contentMediaType 958 The value of this property must be a media type, as defined by RFC 959 2046 [RFC2046]. This property defines the media type of instances 960 which this schema defines. 962 The value of this property MUST be a string. 964 The value of this property SHOULD be ignored if the instance 965 described is not a string. 967 If the "contentEncoding" property is not present, but the instance 968 value is a string, then the value of this property SHOULD specify a 969 text document type, and the character set SHOULD be the character set 970 into which the JSON string value was decoded (for which the default 971 is Unicode). 973 8.5. Example 975 Here is an example schema, illustrating the use of "contentEncoding" 976 and "contentMediaType": 978 { 979 "type": "string", 980 "contentEncoding": "base64", 981 "contentMediaType": "image/png" 982 } 984 Instances described by this schema should be strings, and their 985 values should be interpretable as base64-encoded PNG images. 987 Another example: 989 { 990 "type": "string", 991 "contentMediaType": "text/html" 992 } 994 Instances described by this schema should be strings containing HTML, 995 using whatever character set the JSON string was decoded into 996 (default is Unicode). 998 9. Schema Re-Use With "definitions" 1000 The "definitions" keywords provides a standardized location for 1001 schema authors to inline re-usable JSON Schemas into a more general 1002 schema. The keyword does not directly affect the validation result. 1004 This keyword's value MUST be an object. Each member value of this 1005 object MUST be a valid JSON Schema. 1007 As an example, here is a schema describing an array of positive 1008 integers, where the positive integer constraint is a subschema in 1009 "definitions": 1011 { 1012 "type": "array", 1013 "items": { "$ref": "#/definitions/positiveInteger" }, 1014 "definitions": { 1015 "positiveInteger": { 1016 "type": "integer", 1017 "exclusiveMinimum": 0 1018 } 1019 } 1020 } 1022 10. Schema Annotations 1024 Schema validation is a useful mechanism for annotating instance data 1025 with additional information. The rules for determining when and how 1026 annotations are associated with an instance are outlined in this 1027 specification's overview. 1029 These general-purpose annotation keywords provide commonly used 1030 information for documentation and user interface display purposes. 1032 They are not intended to form a comprehensive set of features. 1033 Rather, additional vocabularies can be defined for more complex 1034 annotation-based applications. 1036 10.1. "title" and "description" 1038 The value of both of these keywords MUST be a string. 1040 Both of these keywords can be used to decorate a user interface with 1041 information about the data produced by this user interface. A title 1042 will preferably be short, whereas a description will provide 1043 explanation about the purpose of the instance described by this 1044 schema. 1046 10.2. "default" 1048 There are no restrictions placed on the value of this keyword. When 1049 multiple occurrences of this keyword are applicable to a single sub- 1050 instance, implementations SHOULD remove duplicates. 1052 This keyword can be used to supply a default JSON value associated 1053 with a particular schema. It is RECOMMENDED that a default value be 1054 valid against the associated schema. 1056 10.3. "readOnly" and "writeOnly" 1058 The value of these keywords MUST be a boolean. When multiple 1059 occurrences of these keywords are applicable to a single sub- 1060 instance, the resulting value MUST be true if any occurrence 1061 specifies a true value, and MUST be false otherwise. 1063 If "readOnly" has a value of boolean true, it indicates that the 1064 value of the instance is managed exclusively by the owning authority, 1065 and attempts by an application to modify the value of this property 1066 are expected to be ignored or rejected by that owning authority. 1068 An instance document that is marked as "readOnly for the entire 1069 document MAY be ignored if sent to the owning authority, or MAY 1070 result in an error, at the authority's discretion. 1072 If "writeOnly" has a value of boolean true, it indicates that the 1073 value is never present when the instance is retrieved from the owning 1074 authority. It can be present when sent to the owning authority to 1075 update or create the document (or the resource it represents), but it 1076 will not be included in any updated or newly created version of the 1077 instance. 1079 An instance document that is marked as "writeOnly" for the entire 1080 document MAY be returned as a blank document of some sort, or MAY 1081 produce an error upon retrieval, or have the retrieval request 1082 ignored, at the authority's discretion. 1084 For example, "readOnly" would be used to mark a database-generated 1085 serial number as read-only, while "writeOnly" would be used to mark a 1086 password input field. 1088 These keywords can be used to assist in user interface instance 1089 generation. In particular, an application MAY choose to use a widget 1090 that hides input values as they are typed for write-only fields. 1092 Omitting these keywords has the same behavior as values of false. 1094 10.4. "examples" 1096 The value of this keyword MUST be an array. There are no 1097 restrictions placed on the values within the array. When multiple 1098 occurrences of this keyword are applicable to a single sub-instance, 1099 implementations MUST provide a flat array of all values rather than 1100 an array of arrays. 1102 This keyword can be used to provide sample JSON values associated 1103 with a particular schema, for the purpose of illustrating usage. It 1104 is RECOMMENDED that these values be valid against the associated 1105 schema. 1107 Implementations MAY use the value(s) of "default", if present, as an 1108 additional example. If "examples" is absent, "default" MAY still be 1109 used in this manner. 1111 11. Security Considerations 1113 JSON Schema validation defines a vocabulary for JSON Schema core and 1114 concerns all the security considerations listed there. 1116 JSON Schema validation allows the use of Regular Expressions, which 1117 have numerous different (often incompatible) implementations. Some 1118 implementations allow the embedding of arbitrary code, which is 1119 outside the scope of JSON Schema and MUST NOT be permitted. Regular 1120 expressions can often also be crafted to be extremely expensive to 1121 compute (with so-called "catastrophic backtracking"), resulting in a 1122 denial-of-service attack. 1124 Implementations that support validating or otherwise evaluating 1125 instance string data based on "contentEncoding" and/or 1126 "contentMediaType" are at risk of evaluating data in an unsafe way 1127 based on misleading information. Applications can mitigate this risk 1128 by only performing such processing when a relationship between the 1129 schema and instance is established (e.g., they share the same 1130 authority). 1132 Processing a media type or encoding is subject to the security 1133 considerations of that media type or encoding. For example, the 1134 security considerations of RFC 4329 Scripting Media Types [RFC4329] 1135 apply when processing JavaScript or ECMAScript encoded within a JSON 1136 string. 1138 12. References 1140 12.1. Normative References 1142 [ecma262] "ECMA 262 specification", . 1146 [json-schema] 1147 Wright, A. and H. Andrews, "JSON Schema: A Media Type for 1148 Describing JSON Documents", draft-handrews-json-schema-00 1149 (work in progress), November 2017. 1151 [relative-json-pointer] 1152 Luff, G. and H. Andrews, "Relative JSON Pointers", draft- 1153 handrews-relative-json-pointer-00 (work in progress), 1154 November 2017. 1156 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1157 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1158 . 1160 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1161 Extensions (MIME) Part One: Format of Internet Message 1162 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 1163 . 1165 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1166 Extensions (MIME) Part Two: Media Types", RFC 2046, 1167 DOI 10.17487/RFC2046, November 1996, 1168 . 1170 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1171 Requirement Levels", BCP 14, RFC 2119, 1172 DOI 10.17487/RFC2119, March 1997, 1173 . 1175 [RFC2673] Crawford, M., "Binary Labels in the Domain Name System", 1176 RFC 2673, DOI 10.17487/RFC2673, August 1999, 1177 . 1179 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1180 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 1181 . 1183 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1184 Resource Identifier (URI): Generic Syntax", STD 66, 1185 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1186 . 1188 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 1189 Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, 1190 January 2005, . 1192 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1193 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1194 2006, . 1196 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1197 DOI 10.17487/RFC5322, October 2008, 1198 . 1200 [RFC5890] Klensin, J., "Internationalized Domain Names for 1201 Applications (IDNA): Definitions and Document Framework", 1202 RFC 5890, DOI 10.17487/RFC5890, August 2010, 1203 . 1205 [RFC5891] Klensin, J., "Internationalized Domain Names in 1206 Applications (IDNA): Protocol", RFC 5891, 1207 DOI 10.17487/RFC5891, August 2010, 1208 . 1210 [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized 1211 Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, 1212 . 1214 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 1215 and D. Orchard, "URI Template", RFC 6570, 1216 DOI 10.17487/RFC6570, March 2012, 1217 . 1219 [RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., 1220 "JavaScript Object Notation (JSON) Pointer", RFC 6901, 1221 DOI 10.17487/RFC6901, April 2013, 1222 . 1224 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1225 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1226 2014, . 1228 12.2. Informative References 1230 [RFC4329] Hoehrmann, B., "Scripting Media Types", RFC 4329, 1231 DOI 10.17487/RFC4329, April 2006, 1232 . 1234 Appendix A. Acknowledgments 1236 Thanks to Gary Court, Francis Galiegue, Kris Zyp, and Geraint Luff 1237 for their work on the initial drafts of JSON Schema. 1239 Thanks to Jason Desrosiers, Daniel Perrett, Erik Wilde, Ben Hutton, 1240 Evgeny Poberezkin, Brad Bowman, Gowry Sankar, Donald Pipowitch, Dave 1241 Finlay, and Denis Laxalde for their submissions and patches to the 1242 document. 1244 Appendix B. ChangeLog 1246 [[CREF3: This section to be removed before leaving Internet-Draft 1247 status.]] 1249 draft-handrews-json-schema-validation-00 1251 * Added "if"/"then"/"else" 1253 * Classify keywords as assertions or annotations per the core 1254 spec 1256 * Warn of possibly removing "dependencies" in the future 1258 * Grouped validation keywords into sub-sections for readability 1260 * Moved "readOnly" from hyper-schema to validation meta-data 1262 * Added "writeOnly" 1264 * Added string-encoded media section, with former hyper-schema 1265 "media" keywords 1267 * Restored "regex" format (removal was unintentional) 1269 * Added "date" and "time" formats, and reserved additional RFC 1270 3339 format names 1272 * I18N formats: "iri", "iri-reference", "idn-hostname", "idn- 1273 email" 1275 * Clarify that "json-pointer" format means string encoding, not 1276 URI fragment 1278 * Fixed typo that inverted the meaning of "minimum" and 1279 "exclusiveMinimum" 1281 * Move format syntax references into Normative References 1282 * JSON is a normative requirement 1284 draft-wright-json-schema-validation-01 1286 * Standardized on hyphenated format names ("uriref" becomes "uri- 1287 ref") 1289 * Add the formats "uri-template" and "json-pointer" 1291 * Changed "exclusiveMaximum"/"exclusiveMinimum" from boolean 1292 modifiers of "maximum"/"minimum" to independent numeric fields. 1294 * Split the additionalItems/items into two sections 1296 * Reworked properties/patternProperties/additionalProperties 1297 definition 1299 * Added "examples" keyword 1301 * Added "contains" keyword 1303 * Allow empty "required" and "dependencies" arrays 1305 * Fixed "type" reference to primitive types 1307 * Added "const" keyword 1309 * Added "propertyNames" keyword 1311 draft-wright-json-schema-validation-00 1313 * Added additional security considerations 1315 * Removed reference to "latest version" meta-schema, use numbered 1316 version instead 1318 * Rephrased many keyword definitions for brevity 1320 * Added "uriref" format that also allows relative URI references 1322 draft-fge-json-schema-validation-01 1324 * Initial draft. 1326 * Salvaged from draft v3. 1328 * Redefine the "required" keyword. 1330 * Remove "extends", "disallow" 1332 * Add "anyOf", "allOf", "oneOf", "not", "definitions", 1333 "minProperties", "maxProperties". 1335 * "dependencies" member values can no longer be single strings; 1336 at least one element is required in a property dependency 1337 array. 1339 * Rename "divisibleBy" to "multipleOf". 1341 * "type" arrays can no longer have schemas; remove "any" as a 1342 possible value. 1344 * Rework the "format" section; make support optional. 1346 * "format": remove attributes "phone", "style", "color"; rename 1347 "ip-address" to "ipv4"; add references for all attributes. 1349 * Provide algorithms to calculate schema(s) for array/object 1350 instances. 1352 * Add interoperability considerations. 1354 Authors' Addresses 1356 Austin Wright (editor) 1358 EMail: aaa@bzfx.net 1360 Henry Andrews (editor) 1361 Cloudflare, Inc. 1362 San Francisco, CA 1363 USA 1365 EMail: henry@cloudflare.com 1367 Geraint Luff 1368 Cambridge 1369 UK 1371 EMail: luffgd@gmail.com