[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

svn:mime-type arbitrary parameters

From: Sean Leonard <dev+ietf_at_seantek.com>
Date: Sat, 25 Oct 2014 11:53:24 -0700

Greetings:

What the best way for Subversion to record parameters of a MIME type
(Internet media type) in a repository?

I require svn:mime-type to be filled out in all of the repositories that
I manage. This is also useful for serving the right content over media
type-aware protocols (HTTP, but there are others).

Some time ago there was a dev discussion about storing the character set
of text in svn:charset (simple textual content) vs. svn:mime-type (using
the header format of RFC 2045).

http://svn.haxx.se/dev/archive-2008-06/0941.shtml
http://svn.haxx.se/dev/archive-2008-07/0138.shtml

It appears that the matter was not fully resolved. svn:charset seems to
enjoy de-facto use. Using RFC 2045 format in svn:mime-type as an
appendage (delimited by ";") would be "correct", but as the poster
notes, is extremely unwieldy. It is not possible to store arbitrary
UTF-8 data, for example, unless you use the syntax of RFC 2231, which
looks like:

    Content-Type: application/x-stuff;
     title*0*=us-ascii'en'This%20is%20even%20more%20
     title*1*=%2A%2A%2Afun%2A%2A%2A%20
     title*2="isn't it!"

Thank you,

Sean

PS I am also the author of the IETF text/markdown media type
registration
<https://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-03>. The
current draft proposes a "syntax" parameter to disambiguate between
different kinds of Markdown. There are hundreds of different
Markdown-derivative syntaxes, and it is unlikely that most of them will
go through the trouble of registering separate media types. This matters
to me personally because we have been storing Markdown content with
materially different syntaxes in our Subversion repositories.
Received on 2014-10-25 20:56:05 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.