Hi Mike, Mainly it was because there did not appear to be any precedent of vendor-specific multipart types. These composite assets are intended to represent a single logical asset comprised of multiple assets. An example of such an asset would be the Photoshop Elements file format "PSE", which is a single file that contains multiple assets much like a ZIP file that in turn is registered under application/zip rather than multipart/zip. Cheers, Tapani Otala On Apr 8, 2010, at 18:08 , mike amundsen wrote:

Why not register this as a Multi-Part MIME type? http://www.iana.org/assignments/media-types/multipart/

mca http://amundsen.com/blog/

On Thu, Apr 8, 2010 at 19:41, Tapani Otala <otala@adobe.com> wrote:

...

Hello,

We would like to submit a new vendor-specific MIME type for your review. The basic idea is simple, but it did not quite fit in the IANA registration form and the recommendation was to post it to this mailing list for review.

MIME media type name: application

MIME subtype name: vnd.adobe.composite-asset

Required parameters: final_type, final_subtype

Optional parameters: none

Description:

This media type denotes a generic composite asset container that contains multiple sub-assets, each of which has an existing IANA registered text, image and video media types. The final type is identified by the final_type and final_subtype parameters.

Sample usage:

application/vnd.adobe.composite-asset; final_type=text, final_subtype=html

Encoding considerations: binary

This media type may require encoding on transports not capable of handling binary.

Security considerations:

This media type contains content that could be considered 'active' or 'executable'. However, it does not expand upon the existing security considerations already applicable to those media types.

Published specification:

This media type references existing IANA registered MIME types, for which there are existing specifications.

Applications which use this media:

Adobe Photoshop.com Web Service (http://www.photoshop.com) and its client applications.

Person to contact for further information:

Tapani Otala (otala@adobe.com)

Intended usage: Limited Use

The use of this media type is limited to the Photoshop.com web service and its client applications.

Sincerely,

Tapani Otala Sr. Engineering Manager, Photoshop.com Platform Services Adobe Systems Incorporated

Mainly it was because there did not appear to be any precedent of vendor-specific multipart types.

That's technically true but irrelevant. THere are no special restrictions on who can register multipart types. There is, however, a requirement (RFC 4288 section 4.2.6) that any type registered under mulitpart MUST conform to the multipart syntax described in RFC 2046. If your type uses, say, a zip container or something similar, it cannot be registered under multipart.

These composite assets are intended to represent a single logical asset comprised of multiple assets. An example of such an asset would be the Photoshop Elements file format "PSE", which is a single file that contains multiple assets much like a ZIP file that in turn is registered under application/zip rather than multipart/zip.

The real question with container types is whether or not they meet the requirements of RFC 4288 section 4.1. Most do but occasionally one comes along that does not, and when they don't no registration of any sort of is possible. Ned

Our content does meet the requirements of RFC 4288 section 4.1, just not in compliance with RFC 2046.

So looks like the application/vnd.adobe.composite-asset is still the appropriate place for this type. Would you agree?

Yes, I'm in agreement with this assessment. Ned

On Wed, Apr 14, 2010 at 21:47, Ned Freed <ned.freed@mrochek.com> wrote:

...

...

Our content does meet the requirements of RFC 4288 section 4.1, just not in compliance with RFC 2046.

...

So looks like the application/vnd.adobe.composite-asset is still the appropriate place for this type. Would you agree?

Yes, I'm in agreement with this assessment.

One (late) question:

Is there no precedence for adding +zip for such composite formats?

No. The question would be: Is being able to perform generic processing of formats packaged using ZIP useful even when you cannot process the specific type? If the answer is yes, then +zip makes sense, if not, then it doesn't. In the absence of more explicit guidelines, which we have for XML-based types but nothing else, this is a call for the registrant to make.

Compared this to say +xml for various XML-derived mimetypes like application/rdf+xml and image/svg+xml.

The argument for +xml is that there's value in being able to process something as XML even when you don't support the type specifically. I can see that argument applying to +zip. I can also see it not applying.

Another example: application/vnd.oasis.opendocument.text is a structured ZIP-file, where META-INF/manifest.xml describes the mime-types of the content (and the uncompressed file mimetype shows the mimetype of the archive itself)

There are many types structured this way.

We're thinking of being strongly inspired by the ODF archive format to make a container for Taverna workflows (by utillising org.odftoolkit.odfdom.pkg.OdfPackage).

Currently I'm thinking to call this application/vnd.taverna.scufl2.research-object+zip - but if the precedence is to *not* include "+zip" we'll just drop the last bit.

Any views on this..?

Speaking in my capacity as a media type reviewer, according to RFC 4288: In accordance with the rules specified in [RFC3023], media subtypes that do not represent XML entities MUST NOT be given a name that ends with the "+xml" suffix. More generally, "+suffix" constructs should be used with care, given the possibility of conflicts with future suffix definitions. I read this as saying that I should push back on any subtype name ending in +zip where the type itself is _not_ enclosed in a ZIP archive or if there's clearly a reason why you wouldn't want generic treatement for the type to ever occur. But I see neither of those applying to your registration. We have in fact registered various types with +suffixes other than +xml, but this may be the first time someone wanted +zip specifically in their type name. Ned