Vendor-specific MIME type for review

Tapani Otala otala at adobe.com
Wed Apr 14 01:33:54 CEST 2010


Hi Ned,

Thanks for the valuable feedback. Here are clarifications:

On Apr 10, 2010, at 09:33 , Ned Freed wrote:

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

Thanks, understood.

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

Our content does not conform to the multipart syntax of RFC 2046, so therefore the multipart tree seems out of question.

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

Cheers,

Tapani Otala
Sr. Engineering Manager, Photoshop.com



More information about the Ietf-types mailing list