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

[Ben Harris <[e-mail]>]

On Tue, 14 Jul 2015, Martin J. Dürst wrote:

> 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.

I think that's slightly helpful, as is the sentence "See [RFC2046] for 
additional information on the restrictions MIME imposes." from RFC 6838. 
That suggests that, possibly with some extra notes about using only UTF-8 
with MIME, permitting UTF-16 and UTF-32 would be tolerable.

> 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.

The highest-priority design goal for YAML is stated to be "YAML is easily 
readable by humans" (YAML 1.2 section 1.1). So while not designed to 
transmit prose, it is designed to transmit human-readable data.  My 
experience is that even machine-generated YAML is generally more readable 
than XML, JSON, or CSV.

>>     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.

I would much prefer to be able to use the standards tree rather than the 
vendor tree, but RFC 6838 doesn't make this easy.  In the vendor tree, 
third-party registrations are explicitly permitted and "vendor" is 
described as being "construed very broadly", which I think is enough to 
let me register this type on behalf of the YAML authors.  The standards 
tree, on the other hand, would either require me to write an RFC or 
require the YAML authors to submit the request themselves and to be 
approved as a "standards-related organization" by the IESG.

I'll see if I can find a way to make either of the standards-tree routes 
work.  Is there any guidance (or history) on what the IESG considers to be 
a standards-related organization?

-- 
Ben Harris, University of Cambridge Information Services.