Re: [media-types] Proposed media type registration for YAML

[" Martin J. Dürst " <[e-mail]>]

Hello Ben,

On 2015/07/07 23:33, Ben Harris wrote:
> Below is a media type registration I'm proposing to submit for YAML.  I
> have one specific question for the list:
>
> * Is it appropriate to use a "text/*" type for something that might be
> encoded in UTF-16 or UTF-32?  I'm confident that YAML in UTF-8 fits the
> line-break requirements of RFC 2046, but I'm not sure whether that
> permits UTF-16 or UTF-32.

The answer is "it depends". For more details, see e.g.
http://tools.ietf.org/html/rfc7303#section-9.2 (or rather actually 
http://tools.ietf.org/html/rfc7303#section-9.1) or the somewhat older 
http://tools.ietf.org/html/rfc3023#section-8.2.

Because YAML is only rarely used to transmit actual human-readable prose 
(as opposed to structured data in textual form), a top-level type of 
application/, with less restrictions, may be much more appropriate.
That's the conclusion XML came to, after many years and some detours.

>     Type name:
>
> text
>
>     Subtype name:
>
> vnd.yaml

I wonder whether the vnd. prefix here is really appropriate. YAML isn't 
a company in any way. Ideally, something like YAML should just be 
text/yaml (or actually application/yaml, see above). The spec at e.g. 
http://yaml.org/spec/1.2/spec.html definitely looks very detailed and 
well worked out, although I can't speak for the actual quality.

Regards,   Martin.


>     Required parameters:
>
> None
>
>     Optional parameters:
>
> There is a single optional parameter, "version", whose value MUST match
> the ns-yaml-version production in YAML 1.1 or YAML 1.2.  If provided, it
> identifies a version of the YAML specification to which the
> corresponding entity conforms.
>
> The "charset" parameter is not used: The YAML specifications define how
> a YAML processor should determine whether a YAML stream is encoded in
> UTF-8, UTF-16, or UTF-32.
>
>     Encoding considerations:
>
> binary
>
>     Security considerations:
>
> Interpreting arbitrary YAML can be dangerous.  Many YAML processors are
> able to serialise and deserialise arbitrary objects in their host
> programming language, which can include arbitrary executable code.
> Applications consuming YAML from untrusted sources MUST restrict the
> range of object types that can be deserialised to those that are safe.
>
> YAML allows for the construction of complex data structures, including
> cyclic ones.  This can create structures that simple reference-counting
> garbage collectors cannot collect when they become unreferenced.  YAML
> consumers using such garbage collectors may need to record which
> references were generated using aliases and to break those references
> before allowing the structure to become unreferenced.
>
>     Interoperability considerations:
>
> N/A
>
>     Published specification:
>
> YAML Ain’t Markup Language (YAML™) Version 1.2,
> http://yaml.org/spec/1.2/spec.html
> YAML Ain’t Markup Language (YAML™) Version 1.1, http://yaml.org/spec/1.1/
> YAML Ain't Markup Language (YAML™) 1.0, http://yaml.org/spec/1.0/
>
> In each case, a text/vnd.yaml entity is a complete YAML stream, which
> might potentially contain multiple YAML documents.
>
>     Applications that use this media type:
>
> A wide variety of implementations are listed at <http://yaml.org>.
>
>     Fragment identifier considerations:
>
> Fragment identifiers are reserved for future standardisation.  While
> having them refer to YAML anchor names is tempting, those are
> deliberately not unique within a stream and hence would not make good
> fragment identifiers.
>
>     Additional information:
>
>       Deprecated alias names for this type: N/A
>       Magic number(s): N/A
>       File extension(s): .yaml  .yml
>       Macintosh file type code(s): N/A
>
>     Person & email address to contact for further information:
>
> YAML mailing list <[e-mail]>
>
>     Intended usage:
>
> COMMON
>
>     Restrictions on usage:
>
> N/A
>
>     Author:
>
> Ben Harris, University of Cambridge <[e-mail]>
>
>     Change controller:
>
> Ben Harris, University of Cambridge <[e-mail]>
> on behalf of Oren Ben-Kiki <[e-mail]>, Clark Evans
> <[e-mail]>, and Ingy döt Net <[e-mail]>
>
>     Provisional registration? (standards tree only):
>
> N/A
>
>
>
> _______________________________________________
> media-types mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/media-types
>