(registered 2024-01-11, last updated 2024-01-11) Media type name: application Media subtype name: prs.implied-object+yaml Required parameters: N/A. Optional parameters: Any parameter whose name matches the ABNF rule `(ALPHA / "_") *(ALPHA / DIGIT / "_" / "." / "-")` is valid. The value of such a parameter SHOULD be a valid URI identifying a YAML tag, or, if the URI starts on "tag:yaml.org,2002:", this initial prefix SHOULD be omitted if that does not result in a syntactically valid URI on its own. This indicates the required string keys of any encoded YAML mapping node as the root of a document or a sequence of documents that is identified by this media type, and the tags of their corresponding values. The value of any such parameter SHOULD NOT be "null" or "tag:yaml.org,2002:null". Note that the set of allowed parameter names includes "charset", which does not indicate encoding and MUST NOT be interpreted in any special way when present. Encoding considerations: binary Same as for application/yaml [RFC-ietf-httpapi-yaml-mediatypes-10]. Security considerations: Same as for application/yaml [RFC-ietf-httpapi-yaml-mediatypes-10]. When processing this type, applications MUST ensure that the structure of the file matches the mapping entry-defining parameters (that the corresponding keys exist and have values with the correct tags), and if they intend to assign a more concrete media type to the file, they SHOULD verify that it is valid. Applications MUST NOT open files coming from untrusted sources if it could lead to arbitrary code execution. Interoperability considerations: Applications that accept or produce this type should not be assumed to have knowledge of more than the top-level mapping entries of the encoded YAML documents. It is not guaranteed that an application offering this type will produce a file in a format that is most commonly associated with the entries, and it is not guaranteed that an application accepting this type will be able to process it any of the formats associated with the entries. Published specification: N/A Applications which use this media: This media type is intended for applications that have to guess the media type of a file, but do not contain heuristics that allow to pick a more concrete media type with acceptable confidence. Fragment identifier considerations: Same as for application/yaml [RFC-ietf-httpapi-yaml-mediatypes-10]. Restrictions on usage: N/A Additional information: 1. Deprecated alias names for this type: N/A 2. Magic number(s): N/A 3. File extension(s): N/A 4. Macintosh file type code: N/A 5. Object Identifiers: N/A General Comments: This media type identifies a meta-format that encompasses all YAML-based formats that encode a document or a sequence of documents with top-level mappings whose entries have specific keys and value tags. It is intended for use in applications that describe files using media types, but do not have sufficient heuristics to output a more specific media type. In such a case, the application may parse the YAML content and analyze the existing top-level entries to populate the parameters. There are a few details to be noted: * The set of allowed parameter names is more restricted compared to what is permitted by the general syntax in [RFC 2045], Section 5.1. While YAML mapping entries may have completely arbitrary keys, such seldom denote any useful structure in YAML documents, and thus this set is limited to cover only strings (with the tag "tag:yaml.org,2002:str") that can be commonly used as identifiers in programming languages (specifically, it is aligned with the NCName production in XML). * A YAML file may store a single document or multiple documents, thus, when a particular sequence of documents is encountered, it must be parsed fully to ascertain that individual documents are compatible. When any two top-level entries with equivalent string keys (regardless of casing differences, since media type parameter names are case-insensitive) are encountered, they MUST be ignored if they have differently tagged values when populating the media type parameters, and when validating YAML mappings against this media type, any entry whose key case-insensitively matches the parameter is sufficient to validate that parameter if the value tags correspond. In addition, the relevant keys MUST be present in every individual document in the sequence. This process may lead to an application/prs.implied-object+yaml object with no parameters, which is valid and denotes any sequence of YAML documents storing a mapping. * When populating the parameters, it is recommended to sort them alphabetically in a case-insensitive manner (i.e. converted to uppercase and sorted lexicographically according to the ASCII values of individual characters) to simplify comparisons or indexing. * The tags are determined in accordance with the core schema tag resolution , and thus include (but are not limited to) values such as "map", "seq", "str", "int", "float", and "bool", shortened from their respective full "tag:yaml.org,2002:" URIs. As an exception, "tag:yaml.org,2002:null" is removed from this set in any form, shortened or full, and null-tagged entries are made impossible to express, with the assumption that any such entry may have other expected tags which would otherwise lead to completely incompatible media types. Null-tagged values are however taken into account for the case of repeated entries described above, and cause differently tagged entries with an equivalent name to be ignored. Examples: application/prs.implied-object+yaml;a=str;b="tag:yaml.org,2002:ns:other";c="ns/other:x" - The media type that represents YAML mappings with 3 required entries with the corresponding keys, whose values are tagged "tag:yaml.org,2002:str", "tag:yaml.org,2002:ns:other", and "tag:yaml.org,2002:ns/other:x", respectively. The second tag cannot be shortened to "ns:other", because that is a syntactically valid URI, while the third tag can be shortened because "ns/other:x" is missing a valid URI scheme. Person to contact for further information: 1. Name: Marek Čermák 2. Email: cermmarek&gmail.com Intended usage: LIMITED USE It is not recommended to use this media type when a more concrete type is known. Its use beyond automated archival, content negotiation and other purposes in general file hosting is limited. Applications should not advocate themselves as accepting this media type if they require more specific structure or format. Author/Change controller: Marek Čermák