Proposal - Extended MIME Type Identifiers

{toc}

h2. Introduction

This proposal aims to aid interoperability between the web's current MIME-type architecture and the more finely-grained identification schemes used within the digital preservation community. This would allow preservation concepts to be embedded more easily in existing tools, and provide a route by which more sophisticated identifiers might become more broadly adopted in the futures.

The seeds of this proposal are already sown within the original MIME type proposal, [RFC 2045|http://tools.ietf.org/html/rfc2046]. For example, from section 4:

Furthermore, in section 4.5.1:

{quote}
The "octet-stream" subtype is used to indicate that a body contains arbitrary binary data. The set of currently defined parameters is:

Finally, the standard allows for extension via shared but unofficial and non-standardised MIME types, prefixed with 'x-' (see section 5.1). And also vnd, which is in partnership or as orphan

This proposal builds on these three areas and extends them to allow MIME types to become interoperable with PRONOM IDs or other fine-grained identifier schemes.

h2. Proposals

First two allow given types to be described in more detail. Second two deal with describing new types.

h3. Define version parameters for known content types

The proposal is to make the version parameter standard for all content types, and prescribe its values for know types. e.g. for PDF, we could define version strings and link them to the PRONOM IDs.

* application/pdf; version="1.0"
** sameAs: PUID:fmt/XXX
* application/pdf; version="1.1"
* application/pdf; version="1.2"
* application/pdf; version="1.3"
* application/pdf; version="1.4"
* application/pdf; version="1.5"
* application/pdf; version="1.6"
* application/pdf; version="1.7"

h3. Define a format-uri parameter for all content types

Add a new parameter, valid for all content types, that permits the addition of a format-uri parameter that declares a linked-data endpoint that identifies the format.

* application/octet-stream; format-uri="http://purl.org/..."

OR perhaps

A format-id or format-urn parameter that does the same thing, but which a controlled scheme instead of a URI scheme. e.g.

* format-id = "PUID:fmt/44"

Note AND relationships are captured like this:

* format-id = "PUID:fmt/44 PUID:fmt/45"

Meaning this item can be parsed as fmt/44 or fmt/45. Or relationships like this:

* format-id = "PUID:fmt/45"; format-id = "PUID:fmt/46"

Meaning this could be one of these two, but I'm not certain. I'm not sure this case makes any sense, and I'm not sure multiple values are allowed.

h3. Formalise the octet-stream 'type' parameter

Take the type parameter, 4.5.1, and begin to standardise the strings. Not sure this is required if format-uri is in place.

* application/octet-stream; type=""


h3. Using prefixed sub-types when standardisation cannot work

To quote the RFC
{quote}
Private values (starting with "X-") may be defined bilaterally between two cooperating agents without outside registration or standardization. Such values cannot be registered or standardized.
{quote}
Plus allowed to use x\- vendor extensions, but only sensible for community agreed but deliberately transient, or orphan works. In general, when standardisation is either too difficult or inappropriate, the DP community could agree on these.


h2. Issues

h3. Impedance mismatch between PUIDs and MIME Types

Although it may appear less sophisticated the MIME Type scheme's parameters framework means it is somewhat more expressive that PUIDs.

For example, the "charset" parameter is applicable to any subtype of "text", ...