May 2009 - Ietf-types - alvestrand.no

specific mime-types for MathML3 ?
by Paul Libbrecht 21 Jun '09

21 Jun '09

Hello mime-types experts, in the W3C Math working group, a hot debate is happening about the types of content. MathML defines two types of content in its specification, MathML- content and MathML-presentation. They are both specified in the same spec which also offers ways to combine them. In the future chapter 6 (draft at http://monet.nag.co.uk/~dpc/draft-spec/chapter6.html ), one can see that the need arises to qualify MathML objects of the two different types with a different name on the clipboard and this is agreed upon in the group. What is not agreed upon is whether the final spec should include a form for just one generic mime-type or three so as to allow negotiation similar to the clipboard: - application/presentation+mathml+xml - application/content+mathml+xml - application/mathml+xml The two first are the specific types, the last one is the generic type; our registration would append the form(s) at RFC 4288 within a normative part in the MathML spec. It's pretty clear we shall specify that the generic type should always be offered if a specific type is offered and, similarly, the generic type should be delivered if it's not clear that the specific type is supported. We do not have yet a big set of scenarios that depend on a content- negotiation where the knowledge of a specific mime-type is the sole enabler instead of "just accepting any MathML and try to do your best with it". Here are my questions: - do you see any danger in having three mime-types if we have the provision above? - is there a chance our registration for three mime-types is rejected for other reasons? thanks in advance paul

4 10

Review of audio media type for IP-MR speech codec
by Roni Even 26 May '09

26 May '09

Hi, The AVT working group requests media type review for the ip-mr_v2.5 media subtype defined in section 5.1 of http://tools.ietf.org/html/draft-ietf-avt-rtp-ipmr-04 . This draft is currently in AVT working group last call. We would be grateful if any comments could be made by June 16th . Thanks, Roni Even (AVT co-chair)

1 0

Registration request for MIME media type tag 3gpp-ims+xml
by John M Meredith 21 May '09

21 May '09

This proposed registration is being distributed to this list (ietf-types(a)iana.org) for preliminary review, in accordance with the instructions given by IANA. It is cc'ed, as suggested by IANA, to Chris Newman. It is also cc'ed to 3GPP delegates to TSG CT WG1 (http://www.3gpp.org/tb/home.htm, http://www.3gpp.org/tb/CT/CT1/CT1.htm) who have a technical interest in the matter. Best regards John M Meredith 3GPP Specifications Manager, ETSI ======================================================================== ======================================== > Name : John M Meredith (3GPP Specifications Manager) > Email : john.meredith&etsi.org > > > MIME media type name: > Application > > MIME subtype name: > 3gpp-ims+xml > > Required parameters: > None > > Optional parameters: > "charset" the parameter has identical semantics to the charset > parameter of the "application/xml" media type as specified in RFC > 3023 [132]. > "sv" or "schemaversion" the parameter's value is used to indicate: > - the versions of the 3GPP IM CN Subsystem XML schema that can be > used to validate the 3GPP IM CN subsystem XML body (if the MIME > type and parameter are present in the Content-Type header) or > - the accepted versions of the 3GPP IM CN Subsystem XML body (if the > MIME type and parameter are present in the Accept header). > > If the "sv" or "schemaversion" parameter is absent, it shall be > assumed that version 1 of the XML Schema for the IM CN subsystem > XML body is supported. > > This registration entry includes ABNF that modifies the m-parameter > definition in RFC 3261 [26]. m-parameter allows for > attribute/value pairs that are applicable to the media range. In > particular, the ABNF below is given for a media range > application/3gpp-ims+xml specific m-parameter. > > m-parameter /= ("sv" / "schemaversion") EQUAL LDQUOT [ sv-value- > list ] RDQUOT > sv-value-list = sv-value-range *( "," sv-value ) sv-value-range = > sv-value [ "-" sv-value ] > sv-value = number / token > number = 1*DIGIT [ "." 1*DIGIT ] > > Encoding considerations: > Same as encoding considerations of application/xml as specified in RFC > 3023 [132] > > Security considerations: > 3GPP has defined mechanisms for ensuring the privacy and integrity > protection of the bodies of SIP messages used in the 3GPP IM CN > Subsystem. > > Interoperability considerations: > This content type provides a format for exchanging information in SIP > Requests and Responses and used within the 3GPP IM CN Subsystem. > > Published specification: > ETSI TS 124 229 version 8.4.1, being a formal transposition of 3GPP TS 24.229 version 8.4.1: > "Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session > Description Protocol (SDP); Stage 3" > > Available via http://pda.etsi.org/pda/home.asp?wkr=RTS/TSGC-0124229v841 (http://www.3gpp.org/ftp/Specs/html-info/24229.htm) > > Applications which use this media: > Applications that use the 3GPP IM CN Subsystem as defined by 3GPP. > > Additional information : > > 1. Magic number(s) : none > 2. File extension(s) : none > 3. Macintosh file type code : none > 4. Object Identifiers: none > > Application submitted on behalf of the Organizational Partners of > 3GPP. > > Person to contact for further information : > > 1. Name : John M Meredith, 3GPP Specifications Manager > 2. Email : john.meredith&etsi.org > > > Intended usage: > This content type provides a format for exchanging information in SIP > Requests and Responses as used within the 3GPP IM CN Subsystem. > > Author/Change controller : 3GPP Specifications Manager via > www.3gpp.org > Technical contact: jbakker&rim.com >

3 4

Should we register each individual MIME type or a family?
by Rosen, Brian 19 May '09

19 May '09

I work with NENA, the North American Number Association. We're engaged in a standards effort for "Next Generation 9-1-1", moving the emergency call system to an IP network. Our work is based on IETF work, and uses SIP Event Notification (RFC3265). We need to define event packages for use within private IP networks connecting public safety agencies, and we do not expect use of these packages to escape into the wild. As a practical matter, defining an event package means defining one or more XML structures that are passed in the event subscription and/or notification. These structures are passed in SIP bodies, and thus need MIME types, typically within the application tree. We will request registration using a prefix of vnd.nena. My question is whether to register each of these MIME types individually with IANA, or register a subtree (vnd.nena.ng911) and create a registry in NENA for the subtree (vnd.nena.ng911.queuestate). I would appreciate advise on that subject. We would expect a dozen or so event packages. We will also need some other MIME types for other SIP related use, for which similar issues apply. NENA is creating a registry management service not unlike a very small IANA, that could manage the subname space if that was deemed appropriate. Brian

2 1

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