- Ietf-types - alvestrand.no

Registration of Media types proposed by LC
by Ray Denenberg, Library of Congress 07 May '09

07 May '09

The following media types are proposed for registration on the standards tree: application/mods+xml application/mads+xml application/mets+xml application/marcxml+xml application/sru+xml These are proposed by the Library of Congress on behalf of several constituencies including the library/bibliographic and metadata communities. These all correspond to standards maintained at the Library of Congress. Please see the document at: http://www.loc.gov/standards/register-media-types.doc for background and for the filled-out template as required by RFC 4288. According to RFC 4288, "Registration of a new media type or types starts with the construction of a registration proposal." This correspondence together with the above referenced document is intended to serve as construction of the proposal. RFC 4288 further states: "Proposals for media types registered in the standards tree by the IETF itself MUST be published as RFCs. Standards tree registrations for media types defined in documents produced by other standards bodies MUST be described by a formal standards specification produced by that body." Formal specifications are cited in the referenced document for each media type. So may I infer that an RFC is not necessary? Further .... "Proposed registrations in the standards tree by other standards bodies should be communicated to the IESG (at iesg(a)ietf.org) and to the ietf-types list (at ietf-types(a)iana.org) .. Notice of a potential media type registration in the standards tree MUST be sent to the "ietf-types(a)iana.org" mailing list for review." Thus I an sending this correspondence to iesg(a)ietf.org and ietf-types(a)iana.org. Further.... "Provided that the media type meets all of the relevant requirements and has obtained whatever approval is necessary, the author may submit the registration request to the IANA... IESG approval in effect submits the registration to the IANA. There is no need for an additional registration request." Based on this I am not sure what further steps if any I need to take, so I await guidance. (I have not previously registered a media type.) Thank you. Ray Denenberg, Library of Congress

3 5

Did ietf-types move from iana.org to ietf.org?
by Dean Willis 06 May '09

06 May '09

All the types email I've gotten recently has had a to: of ietf-types(a)ietf.org . However, http://trac.tools.ietf.org/group/iesg/trac/wiki/MediaTypes and http://tools.ietf.org/html/rfc4288 say iana.org. Which is right? -- Dean

2 1

Vendor-specific MIME type for review
by Tapani Otala 05 May '09

05 May '09

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: image MIME media type name: video MIME subtype name: vnd.adobe.partial-upload Required parameters: final_type, final_subtype Optional parameters: none Description: This media type denotes an on-going partial upload of existing IANA registered image and video media types. The final type is identified by the final_type and final_subtype parameters. Sample usage: video/vnd.adobe.partial-upload; final_type=video, final_subtype=mp4 Encoding considerations: binary This media type may require encoding on transports not capable of handling binary. Security considerations: This media type references 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(a)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

1 0

MIME Media Types
by Christian Timmerer (ITEC) 04 May '09

04 May '09

Hello, I'd like to inform you that we've defined the MIME type application/ mp21 as part of ISO/IEC 21000-9:2005/Amd.1:2008 (File format of the MPEG-21 Multimedia Framework). The MIME type definition is publicly available at the following address and also below for your convenience. Annex D of ISO/IEC 21000-9:2005: http://standards.iso.org/ittf/PubliclyAvailableStandards/c050551_ISOIEC_210… F. A. S. site: http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html I would appreciate if this could be included as a mime type at http://www.iana.org/assignments/media-types/application/ . In case you have any questions, please do not hesitate to contact me. Thank you. Best regards, -Christian (editor of ISO/IEC 21000-9:2005/Amd.1:2008) The text from http://standards.iso.org/ittf/PubliclyAvailableStandards/c050551_ISOIEC_210… MIME media type name: application MIME subtype name: mp21 Required parameters: none Optional parameters: none Encoding considerations: base64 is generally preferred; files are binary and should be transmitted without CR/LF conversion, 7-bit stripping, etc. Note that although files conforming to ISO/IEC 21000-2 are textual XML the mp21 file which contains it is binary. Security considerations: It is possible to inject non-compliant MPEG streams (Audio, Video, and Systems) in the MP21 file to overload the receiver/decoder's buffers. This might compromise the functionality of the receiver or even crash it. An MP21 file supports the storage of stream types, including commands that are executed on the terminal such as Digital Item Methods based on ECMASCRIPT for which also bindings to Java(TM) and C++ exists. It is possible to use one or more of the above in a manner non- compliant to MPEG to crash the receiver or temporarily make it unavailable. Authentication mechanisms can be used to validate of the sender and the data to prevent security problems due to non-compliant malignant MP21 files. Interoperability considerations: A number of interoperating implementations exist within the ISO/IEC 21000 community, and that community has reference software for reading and writing the file format. Published specification: ISO/IEC 21000-9:2005 Applications which use this media type: Multimedia Additional information: Magic number(s): none File extension(s): m21 and mp21 are both declared at http://www.fileinfo.net and http://filext.com/. Macintosh File Type Code(s): mp21 is registered with Apple. Person & email address to contact for further information: David Singer, singer(a)apple.com Intended usage: COMMON Author/Change controller: David Singer, ISO/IEC 21000 file format chair

1 0

MIME Type Review: application/nlsml+xml, text/grammar-ref-list
by Eric Burger 28 Apr '09

28 Apr '09

http://tools.ietf.org/html/draft-ietf-speechsc-mrcpv2 defines the following MIME types: application/nlsml+xml is defined in section 13.2.1 text/grammar-ref-list is defined in section 13.5.1 Please do not panic about section 13.5.2, text/uri-list. Since it is substantially identical to the definition in RFC 2483, we will most likely remove the definition in section 13.5.2 and reference the IANA registry, with an Informative reference to RFC 2483. We have been at this for five years, and to be honest we cannot remember if we asked for review. We really, really, really are done. Thus, we would appreciate a quick look. Thanks.

1 0

Mime type registration
by Shane Ruman 17 Apr '09

17 Apr '09

Hello, Below is our request for a registered mime-type. The purpose of this mime type has a limited scope - to communicate a video uuid between our browser-based video player and our desktop video player. If there is some issue with the request or further steps must be take, please let me know. Thanks. Subject: Registration of media type vendor/application Type name: application Subtype name: vnd.extendmedia.ocmf Required parameters: none Optional parameters: none Encoding considerations: none Security considerations: none Interoperability considerations: none Published specification: none Applications that use this media type: ExtendMedia OpenCASE Additional information: none Person & email address to contact for further information: sruman(a)extend.com Intended usage: LIMITED USE Restrictions on usage: Strictly to be used between two components of the OpenCASE video asset management suite. Author: Shane Ruman Change controller: Shane Ruman

1 0

Re: Request for mime type registration for application/vnd.pkg5.info
by jmr 08 Apr '09

08 Apr '09

Mark - we are not sure at present if we will be registering other vnd.pkg5.* types, which is why we left it like this. I plan to get a spec for the p5i file next week and will post it then. Thanks, JR Message: 1 Date: Sun, 5 Apr 2009 17:14:52 -0400 From: Mark Baker <mark(a)coactus.com> Subject: Re: Request for mime type registration for application/vnd.pkg5.info To: jmr <John.Rice(a)sun.com> Cc: ietf-types(a)iana.org Message-ID: <e9dffd640904051414w5ed1415dta624a0900b5ceae2(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 27, 2009 at 2:18 PM, jmr <John.Rice(a)sun.com> wrote: > > Hi, > > > > I am a developer working on the Packaging System which is part of the > > OpenSolaris.org project [1]. I would like to register a mime type for > > OpenSolaris.org's IPS packaging system, pkg(5) [2]: > > > > MimeType: application/vnd.pkg5.info > Can I assume by your choice of name structure that you're planning to register other vnd.pkg5.* types? If yes, then that's fine, otherwise you might just want to go with vnd.pkg5-info. Mark.

1 0

Request for mime type registration for application/vnd.pkg5.info
by jmr 05 Apr '09

05 Apr '09

Hi, I am a developer working on the Packaging System which is part of the OpenSolaris.org project [1]. I would like to register a mime type for OpenSolaris.org's IPS packaging system, pkg(5) [2]: MimeType: application/vnd.pkg5.info File extension(s): .p5i Magic number(s): None The contents of the file are in JSON format (http://www.json.org/) and specify one or more Publishers to add to a users system that is running OpenSolaris, along with an optional number of packages [3]. The mime type is bound to files of .p5i extension [4] and clicking on such a file on the OpenSolaris system launches the Package Manager application to process the file, prompting the user to install the named Repositories and Packages. I have read rfc4288: - Media Type Specification and Registration Procedures: http://tools.ietf.org/html/rfc4288 And as per guidelines in Section 5, wanted to submit this mime type for initial review and comment before submitting a formal request via: http://www.iana.org/cgi-bin/mediatypes.pl Best regards, John Rice Snr. Staff Engineer Dublin, Ireland Sun Microsystems [1]: http://www.opensolaris.org/os/ [2]: http://opensolaris.org/sc/src/pkg/gate/src/man/pkg.5.txt http://www.opensolaris.org/os/project/pkg/ http://www.opensolaris.org/os/package/ [3]: http://blogs.sun.com/jmr/entry/packagemanager_for_2009_06 [4]: Example .p5i file: ----------------------------------- { "publishers": [ { "name": "opensolaris.org", "packages": [ "SUNWfirefoxl10n-pl-PL", "SUNWthunderbirdl10n-pl-PL" ], "repositories": [ { "collection_type": "core", "description": "opensolaris.org", "legal_uris": [ "http://opensolaris.org/license.html" ], "mirrors": [], "name": "opensolaris.org", "origins": [ "http://osol-re.sfbay.sun.com/" ], "refresh_seconds": 43200, "registration_uri": "", "related_uris": [] } ] }, { "name": "sunfree", "packages": [ "IPSFWjoe" ], "repositories": [ { "collection_type": "supplemental", "description": "sunfree", "legal_uris": [], "mirrors": [], "name": "sunfree", "origins": [ "http://pkg.sunfreeware.com:9000/" ], "refresh_seconds": 43200, "registration_uri": "", "related_uris": [] } ] }, { "name": "contrib", "repositories": [ { "collection_type": "supplemental", "description": "contrib", "legal_uris": [ "http://pkg.opensolaris.org/contrib/license.html" ], "mirrors": [], "name": "contrib", "origins": [ "http://pkg.opensolaris.org/contrib/" ], "refresh_seconds": 43200, "registration_uri": "", "related_uris": [] } ] } ], "version": 1 }

3 2

Re[2]: Registration of media type application/vnd.emclient.accessrequest+xml
by Filip Navara 02 Apr '09

02 Apr '09

Hello, sorry for late reply. You might be right about the "version" parameter, we included it only to prevent compatibility problems in future and we actually don't plan to use it. Your suggestion of new MIME type seems reasonable and we might as well drop the parameter entirely (and keep the "1.0" value as only possible, for compatibility). The "Encoding considerations" section has been changed to match RFC 3023. It's primarily used as XML MIME part inside an e-mail message. There is no published specification currently and there will not be one until May or so. Thanks for suggestions. Best regards, Filip Navara > -----Original Message----- > From: Mark Baker <mark(a)coactus.com> > To: Filip Navara <navara(a)emclient.com> > Cc: "ietf-types(a)iana.org" <ietf-types(a)iana.org> > Date: 02/19/09 22:17 > Subject: Re: Registration of media type application/vnd.emclient.accessrequest+xml > > On Thu, Jan 22, 2009 at 11:14 AM, Filip Navara <navara(a)emclient.com> wrote: > > > > Type name: application > > > > Subtype name: Vendor Tree - vnd.emclient.accessrequest+xml > > > > Required parameters: none > > > > Optional parameters: > > > > version - in the X.Y notation where X specifies major version change and Y > > specifies minor version change. Applications supporting this MIME type should > > not try to process the content unless the major version number is recognize > > by the particular implementation. > > I would recommend against this approach if not too late to change it > in your software. If a change occurs to the format such that old > software will not be able to process new documents, then you should > mint a new media type. > > > > > Encoding considerations: > > > > The content of this media type consists of lines of 7bit or 8bit text. > > In the latter case use of quoted-printable or base64 may be needed > > when operating over 7bit transports. > > I'm confused. If you're using the "+xml" suffix, the format needs to > be XML based and not some transformed version of XML. Transfer > codings ala HTTP are of course permitted, but it's not clear to me > that this is what you're talking. > > > > > Security considerations: > > > > The type exists to provide a limited and safe subset of operations to media > > authors, but the full spectrum of security issues associated with this type > > has not been completely assessed. > > Explicit actions based on the content should be done only after confirmation > > by the recepient. Embedding inside S/MIME container with digital signature > > is recommended. > > See RFC 3023, section 10 for a more complete analysis of XML related > > security issues. > > > > Interoperability considerations: > > > > There are no special known interoperability issues, but the full spectrum > > of interoperability issues associated with this type has not been completely > > assessed. > > > > Published specification: > > Is there one? > > Mark.

1 0

Registration of MIME media type MESSAGE/DISCLAIMER
by Ravishankar Nandagopalan 26 Mar '09

26 Mar '09

MIME media type name: MESSAGE MIME subtype name: DISCLAIMER Required parameters: Disclaiming Domain (DD), Boundary Optional parameters: Disclaimer Action (DA), Department Identification (DID) Encoding considerations: Appropriate encoding should be used based on the media being encoded as the types can include text plain, HTML, images and other multimedia contents Security considerations: Since disclaimers can be constructed using 'External-body' media type and can contain 'Image' media, the security considerations outlined in RFC 2046<http://www.rfc-editor.org/rfc/rfc2046.txt> and RFC 2045<http://www.rfc-editor.org/rfc/rfc2045.txt> will apply for the media type and the RFC list specified for the Image media sub-type specified here<http://www.iana.org/assignments/media-types/image/>. Applications which use this media type: Fax and Messaging Person & email address to contact for further information: Ravishankar Nandagopalan ravisn(a)microsoft.com Intended usage: COMMON Author/Change controller: Ravishankar Nandagopalan Parameter descriptions: 1. Disclaiming domain (DD): Defines the domain that inserts/owns the disclaimer. 2. Boundary: Boundary delimiters, which is defined in RFC 2046<http://www.rfc-editor.org/rfc/rfc2045.txt> 3. Disclaimer Action (DA): This optional parameter informs the user agent whether to append or prepend the disclaimer to the message body. The default action if omitted or unspecified should be 'Append'. 4. Department Identification (DID): This parameter is used in the scenario where departments or entities disclaim using the same SMTP domain. This parameter should be populated when the aforementioned scenario exists to manage the disclaimers without duplication. Media subtype usage: This media sub-type is intended to make disclaimers more manageable and legible for the users by avoiding duplication of disclaimers and help manage their rich content for effective and error free encoding and transmission. The media type will be used to treat disclaimers as a unique part of the message and all the norms that apply for a normal message body content will apply.

3 3