[media-types] Proposed media type registration for YAML

Ben Harris <bjh21@cam.ac.uk> Tue, 07 July 2015 14:57 UTC

Date: Tue, 07 Jul 2015 15:33:55 +0100
From: Ben Harris <bjh21@cam.ac.uk>
To: media-types@iana.org
Message-ID: <alpine.DEB.2.10.1507071519140.29345@puff.ds.cam.ac.uk>
User-Agent: Alpine 2.10 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="1870872840-617897347-1436279570=:29345"
Content-ID: <alpine.DEB.2.10.1507071533420.29345@puff.ds.cam.ac.uk>
Sender: "B.J. Harris" <bjh21@cam.ac.uk>
Archived-At: <http://mailarchive.ietf.org/arch/msg/media-types/e9ZNC0hDXKXeFlAVRWxLCCaG9GI>
Subject: [media-types] Proposed media type registration for YAML
Precedence: list

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.

    Type name:

text

    Subtype name:

vnd.yaml

    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 <yaml-core@lists.sourceforge.net>

    Intended usage:

COMMON

    Restrictions on usage:

N/A

    Author:

Ben Harris, University of Cambridge <bjh21@cam.ac.uk>

    Change controller:

Ben Harris, University of Cambridge <bjh21@cam.ac.uk>
on behalf of Oren Ben-Kiki <oren@ben-kiki.org>, Clark Evans 
<cce@clarkevans.com>, and Ingy döt Net <ingy@ingy.net>

    Provisional registration? (standards tree only):

N/A

-- 
Ben Harris, University of Cambridge Information Services.

[media-types] Proposed media type registration fo… Ben Harris
Re: [media-types] Proposed media type registratio… Martin J. Dürst
Re: [media-types] Proposed media type registratio… Mark Baker
Re: [media-types] Proposed media type registratio… Ben Harris
Re: [media-types] Proposed media type registratio… Ben Harris
Re: [media-types] Proposed media type registratio… Ben Harris