Tapani Otala | 9 Apr 01:41 2010
Picon

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.
(Continue reading)

mike amundsen | 9 Apr 03:08 2010
Picon

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:
(Continue reading)

Tapani Otala | 9 Apr 03:47 2010
Picon

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
(Continue reading)

mike amundsen | 9 Apr 05:19 2010
Picon

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/
>>
>>
>>
>>
(Continue reading)

Adriano.Santoni | 9 Apr 08:01 2010
Picon

Request for MIME media type Application/Standards Tree

<!-- /* Font Definitions */ <at> font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:1; mso-generic-font-family:roman; mso-font-format:other; mso-font-pitch:variable; mso-font-signature:0 0 0 0 0 0;} <at> font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4; mso-font-charset:0; mso-generic-font-family:swiss; mso-font-pitch:variable; mso-font-signature:-1610611985 1073750139 0 0 159 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin:0cm; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:EN-US;} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; mso-themecolor:hyperlink; text-decoration:underline; text-underline:single;} a:visited, span.MsoHyperlinkFollowed {mso-style-noshow:yes; mso-style-priority:99; color:purple; mso-themecolor:followedhyperlink; text-decoration:underline; text-underline:single;} p.MsoPlainText, li.MsoPlainText, div.MsoPlainText {mso-style-noshow:yes; mso-style-priority:99; mso-style-link:"Plain Text Char"; margin:0cm; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:EN-US;} span.PlainTextChar {mso-style-name:"Plain Text Char"; mso-style-noshow:yes; mso-style-priority:99; mso-style-unhide:no; mso-style-locked:yes; mso-style-link:"Plain Text"; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-hansi-font-family:Calibri;} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:EN-US;} <at> page Section1 {size:612.0pt 792.0pt; margin:70.85pt 2.0cm 2.0cm 2.0cm; mso-header-margin:36.0pt; mso-footer-margin:36.0pt; mso-paper-source:0;} div.Section1 {page:Section1;} -->

Name : Adriano Santoni

 

Email : adriano.santoni <at> actalis.it

 

MIME media type name : application

 

MIME subtype name : timestamped-data

 

Required parameters : None

 

Optional parameters :

None

 

Encoding considerations : binary

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

 

Security considerations :

See the Security considerations in the published specification.

 

Interoperability considerations :

None

 

Published specification :RFC 5544

 

Applications which use this media :

Any application supporting the TimeStampedData format.

 

Additional information :

 

1. Magic number(s) : None

2. File extension(s) : .TSD

3. Macintosh file type code : None

4. Object Identifiers: None

 

None

 

Person to contact for further information :

 

1. Name : Adriano Santoni

2. Email : adriano.santoni <at> actalis.it

 

Intended usage : Common

Carries a TimeStampedData envelope, wrapping a file (or a reference to it) with the corresponding temporal evidence.

 

Author/Change controller : Adriano Santoni Actalis S.p.A.

adriano.santoni <at> actalis.it

 

Roni Even | 9 Apr 11:53 2010

RE: Request for MIME media type Application/Standards Tree

Hi,

I think that according to section 3.1 of RFC 4288 the change controller should be the IETF or the WG that handled RFC 5544

 

Roni Even

 

From: ietf-types-bounces <at> alvestrand.no [mailto:ietf-types-bounces <at> alvestrand.no] On Behalf Of Adriano.Santoni
Sent: Friday, April 09, 2010 9:01 AM
To: ietf-types <at> alvestrand.no
Subject: Request for MIME media type Application/Standards Tree

 

Name : Adriano Santoni

 

Email : adriano.santoni <at> actalis.it

 

MIME media type name : application

 

MIME subtype name : timestamped-data

 

Required parameters : None

 

Optional parameters :

None

 

Encoding considerations : binary

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

 

Security considerations :

See the Security considerations in the published specification.

 

Interoperability considerations :

None

 

Published specification :RFC 5544

 

Applications which use this media :

Any application supporting the TimeStampedData format.

 

Additional information :

 

1. Magic number(s) : None

2. File extension(s) : .TSD

3. Macintosh file type code : None

4. Object Identifiers: None

 

None

 

Person to contact for further information :

 

1. Name : Adriano Santoni

2. Email : adriano.santoni <at> actalis.it

 

Intended usage : Common

Carries a TimeStampedData envelope, wrapping a file (or a reference to it) with the corresponding temporal evidence.

 

Author/Change controller : Adriano Santoni Actalis S.p.A.

adriano.santoni <at> actalis.it

 


Adriano.Santoni | 9 Apr 12:01 2010
Picon

Re: Request for MIME media type Application/Standards Tree

Roni,

that RFC was not developed within a WG; it was an independent submission.

Adriano


Il 09/04/2010 11:53, Roni Even ha scritto:
<!-- /* Font Definitions */ <at> font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} <at> font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} <at> font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif"; color:black;} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoPlainText, li.MsoPlainText, div.MsoPlainText {mso-style-priority:99; mso-style-link:"Plain Text Char"; margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif"; color:black;} span.PlainTextChar {mso-style-name:"Plain Text Char"; mso-style-priority:99; mso-style-link:"Plain Text"; font-family:"Calibri","sans-serif";} span.EmailStyle19 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} <at> page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in;} div.Section1 {page:Section1;} -->

Hi,

I think that according to section 3.1 of RFC 4288 the change controller should be the IETF or the WG that handled RFC 5544

 

Roni Even

 

From: ietf-types-bounces <at> alvestrand.no [mailto:ietf-types-bounces <at> alvestrand.no] On Behalf Of Adriano.Santoni
Sent: Friday, April 09, 2010 9:01 AM
To: ietf-types <at> alvestrand.no
Subject: Request for MIME media type Application/Standards Tree

 

Name : Adriano Santoni

 

Email : adriano.santoni <at> actalis.it

 

MIME media type name : application

 

MIME subtype name : timestamped-data

 

Required parameters : None

 

Optional parameters :

None

 

Encoding considerations : binary

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

 

Security considerations :

See the Security considerations in the published specification.

 

Interoperability considerations :

None

 

Published specification :RFC 5544

 

Applications which use this media :

Any application supporting the TimeStampedData format.

 

Additional information :

 

1. Magic number(s) : None

2. File extension(s) : .TSD

3. Macintosh file type code : None

4. Object Identifiers: None

 

None

 

Person to contact for further information :

 

1. Name : Adriano Santoni

2. Email : adriano.santoni <at> actalis.it

 

Intended usage : Common

Carries a TimeStampedData envelope, wrapping a file (or a reference to it) with the corresponding temporal evidence.

 

Author/Change controller : Adriano Santoni Actalis S.p.A.

adriano.santoni <at> actalis.it

 


Attachment (adriano_santoni.vcf): text/x-vcard, 284 bytes
Sean Turner | 9 Apr 19:02 2010

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

Sean Turner | 9 Apr 19:26 2010

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

Ned Freed | 10 Apr 18:33 2010

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


Gmane