idnits 2.17.1 draft-ietf-httpapi-rest-api-mediatypes-01.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (7 March 2022) is 774 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 657 -- Looks like a reference, but probably isn't: '1' on line 657 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPAPI R. Polli 3 Internet-Draft Digital Transformation Department, Italian Government 4 Intended status: Informational 7 March 2022 5 Expires: 8 September 2022 7 REST API Media Types 8 draft-ietf-httpapi-rest-api-mediatypes-01 10 Abstract 12 This document registers the following media types used in APIs on the 13 IANA Media Types registry: application/yaml, application/schema+json, 14 application/schema-instance+json, application/openapi+json, and 15 application/openapi+yaml. 17 Note to Readers 19 _RFC EDITOR: please remove this section before publication_ 21 Discussion of this draft takes place on the HTTP APIs working group 22 mailing list (httpapi@ietf.org), which is archived at 23 https://mailarchive.ietf.org/arch/browse/httpapi/ 24 (https://mailarchive.ietf.org/arch/browse/httpapi/). 26 The source code and issues list for this draft can be found at 27 https://github.com/ietf-wg-httpapi/mediatypes (https://github.com/ 28 ietf-wg-httpapi/mediatypes). 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 8 September 2022. 47 Copyright Notice 49 Copyright (c) 2022 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 (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Revised BSD License text as 58 described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Revised BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 65 2. Media Type registrations . . . . . . . . . . . . . . . . . . 3 66 2.1. Media Type application/yaml . . . . . . . . . . . . . . . 3 67 2.2. The +yaml Structured Syntax Suffix . . . . . . . . . . . 4 68 2.3. The OpenAPI Media Types . . . . . . . . . . . . . . . . . 5 69 2.3.1. Media Type application/openapi+json . . . . . . . . . 6 70 2.3.2. Media Type application/openapi+yaml . . . . . . . . . 7 71 2.4. JSON Schema Media Types . . . . . . . . . . . . . . . . . 8 72 2.4.1. The "$schema" Keyword . . . . . . . . . . . . . . . . 8 73 2.4.2. Identifying a Schema via a Media Type Parameter . . . 9 74 2.4.3. Linking to a Schema . . . . . . . . . . . . . . . . . 10 75 2.4.4. Fragment Identifiers . . . . . . . . . . . . . . . . 10 76 2.4.5. Media Type application/schema+json . . . . . . . . . 11 77 2.4.6. Media Type application/schema-instance+json . . . . . 12 78 3. Interoperability Considerations . . . . . . . . . . . . . . . 13 79 3.1. YAML Media Types . . . . . . . . . . . . . . . . . . . . 13 80 3.1.1. YAML is an Evolving Language . . . . . . . . . . . . 13 81 3.1.2. YAML and JSON . . . . . . . . . . . . . . . . . . . . 13 82 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 83 4.1. YAML Media Types . . . . . . . . . . . . . . . . . . . . 15 84 4.1.1. Arbitrary Code Execution . . . . . . . . . . . . . . 15 85 4.1.2. Resource exhaustion . . . . . . . . . . . . . . . . . 15 86 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 87 6. Normative References . . . . . . . . . . . . . . . . . . . . 16 88 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18 89 FAQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 93 1. Introduction 95 OpenAPI Specification [oas] version 3 and above is a consolidated 96 standard for describing HTTP APIs using the JSON [JSON] and YAML 97 [YAML] data format. 99 To increase interoperability when processing API specifications and 100 leverage content negotiation mechanisms when exchanging OpenAPI 101 Specification resources this specification register the following 102 media-types: application/yaml, application/schema+json, application/ 103 schema-instance+json, application/openapi+json and application/ 104 openapi+yaml. 106 Moreover it defines and registers the +yaml structured syntax suffix. 108 1.1. Notational Conventions 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in 113 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 114 capitals, as shown here. These words may also appear in this 115 document in lower case as plain English words, absent their normative 116 meanings. 118 This document uses the Augmented BNF defined in [RFC5234] and updated 119 by [RFC7405]. 121 The terms "content", "content negotiation", "resource", and "user 122 agent" in this document are to be interpreted as in [SEMANTICS]. 124 2. Media Type registrations 126 This section describes the information required to register the above 127 media types according to [MEDIATYPE] 129 2.1. Media Type application/yaml 131 The following information serves as the registration form for the 132 application/yaml media type. 134 Type name: application 136 Subtype name: yaml 138 Required parameters: None 140 Optional parameters: None; unrecognized parameters should be ignored 141 Encoding considerations: Same as [JSON] 143 Security considerations: see Section 4 of this document 145 Interoperability considerations: see Section 3.1 of this document 147 Published specification: (this document) 149 Applications that use this media type: HTTP 151 Fragment identifier considerations: Same as for application/json 152 [JSON] 154 Additional information: 156 Deprecated alias names for this type: application/x-yaml, text/yaml, 157 text/x-yaml 159 Magic number(s): n/a 161 File extension(s): yaml, yml 163 Macintosh file type code(s): n/a 165 Person and email address to contact for further information: See 166 Authors' Addresses section. 168 Intended usage: COMMON 170 Restrictions on usage: None. 172 Author: See Authors' Addresses section. 174 Change controller: n/a 176 2.2. The +yaml Structured Syntax Suffix 178 The suffix +yaml MAY be used with any media type whose representation 179 follows that established for application/yaml. The media type 180 structured syntax suffix registration form follows. See [MEDIATYPE] 181 for definitions of each of the registration form headings. 183 Name: YAML Ain't Markup LanguageML (YAML) 185 +suffix: +yaml 187 References: [YAML] 188 Encoding considerations: see Section 2.1 190 Fragment identifier considerations: 192 The syntax and semantics of fragment identifiers specified for 193 +yaml SHOULD be as specified for {{application-yaml}} 195 The syntax and semantics for fragment identifiers for a specific 196 `xxx/yyy+json` SHOULD be processed as follows: 198 For cases defined in +yaml, where the fragment identifier resolves 199 per the +yaml rules, then process as specified in +yaml. 201 For cases defined in +yaml, where the fragment identifier does 202 not resolve per the +yaml rules, then process as specified in 203 `xxx/yyy+yaml`. 205 For cases not defined in +yaml, then process as specified in 206 `xxx/yyy+yaml`. 208 Interoperability considerations: See Section 2.1 210 Security considerations: See Section 2.1 212 Contact: See Authors' Addresses section. 214 Author: See Authors' Addresses section 216 Change controller: n/a 218 2.3. The OpenAPI Media Types 220 The OpenAPI Specification Media Types convey OpenAPI document (OAS) 221 files as defined in [oas] for version 3.0.0 and above. 223 Those files can be serialized in [JSON] or [YAML]. Since there are 224 multiple OpenAPI Specification versions, those media-types support 225 the version parameter. 227 The following examples conveys the desire of a client to receive an 228 OpenAPI Specification resource preferably in the following order: 230 1. openapi 3.1 in YAML 232 2. openapi 3.0 in YAML 234 3. any openapi version in json 235 Accept: application/openapi+yaml;version=3.1, 236 application/openapi+yaml;version=3.0;q=0.5, 237 application/openapi+json;q=0.3 239 2.3.1. Media Type application/openapi+json 241 The following information serves as the registration form for the 242 application/openapi+json media type. 244 Type name: application 246 Subtype name: openapi+json 248 Required parameters: None 250 Optional parameters: version; unrecognized parameters should be 251 ignored 253 Encoding considerations: Same as [JSON] 255 Security considerations: see Section 4 of this document 257 Interoperability considerations: None 259 Published specification: (this document) 261 Applications that use this media type: HTTP 263 Fragment identifier considerations: Same as for application/json 264 [JSON] 266 Additional information: 268 Deprecated alias names for this type: n/a 270 Magic number(s): n/a 272 File extension(s): json 274 Macintosh file type code(s): n/a 276 Person and email address to contact for further information: See 277 Authors' Addresses section. 279 Intended usage: COMMON 281 Restrictions on usage: None. 283 Author: See Authors' Addresses section. 285 Change controller: n/a 287 2.3.2. Media Type application/openapi+yaml 289 The following information serves as the registration form for the 290 application/openapi+yaml media type. 292 Type name: application 294 Subtype name: openapi+yaml 296 Required parameters: None 298 Optional parameters: version; unrecognized parameters should be 299 ignored 301 Encoding considerations: Same as [JSON] 303 Security considerations: see Section 4 of this document 305 Interoperability considerations: see Section 2.1 307 Published specification: (this document) 309 Applications that use this media type: HTTP 311 Fragment identifier considerations: Same as for application/json 312 [JSON] 314 Additional information: 316 Deprecated alias names for this type: n/a 318 Magic number(s): n/a 320 File extension(s): yaml, yml 322 Macintosh file type code(s): n/a 324 Person and email address to contact for further information: See 325 Authors' Addresses section 327 Intended usage: COMMON 329 Restrictions on usage: None. 331 Author: See Authors' Addresses section 333 Change controller: n/a 335 2.4. JSON Schema Media Types 337 JSON Schema is a declarative domain-specific language for validating 338 and annotating JSON documents (see [jsonschema]). 340 This document registers the media types associated with JSON Schema. 342 There are many dialects of JSON Schema in wide use today. The JSON 343 Schema maintainers have released several dialects including draft-04, 344 draft-07, and draft 2020-12. There are also several third-party JSON 345 Schema dialects in wide use including the ones defined for use in 346 OpenAPI and MongoDB. 348 This specification defines little more than how to identify the 349 dialect while leaving most of the semantics of the schema up to the 350 dialect to define. Clients MUST use the following order of 351 precedence for determining the dialect of a schema. 353 * The $schema keyword (Section 2.4.1) 355 * The "schema" media type parameter (Section 2.4.2) 357 * The context of the enclosing document. This applies only when a 358 schema is embedded within a document. The enclosing document 359 could be another schema in the case of a bundled schema or it 360 could be another type of document that includes schemas such as an 361 OpenAPI document. 363 * If none of the above result in identifying the dialect, client 364 behavior is undefined. 366 2.4.1. The "$schema" Keyword 368 The $schema keyword is used as a JSON Schema dialect identifier. The 369 value of this keyword MUST be a URI [RFC3986]. This URI SHOULD 370 identify a meta-schema that can be used to validate that the schema 371 is syntactically correct according to the dialect the URI identifies. 373 The dialect SHOULD define where the $schema keyword is allowed and/or 374 recognized in a schema, but it is RECOMMENDED that dialects do not 375 allow the schema to change within the same Schema Resource. 377 2.4.2. Identifying a Schema via a Media Type Parameter 379 Media types MAY allow for a schema media type parameter, to support 380 content negotiation based on schema identifier (see Section 12 of 381 [SEMANTICS]). The schema media type parameter MUST be a URI- 382 reference [RFC3986]. 384 The schema parameter identifies a schema that provides semantic 385 information about the resource the media type represents. When using 386 the application/schema+json media type, the schema parameter 387 identifies the dialect of the schema the media type represents. 389 The schema URI is opaque and SHOULD NOT automatically be 390 dereferenced. Since schema doesn't necessarily point to a network 391 location, the "describedby" relation is used for linking to a 392 downloadable schema. 394 The following is an example of content negotiation where a user agent 395 can accept two different versions of a "pet" resource. Each resource 396 version is identified by a unique JSON Schema. 398 Request: 400 NOTE: '\' line wrapping per RFC 8792 402 GET /pet/1234 HTTP/1.1 403 Host: foo.example 404 Accept: \ 405 application/schema-instance+json; schema="/schemas/v2/pet"; q=0.2, \ 406 application/schema-instance+json; schema="/schemas/v1/pet"; q=0.1 408 Response: 410 NOTE: '\' line wrapping per RFC 8792 412 HTTP/1.1 200 Ok 413 Content-Type: \ 414 application/schema-instance+json; schema="/schemas/v2/pet" 416 { 417 "petId": "1234", 418 "name": "Pluto", 419 ... 420 } 422 In the following example, the user agent is able to accept two 423 possible dialects of JSON Schema and the server replies with the 424 latest one. 426 Request: 428 NOTE: '\' line wrapping per RFC 8792 430 GET /schemas/v2/pet HTTP/1.1 431 Host: foo.example 432 Accept: application/schema+json; \ 433 schema="https://json-schema.org/draft/2020-12/schema", \ 434 application/schema+json; \ 435 schema="http://json-schema.org/draft-07/schema#" 437 Response: 439 NOTE: '\' line wrapping per RFC 8792 441 HTTP/1.1 200 OK 442 Content-Type: \ 443 application/schema+json; \ 444 schema="https://json-schema.org/draft/2020-12/schema" 446 { 447 "$id": "https://json-schema.org/draft/2020-12/schema", 448 "$schema": "https://json-schema.org/draft/2020-12/schema", 449 ... 450 } 452 2.4.3. Linking to a Schema 454 It is RECOMMENDED that instances described by a schema provide a link 455 to a downloadable JSON Schema using the link relation describedby, as 456 defined by Linked Data Protocol 1.0, section 8.1 457 [W3C.REC-ldp-20150226]. 459 In HTTP, such links can be attached to any response using the Link 460 header [LINK]. 462 Link: ; rel="describedby" 464 2.4.4. Fragment Identifiers 466 Two fragment identifier structures are supported: JSON Pointers and 467 plain-names. 469 The use of JSON Pointers as URI fragment identifiers is described in 470 [RFC6901]. Fragment identifiers that are empty or start with a /, 471 MUST be interpreted as JSON Pointer fragment identifiers. 473 Plain-name fragment identifiers reference locally named locations in 474 the document. The dialect determines how plain-name identifiers map 475 to locations within the document. All fragment identifiers that do 476 not match the JSON Pointer syntax MUST be interpreted as plain name 477 fragment identifiers. 479 2.4.5. Media Type application/schema+json 481 The application/schema+json media type represents JSON Schema. This 482 schema can be an official dialect or a third-party dialect. The 483 following information serves as the registration form for the 484 application/schema+json media type. 486 *Type name*: application 488 *Subtype name*: schema+json 490 *Required parameters*: N/A 492 *Optional parameters*: 494 * *schema*: A URI identifying the JSON Schema dialect the schema was 495 written for. If this value conflicts with the value of the 496 $schema keyword in the schema, the $schema keyword takes 497 precedence. 499 *Encoding considerations*: Same as [JSON] 501 *Security considerations*: See the "Security Considerations" section 502 of [jsonschema] 504 *Interoperability considerations*: See the "General Considerations" 505 section of [jsonschema] 507 *Published specification*: (this document) 509 *Applications that use this media type*: JSON Schema is used in a 510 variety of applications including API servers and clients that 511 validate JSON requests and responses, IDEs that valid configuration 512 files, databases that store JSON, and more. 514 *Fragment identifier considerations*: See Section 2.4.4 516 *Additional information*: 518 * *Deprecated alias names for this type*: N/A 520 * *Magic number(s)*: N/A 521 * *File extension(s)*: json, schema.json 523 * *Macintosh file type code(s)*: N/A 525 *Person and email address to contact for further information*: See 526 Authors' Addresses section. 528 *Intended usage*: COMMON 530 *Restrictions on usage*: N/A. 532 *Author*: See Authors' Addresses section. 534 *Change controller*: N/A 536 2.4.6. Media Type application/schema-instance+json 538 The application/schema-instance+json media type is an extension of 539 the [JSON] media type that just adds the schema media type parameter 540 and fragment identification. The following information serves as the 541 registration form for the application/schema-instance+json media 542 type. 544 *Type name*: application 546 *Subtype name*: schema-instance+json 548 *Required parameters*: N/A 550 *Optional parameters*: 552 * *schema*: A URI identifying a JSON Schema that provides semantic 553 information about this JSON representation. 555 *Encoding considerations*: Same as [JSON] 557 *Security considerations*: Same as [JSON] 559 *Interoperability considerations*: Same as [JSON] 561 *Published specification*: (this document) 563 *Applications that use this media type*: JSON Schema is used in a 564 variety of applications including API servers and clients that 565 validate JSON requests and responses, IDEs that valid configuration 566 files, databases that store JSON, and more. 568 *Fragment identifier considerations*: See Section 2.4.4 569 *Additional information*: 571 * *Deprecated alias names for this type*: N/A 573 * *Magic number(s)*: N/A 575 * *File extension(s)*: json 577 * *Macintosh file type code(s)*: N/A 579 *Person and email address to contact for further information*: See 580 Authors' Addresses section. 582 *Intended usage*: COMMON 584 *Restrictions on usage*: N/A 586 *Author*: See Authors' Addresses section. 588 *Change controller*: N/A 590 3. Interoperability Considerations 592 3.1. YAML Media Types 594 3.1.1. YAML is an Evolving Language 596 YAML is an evolving language and, in time, some features have been 597 added, and others removed. 599 While this document is based on a given YAML version [YAML], media 600 types registration does not imply a specific version. This allows 601 content negotiation of version-independent YAML resources. 603 Implementers concerned about features related to a specific YAML 604 version can specify it in the documents using the %YAML directive 605 (see Section 6.8.1 of [YAML]). 607 3.1.2. YAML and JSON 609 When using flow collection styles (see Section 7.4 of [YAML]) a YAML 610 document could look like JSON [JSON], thus similar interoperability 611 considerations apply. 613 When using YAML as a more efficient format to serialize information 614 intented to be consumed as JSON, information can be discarded: this 615 includes comments (see Section 3.2.3.3 of [YAML]) and alias nodes 616 (see Section 7.1 of [YAML]), that do not have a JSON counterpart. 618 # This comment will be lost 619 # when serializing in JSON. 620 Title: 621 type: string 622 maxLength: &text_limit 64 624 Name: 625 type: string 626 maxLength: *text_limit # Replaced by the value 64. 628 Figure 1: JSON replaces alias nodes with static values. 630 Implementers need to ensure that relevant information will not be 631 lost during the processing. For example, they might consider 632 acceptable that alias nodes are replaced by static values. 634 In some cases an implementer may want to define a list of allowed 635 YAML features, taking into account that the following ones might have 636 interoperability issues with JSON: 638 * non UTF-8 encoding, since YAML supports UTF-16 and UTF-32 in 639 addition to UTF-8; 641 * mapping keys that are not strings; 643 * circular references represented using anchor (see Section 4.1.2 644 and Figure 3). 646 * .inf and .nan float values, since JSON does not support them; 648 * non-JSON types, including the ones associated to tags like 649 !!timestamp that were deployed in older YAML versions; 651 * tags in general, and specifically ones that do not map to JSON 652 types like custom and local tags such as !!python/object and 653 !mytag (see Section 2.4 of [YAML]); 655 non-json-keys: 656 2020-01-01: a timestamp 657 [0, 1]: a sequence 658 ? {k: v} 659 : a map 660 non-json-value: 2020-01-01 662 Figure 2: Example of mapping keys not supported in JSON 664 4. Security Considerations 666 Security requirements for both media type and media type suffix 667 registrations are discussed in Section 4.6 of [MEDIATYPE]. 669 4.1. YAML Media Types 671 4.1.1. Arbitrary Code Execution 673 Care should be used when using YAML tags, because their 674 implementation might trigger unexpected code execution. 676 Code execution in deserializers should be disabled by default, and 677 only be enabled explicitly. In those cases, the implementation 678 should ensure - for example, via specific functions - that the code 679 execution results in strictly bounded time/memory limits. 681 Many implementations provide safe deserializers addressing these 682 issues. 684 4.1.2. Resource exhaustion 686 YAML documents are rooted, connected, directed graphs and can contain 687 reference cycles, so they can't be treated as simple trees (see 688 Section 3.2.1 of [YAML]). An implementation that attempts to do that 689 can infinite-loop at some point (e.g. when trying to serialize a YAML 690 document in JSON). 692 x: &x 693 y: *x 695 Figure 3: A cyclic document 697 Even if a document is not cyclic, treating it as a tree could lead to 698 improper behaviors (such as the "billion laughs" problem). 700 x1: &a1 ["a", "a"] 701 x2: &a2 [*a1, *a1] 702 x3: &a3 [*a2, *a2] 704 Figure 4: A billion laughs document 706 This can be addressed using processors limiting the anchor recursion 707 depth and validating the input before processing it; even in these 708 cases it is important to carefully test the implementation you are 709 going to use. The same considerations apply when serializing a YAML 710 representation graph in a format that do not support reference cycles 711 (see Section 3.1.2). 713 5. IANA Considerations 715 This specification defines the following new Internet media types 716 [MEDIATYPE]. 718 IANA has updated the "Media Types" registry at 719 https://www.iana.org/assignments/media-types 720 (https://www.iana.org/assignments/media-types) with the registration 721 information provided below. 723 +==================================+==========================+ 724 | Media Type | Section | 725 +==================================+==========================+ 726 | application/yaml | Section 2.1 of ThisRFC | 727 +----------------------------------+--------------------------+ 728 | application/openapi+yaml | Section 2.3.2 of ThisRFC | 729 +----------------------------------+--------------------------+ 730 | application/openapi+json | Section 2.3.1 of ThisRFC | 731 +----------------------------------+--------------------------+ 732 | application/schema+json | Section 2.4.5 of ThisRFC | 733 +----------------------------------+--------------------------+ 734 | application/schema-instance+json | Section 2.4.6 of ThisRFC | 735 +----------------------------------+--------------------------+ 737 Table 1 739 IANA has updated the "Structured Syntax Suffixes" registry at 740 https://www.iana.org/assignments/media-type-structured-suffix 741 (https://www.iana.org/assignments/media-type-structured-suffix) with 742 the registration information provided below. 744 +========+========================+ 745 | Suffix | Section | 746 +========+========================+ 747 | +yaml | Section 2.2 of ThisRFC | 748 +--------+------------------------+ 750 Table 2 752 6. Normative References 754 [JSON] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 755 Interchange Format", STD 90, RFC 8259, 756 DOI 10.17487/RFC8259, December 2017, 757 . 759 [jsonschema] 760 Wright, A., Andrews, H., Hutton, B., and G. Dennis, "JSON 761 Schema Core", 28 January 2020, 762 . 764 [LINK] Nottingham, M., "Web Linking", RFC 8288, 765 DOI 10.17487/RFC8288, October 2017, 766 . 768 [MEDIATYPE] 769 Freed, N., Klensin, J., and T. Hansen, "Media Type 770 Specifications and Registration Procedures", BCP 13, 771 RFC 6838, DOI 10.17487/RFC6838, January 2013, 772 . 774 [oas] Darrel Miller, Jeremy Whitlock, Marsh Gardiner, Mike 775 Ralphson, Ron Ratovsky, and Uri Sarid, "OpenAPI 776 Specification 3.0.0", 26 July 2017. 778 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 779 Requirement Levels", BCP 14, RFC 2119, 780 DOI 10.17487/RFC2119, March 1997, 781 . 783 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 784 Resource Identifier (URI): Generic Syntax", STD 66, 785 RFC 3986, DOI 10.17487/RFC3986, January 2005, 786 . 788 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 789 Specifications: ABNF", STD 68, RFC 5234, 790 DOI 10.17487/RFC5234, January 2008, 791 . 793 [RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., 794 "JavaScript Object Notation (JSON) Pointer", RFC 6901, 795 DOI 10.17487/RFC6901, April 2013, 796 . 798 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 799 RFC 7405, DOI 10.17487/RFC7405, December 2014, 800 . 802 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 803 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 804 May 2017, . 806 [SEMANTICS] 807 Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 808 Semantics", Work in Progress, Internet-Draft, draft-ietf- 809 httpbis-semantics-19, 12 September 2021, 810 . 813 [W3C.REC-ldp-20150226] 814 Speicher, S., Arwe, J., and A. Malhotra, "Linked Data 815 Platform 1.0", World Wide Web Consortium Recommendation 816 REC-ldp-20150226, 26 February 2015, 817 . 819 [YAML] Oren Ben-Kiki, Clark Evans, and Ingy dot Net, "YAML Ain't 820 Markup Language Version 1.2", 1 October 2021, 821 . 823 Appendix A. Acknowledgements 825 Thanks to Erik Wilde and David Biesack for being the initial 826 contributors of this specification, and to Darrel Miller and Rich 827 Salz for their support during the adoption phase. 829 In addition to the people above, this document owes a lot to the 830 extensive discussion inside and outside the HTTPAPI workgroup. The 831 following contributors have helped improve this specification by 832 opening pull requests, reporting bugs, asking smart questions, 833 drafting or reviewing text, and evaluating open issues: 835 Eemeli Aro, Tina (tinita) Mueller, Ben Hutton and Jason Desrosiers. 837 FAQ 839 Q: Why this document? After all these years, we still lack a proper 840 media-type for YAML. This has some security implications too (eg. 841 wrt on identifying parsers or treat downloads) 843 Change Log 845 RFC EDITOR PLEASE DELETE THIS SECTION. 847 Author's Address 849 Roberto Polli 850 Digital Transformation Department, Italian Government 851 Italy 852 Email: robipolli@gmail.com