[media-types] Proposed media type registration for YAML

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

Return-Path: <bjh21@cam.ac.uk>
X-Original-To: media-types@ietfa.amsl.com
Delivered-To: media-types@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 73B1D1ACD4B for <media-types@ietfa.amsl.com>; Tue, 7 Jul 2015 07:57:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Bg-TCmMhSXm5 for <media-types@ietfa.amsl.com>; Tue, 7 Jul 2015 07:57:17 -0700 (PDT)
Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:201::1:74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADC3C1AC41C for <media-types@ietf.org>; Tue, 7 Jul 2015 07:56:52 -0700 (PDT)
Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk []) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id t67EuVGh021443 for <media-types@iana.org>; Tue, 7 Jul 2015 14:56:52 GMT
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from puff.ds.cam.ac.uk ([]:38428) by ppsw-51.csi.cam.ac.uk (ppsw.cam.ac.uk []:25) with esmtps (TLSv1.2:DHE-RSA-AES128-SHA:128) id 1ZCTwZ-0002w2-ZM (Exim 4.82_3-c0e5623) for media-types@iana.org (return-path <bjh21@cam.ac.uk>); Tue, 07 Jul 2015 15:33:56 +0100
Received: from bjh21 (helo=localhost) by puff.ds.cam.ac.uk with local-esmtp (Exim 4.82) (envelope-from <bjh21@cam.ac.uk>) id 1ZCTwZ-0002aD-SM for media-types@iana.org; Tue, 07 Jul 2015 15:33:55 +0100
Date: Tue, 7 Jul 2015 15:33:55 +0100 (BST)
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>
X-Greylist: Delayed for 00:22:35 by milter-greylist-4.0 (pechora4.lax.icann.org []); Tue, 07 Jul 2015 14:56:52 +0000 (UTC)
Archived-At: <http://mailarchive.ietf.org/arch/msg/media-types/e9ZNC0hDXKXeFlAVRWxLCCaG9GI>
X-Mailman-Approved-At: Tue, 07 Jul 2015 15:49:13 -0700
Subject: [media-types] Proposed media type registration for YAML
X-BeenThere: media-types@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." <media-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/media-types>, <mailto:media-types-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/media-types/>
List-Post: <mailto:media-types@ietf.org>
List-Help: <mailto:media-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/media-types>, <mailto:media-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jul 2015 15:02:58 -0000

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:


    Subtype name:


    Required parameters:


    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:


    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:


    Published specification:

YAML Ain’t Markup Language (YAML™) Version 1.2, 
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 

    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:


    Restrictions on usage:



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>rg>, Clark Evans 
<cce@clarkevans.com>om>, and Ingy döt Net <ingy@ingy.net>

    Provisional registration? (standards tree only):


Ben Harris, University of Cambridge Information Services.