Vendor-specific MIME type for review

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.

Re: Vendor-specific MIME type for review

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 <at> 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:

Re: Vendor-specific MIME type for review

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

Re: Vendor-specific MIME type for review

Understood.

mca
http://amundsen.com/blog/

On Thu, Apr 8, 2010 at 21:47, Tapani Otala <otala <at> adobe.com> wrote:
> 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/
>>
>>
>>
>>

Request for MIME media type Application/Standards Tree

RE: Request for MIME media type Application/Standards Tree

Re: Request for MIME media type Application/Standards Tree

application/pkcs8

I believe that the application/pkcs8 media type registration was 
reviewed by these experts previously; however, the last time it was 
reviewed it was in http://tools.ietf.org/html/draft-ietf-sip-certs.  The 
registration was moved from the sip-certs ID to an ID that updates 
PKCS#8 (http://tools.ietf.org/html/draft-turner-asymmetrickeyformat-04) 
to keep all the PKCS#8 information in one place.  Can someone confirm 
whether or not a new review is needed?  If it is, can the clock start now?

spt

application/pkcs10

I'd like to request an expert review for the application/pkcs10 media 
type registration found in:
http://tools.ietf.org/html/draft-turner-application-pkcs10-media-type

The text for formation of the application/pkcs10 media type is adapted
from RFC 2311.  Only minor changes were made, as can be seen in the
diffs between version -00 and -01. The changes in -02 were editorial. 
An IETF LC has been requested for this ID.

spt

Re: Vendor-specific MIME type for review

> 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