Remove references to JSON Schema media types

Author: jdesrosiers

.remarkrc-lint.js

@@ -2,6 +2,7 @@ import remarkValidateLinks from "remark-validate-links";
 import remarkPresetLintConsistent from "remark-preset-lint-consistent";
 import remarkPresetLintRecommended from "remark-preset-lint-recommended";
 import remarkPresetLintMarkdownStyleGuide from "remark-preset-lint-markdown-style-guide";
+import remarkLintDefinitionCase from "remark-lint-definition-case";
 import remarkLintListItemIndent from "remark-lint-list-item-indent";
 import remarkLintListItemSpacing from "remark-lint-list-item-spacing";
 import remarkLintNoFileNameMixedCase from "remark-lint-no-file-name-mixed-case";
@@ -14,6 +15,7 @@ export default {
     remarkPresetLintConsistent,
     remarkPresetLintRecommended,
     remarkPresetLintMarkdownStyleGuide,
+    [remarkLintDefinitionCase, false],
     [remarkLintListItemIndent, "one"],
     [remarkLintListItemSpacing, { checkBlanks: true }],
     [remarkLintNoFileNameMixedCase, false],

specs/jsonschema-core.md

@@ -105,8 +105,8 @@ define their own dialects of JSON Schema.
 
 ### JSON Document
 
-A JSON document is an information resource (series of octets) described by the
-`application/json` media type.
+In JSON Schema, the terms "JSON document", "JSON data", and "JSON value" are
+interchangeable and refer to the data model defined in {{data-model}}.
 
 In JSON Schema, the terms "JSON document", "JSON text", and "JSON value" are
 interchangeable because of the data model it defines in {{data-model}}.
@@ -117,13 +117,8 @@ model can be interpreted against a JSON Schema.
 
 ### Instance
 
-A JSON document to which a schema is applied is known as an "instance".
-
-JSON Schema is defined over `application/json` or compatible documents,
-including media types with the `+json` structured syntax suffix.
-
-Among these, this specification defines the `application/schema-instance+json`
-media type which defines handling for fragments in the IRI.
+A JSON document to which a schema is applied is known as a "JSON instance" or
+just an "instance".
 
 #### Instance Data Model {#data-model}
 
@@ -193,12 +188,8 @@ use of the `const` keyword.
 
 ### JSON Schema Documents {#schema-document}
 
-A JSON Schema document, or simply a schema, is a JSON document used to describe
-an instance. A schema can itself be interpreted as an instance, but SHOULD
-always be given the media type `application/schema+json` rather than
-`application/schema-instance+json`. The `application/schema+json` media type is
-defined to offer a superset of the fragment identifier syntax and semantics
-provided by `application/schema-instance+json`.
+A JSON Schema document, or simply a schema, is used to describe an instance. A
+schema can itself be interpreted as an instance.
 
 A JSON Schema MUST be an object or a boolean.
 
@@ -909,21 +900,25 @@ steps.
 
 1. The `$schema` keyword - Implementations MUST process the schema according to
    the dialect it declares.
-2. `application/schema+json` media type with a `schema` parameter -
-   Implementations which support media type parameter inputs MUST process the
-   schema according to the dialect the parameter declares. A media type will
-   generally only be available if the schema has been retrieved from an external
-   source and only applies to the document root.
-3. Parent dialect - An embedded schema resource which does not itself contain a
-   `$schema` keyword MUST be processed using the same dialect as the schema
-   which contains it. If the schema is embedded in a non-schema document, the
-   semantics for determining the dialect MAY be determined by any specification
-   which applies to that document.
+2. Parent schema dialect - A schema resource embedded within another schema
+   resource which does not itself contain a `$schema` keyword MUST be processed
+   using the same dialect as the schema which contains it.
+3. External context - In some contexts, there is a default dialect or a way to
+   declare the dialect external from the schema resource in question. Examples
+   include the following.
+    - If the schema is embedded in a non-schema document (such as an OpenAPI
+      Document), the semantics for determining the dialect MUST be determined by
+      the specification that applies to that document.
+    - If the media type of the schema is known and the media type defines a
+      default dialect or a way to declare a dialect, the dialect MUST be
+      determined by the rules of that media types. For example, the
+      [application/schema+json] media type includes a `schema` parameter that
+      can be used to declare the dialect. A media type will generally only be
+      available if the schema has been retrieved from an external source and
+      only applies to the document root.
 4. User configuration - Implementations MAY provide means for the user to
    configure the dialect under which a schema should be processed.
 
-(Note that steps 2 and 3 are mutually exclusive.)
-
 If the dialect is not specified through one of these methods, the implementation
 MUST refuse to process the schema.
 
@@ -940,9 +935,6 @@ The value of this keyword MUST be an
 [IRI](https://www.rfc-editor.org/info/rfc3987) (containing a scheme) and this
 IRI MUST be normalized.
 
-If this IRI identifies a retrievable resource, that resource SHOULD be of media
-type `application/schema+json`.
-
 The `$schema` keyword SHOULD be used in the document root schema object, and MAY
 be used in the root schema objects of embedded schema resources. This keyword
 MUST NOT appear in a subschema that is not also the root object of a schema
@@ -1143,11 +1135,10 @@ this string to end users. Tools for editing schemas SHOULD support displaying
 and editing this keyword. The value of this keyword MAY be used in debug or
 error output which is intended for developers making use of schemas.
 
-Tools that translate other media types or programming languages to and from
-`application/schema+json` MAY choose to convert that media type or programming
-language's native comments to or from `$comment` values. The behavior of such
-translation when both native comments and `$comment` properties are present is
-implementation-dependent.
+Tools that translate schemas between media types or programming languages MAY
+choose to convert that media type or programming language's native comments to
+or from `$comment` values. The behavior of such translation when both native
+comments and `$comment` properties are present is implementation-dependent.
 
 Implementations MAY strip `$comment` values at any point during processing. In
 particular, this allows for shortening schemas when the size of deployed schemas
@@ -1181,8 +1172,8 @@ implementation-specific default IRI MAY be used as described in RFC 3987 Section
 6.5 and RFC 3986 Section 5.1.4. It is RECOMMENDED that implementations document
 any default base IRI that they assume.
 
-If a schema object is embedded in a document of another media type, then the
-initial base IRI is determined according to the rules of that media type.
+If a schema object is embedded in a document that is not a schema, then the
+initial base IRI is determined according to the rules of that document.
 
 Unless the `$id` keyword described in an earlier section is present in the root
 schema, this base IRI SHOULD be considered the canonical IRI of the schema
@@ -1460,14 +1451,17 @@ custom keywords.
 A reference target under a keyword for which the value is not explicitly known
 to be a schema results in undefined behavior. Implementations MAY support
 references to these locations, however such behavior is not considered
-interoperable and should not be relied upon.[^10]
+interoperable and should not be relied upon.
 
-[^10]: These scenarios are analogous to fetching a schema over HTTP but
-receiving a response with a Content-Type other than `application/schema+json`.
-An implementation can certainly try to interpret it as a schema, but the origin
-server offered no guarantee that it actually is any such thing. Therefore,
-interpreting it as such has security implication and may produce unpredictable
-results.
+When a schema is resolved over HTTP or another protocol that declares the media
+type of the response, implementations SHOULD refuse to evaluate schemas whose
+declared media type is not a known and supported JSON Schema media type such as
+[application/schema+json].[^10]
+
+[^10]: An implementation can certainly try to interpret it as a schema, but
+there's no guarantee that it can be parsed and evaluated as a schema. Therefore,
+interpreting it as such has security implications and may produce unpredictable
+or malicious results.
 
 #### Failure to resolve references {#failed-refs}
 
@@ -2159,49 +2153,6 @@ Third-party JSON Schema extensions may introduce additional risks. Implementers
 are advised to consult the specifications of any extensions they support and
 take into account their security considerations as well.
 
-## IANA Considerations
-
-### `application/schema+json`
-
-The proposed MIME media type for JSON Schema is defined as follows:
-
-Type name:: application
-
-Subtype name:: schema+json
-
-Required parameters:: N/A
-
-Encoding considerations:: Encoding considerations are identical to those
-specified for the `application/json` media type. See [JSON][rfc8259].
-
-Security considerations:: See {{security}} above.
-
-Interoperability considerations:: See Sections [6.2](#language),
-[6.3](#data-model), and [6.4](#regex) above.
-
-Fragment identifier considerations:: See {{fragments}}
-
-### `application/schema-instance+json`
-
-The proposed MIME media type for JSON Schema Instances that require a JSON
-Schema-specific media type is defined as follows:
-
-Type name:: application
-
-Subtype name:: schema-instance+json
-
-Required parameters:: N/A
-
-Encoding considerations:: Encoding considerations are identical to those
-specified for the `application/json` media type. See [JSON][rfc8259].
-
-Security considerations:: See {{security}} above.
-
-Interoperability considerations:: See Sections [6.2](#language),
-[6.3](#data-model), and [6.4](#regex) above.
-
-Fragment identifier considerations:: See {{fragments}}
-
 ## %appendix% Schema identification examples {#idexamples}
 
 Consider the following schema, which shows `$id` being used to identify both the
@@ -2676,3 +2627,4 @@ to the document.
 [rfc6901]: https://www.rfc-editor.org/info/rfc6901
 [rfc8259]: https://www.rfc-editor.org/info/rfc8259
 [rfc8288]: https://www.rfc-editor.org/info/rfc8288
+[application/schema+json]: ../ietf/json-schema-media-types.md