November 2004 - Ietf-types

MIME Type Review for KPML MIME Types
by Eric Burger 20 Jan '05

20 Jan '05

KPML is in the process of WGLC in the SIPPING work group. KPML defines two new MIME types, application/kpml-request+xml and application/kpml-response+xml . We would greatly appreciate expert review of the definition and usage of these new types. The draft lives at: http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-06.txt Thanks. -- Eric Burger

2 1

Testing the waters for text/troff
by Bruce Lilly 06 Dec '04

06 Dec '04

I am quite surprised that there is no registered MIME media type for text with nroff/troff markup, especially as that format has traditionally been used for RFC and Internet Draft documents (RFC 2223). I could find no record in the archives of this mailing list of any discussion on the matter. Has there been any proposal for such a text subtype, and if so, what were the reasons that have prevented it from being approved?

6 14

MIME Type Review Request: image/svg+xml
by Chris Lilley 24 Nov '04

24 Nov '04

Please review the Media Type registration template described below. It is available in HTML [1] or in plain text form [2] and relates to the SVG specification [3]. Registration of this Media Type in the standards tree is requested, in conformance with [4] and [5]. [1] http://www.w3.org/TR/SVG12/mimereg.html [2] http://www.w3.org/TR/SVG12/mimereg.html,text [3] http://www.w3.org/TR/SVG12/ [4] http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt [5] http://www.w3.org/2002/06/registering-mediatype Registration of Media Type image/svg+xml MIME media type name: image MIME subtype name: svg+xml Required parameters: None. Optional parameters: None The encoding of an SVG document is determined by the XML encoding declaration. This has identical semantics to the application/xml media type in the case where the charset parameter is omitted, as specified in [6]RFC3023 sections 8.9, 8.10 and 8.11. [6] http://www.w3.org/TR/SVG12/references Encoding considerations: Same as for application/xml. See [7]RFC3023 , section 3.2. [7] http://www.w3.org/TR/SVG12/references Restrictions on usage: None Security considerations: As with other XML types and as noted in [8]RFC3023 section 10, repeated expansion of maliciously constructed XML entities can be used to consume large amounts of memory, which may cause XML processors in constrained environments to fail. [8] http://www.w3.org/TR/SVG12/references SVG documents may be transmitted in compressed form using gzip compression. For systems which employ MIME-like mechanisms, such as HTTP, this is indicated by the Content-Transfer-Encoding header; for systems which do not, such as direct filesystem access, this is indicated by the filename extension and by the Macintosh File Type Codes. In addition, gzip compressed content is readily recognised by the initial byte sequence as described in [9]RFC1952 section 2.3.1. [9] http://www.w3.org/TR/SVG12/references Several SVG elements may cause arbitrary URIs to be referenced. In this case, the security issues of [10]RFC2396, section 7, should be considered. [10] http://www.w3.org/TR/SVG12/references In common with HTML, SVG documents may reference external media such as images, audio, video, style sheets, and scripting languages. Scripting languages are executable content. In this case, the security considerations in the Media Type registrations for those formats apply. In addition, because of the extensibility features for SVG and of XML in general, it is possible that "image/svg+xml" may describe content that has security implications beyond those described here. However, if the processor follows only the normative semantics of this specification, this content will be outside the SVG namespace and will be ignored. Only in the case where the processor recognizes and processes the additional content, or where further processing of that content is dispatched to other processors, would security issues potentially arise. And in that case, they would fall outside the domain of this registration document. Interoperability considerations: This specification describes processing semantics that dictate behavior that must be followed when dealing with, among other things, unrecognized elements and attributes, both in the SVG namespace and in other namespaces. Because SVG is extensible, conformant "image/svg+xml" processors must expect that content received is well-formed XML, but it cannot be guaranteed that the content is valid to a particular DTD or Schema or that the processor will recognize all of the elements and attributes in the document. SVG has a published Test Suite and associated implementation report showing which implementations passed which tests at the time of the report. This information is periodically updated as new tests are added or as implementations improve. Published specification: This media type registration is extracted from Appendix G of the SVG 1.2 specification. Additional information: Person & email address to contact for further information: Dean Jackson, (dean(a)w3.org) Intended usage: COMMON Author/Change controller: The SVG specification is a work product of the World Wide Web Consortium's SVG Working Group. The W3C has change control over these specifications. -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group Member, W3C Technical Architecture Group

3 9

XMF mime type
by jeanluc borla 20 Nov '04

20 Nov '04

Hi, Could someone give me infos about XMF (0,1,2) mime types. It seems that XMF 0,1,2 correspond to MIDI type 0 (no track data), 1 (track data), 2 (DLS). They all should have same mime type but it's my understanding that several mime type exist, which are: audio/mobile-xmf, audio/x-xmf, audio/xmf and perhaps audio/x-midi The models which support XMF are: Sendo X, Siemens SX1, Motorola A1000, Motorola E 1000 So could you tell me what mime type correspond to each XMF format and each model mobile Best Regards, Jean Luc Borla

1 0

MIME types for preliminary community review
by Paul Sandoz 19 Nov '04

19 Nov '04

Hi, Attached are three MIME types for prelimiary community review before registration. Any feedback would be most welcome. I understand the new 'Media Type Specifications and Registration Procedures' [1], which obsoletes RFC 2048, is in effect even though no new RFC number has been assigned. The MIME types are specified in the following: ITU-T Rec. X.891 | ISO/IEC 24824-1 (Fast Infoset) [2] ITU-T Rec. X.892 | ISO/IEC 24824-2 (Fast Web Services) [3] both of which are Final Committee Drafts under ballot in ISO. The ballot finishes on the 1st Feb 2005. If there are any changes required as a result of review then i can incorporate these into an ISO ballot comment. I plan to sumbit the MIME types to IANA (iana(a)iana.org) in about 2 weeks time. Thanks, Paul. [1] http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt [2] http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=4132… [3] http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=4132… -- | ? + ? = To question ----------------\ Paul Sandoz x38109 +33-4-76188109 MIME media type name: application MIME subtype name: soap+fastinfoset Required parameters: None. Optional parameters: "action": This parameter shall be used to identify the intent of the W3C SOAP message infoset as specified for the "action" parameter of the W3C SOAP 1.2 "application/soap+xml" MIME media type (see W3C SOAP 1.2 Part 2, Appendix A). The value of the "action" parameter shall be an absolute URI-reference as specified in IETF RFC 2396. No restriction shall be placed on the specificity of the URI or that it is resolvable. Encoding considerations: This media type is used to identify W3C SOAP message infosets serialized as fast infoset documents as specified in ITU-T Rec. X.892 | ISO/IEC 24824-2. Use of this MIME media type will require additional specification if used on transports that do not provide 8-bit binary transparency. (For the purposes of Fast Web Services, ITU-T Rec. X.892 | ISO/IEC 24824-2, this media type is always used with HTTP as the transport mechanism, and no further specification is needed.) Security considerations: Because W3C SOAP message infosets can carry application defined data whose semantics is independent from that of any MIME wrapper (or context within which the MIME wrapper is used), one should not expect to be able to understand the semantics of the W3C SOAP message infoset based on the semantics of the MIME wrapper alone. Therefore, whenever using the "application/soap+fastinfoset" media type, it is strongly recommended that the security implications of the context within which the W3C SOAP message infoset is used is fully understood. The security implications are likely to involve the specific SOAP binding to an underlying protocol as well as the application-defined semantics of the data carried in the W3C SOAP message infoset. Interoperability considerations: There are no known interoperability issues. Published specification: ITU-T Rec. X.892 | ISO/IEC 24824-2 Applications which use this media type: No known applications that use this media type. Additional information: Magic number(s): A W3C SOAP message infoset serialized as a fast infoset document may begin with one of the following byte sequences: - a byte sequence that corresponds to a UTF-8 encoded XML declaration of the string "<?xml version='1.0' encoding='finf'", the first five bytes of which are hexadecimal 3C 3F 78 6D 6C; - a byte sequence that corresponds to a UTF-8 encoded XML declaration of the string "<?xml version='1.1' encoding='finf'", the first five bytes of which are also hexadecimal 3C 3F 78 6D 6C; - a byte sequence of hexadecimal E0 00 00 01. File extension(s): W3C SOAP message infosets serialized as fast infoset documents are not required or expected to be stored as files. Person & email address to contact for further information: ITU-T ASN.1 Rapporteur (contact via tsb(a)itu.int) ISO/IEC JTC1/SC6 ASN.1 Rapporteur (contact via secretariat(a)jtc1sc06.org) Intended usage: COMMON Author/Change controller: Joint ITU-T | ISO/IEC balloting procedures in accordance with ITU-T Rec. A.23 Collaboration with the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) on information technology, Annex A and ISO/IEC JTC1 Directives, Annex K. MIME media type name: application MIME subtype name: fastinfoset Required parameters: None. Optional parameters: None. Encoding considerations: XML infosets encoded as fast infoset documents will result in the production of binary data. This MIME media type may require further encoding on transports not capable of handling binary data. Security considerations: Because XML infosets encoded as fast infoset documents can carry application defined data whose semantics is independent from that of any MIME wrapper (or context within which the MIME wrapper is used), one should not expect to be able to understand the semantics of the fast infoset document based on the semantics of the MIME wrapper alone. Therefore, whenever using the "application/fastinfoset" media type, it is strongly recommended that the security implications of the context within which the fast infoset document is used is fully understood. Interoperability considerations: There are no known interoperability issues. Published specification: ITU-T Rec. X.891 | ISO/IEC 24824-1 Applications which use this media type: No known applications currently use this media type. Additional information: Magic number(s): A fast infoset document may begin with one of the following byte sequences: - a byte sequence that corresponds to a UTF-8 encoded XML declaration of the string "<?xml version='1.0' encoding='finf'", the first five bytes of which are hexadecimal 3C 3F 78 6D 6C; - a byte sequence that corresponds to a UTF-8 encoded XML declaration of the string "<?xml version='1.1' encoding='finf'", the first five bytes of which are also hexadecimal 3C 3F 78 6D 6C; - a byte sequence of hexadecimal E0 00 00 01. File extension(s): *.finf Person & email address to contact for further information: ITU-T ASN.1 Rapporteur (contact via tsb(a)itu.int) ISO/IEC JTC1/SC6 ASN.1 Rapporteur (contact via secretariat(a)jtc1sc06.org) Intended usage: COMMON Author/Change controller: Joint ITU-T | ISO/IEC balloting procedures in accordance with ITU-T Rec. A.23 Collaboration with the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) on information technology, Annex A and ISO/IEC JTC1 Directives, Annex K. MIME media type name: application MIME subtype name: fastsoap Required parameters: None. Optional parameters: "action": This parameter shall be used to identify the intent of the ASN.1 SOAP message as specified for the "action" parameter of the W3C SOAP 1.2 "application/soap+xml" MIME media type (see W3C SOAP 1.2 Part 2, Appendix A). The value of the "action" parameter shall be an absolute URI-reference as specified in IETF RFC 2396. No restriction shall be placed on the specificity of the URI or that it is resolvable. Encoding considerations: This media type is used to identify content that is a value of the ASN.1 Envelope type specified in the ASN1SOAP module of ITU-T Rec. X.892 | ISO/IEC 24824-2, encoded using Basic Aligned Packed Encoding Rule specified in ITU-T Rec. X.691 | ISO/IEC 8825-2. Use of this MIME media type will require additional specification if used on transports that do not provide 8-bit binary transparency. (For the purposes of Fast Web Services, ITU-T Rec. X.892 | ISO/IEC 24824-2, this media type is always used with the Basic Aligned Packed Encoding Rule and with HTTP as the transport mechanism, and no further specification is needed.) Security considerations: Because ASN.1 SOAP messages can carry application-defined data whose semantics is independent from that of any MIME wrapper (or context within which the MIME wrapper is used), one should not expect to be able to understand the semantics of the ASN.1 SOAP message based on the semantics of the MIME wrapper alone. Therefore, whenever using the "application/fastsoap" media type, it is strongly recommended that the security implications of the context within which the ASN.1 SOAP message is used is fully understood. The security implications are likely to involve the specific ASN.1 SOAP binding to an underlying protocol as well as the application-defined semantics of the data carried in the ASN.1 SOAP message. Interoperability considerations: There are no known interoperability issues. Published specification: ITU-T Rec. X.892 | ISO/IEC 24824-2 Applications which use this media type: No known applications that use this media type. Additional information: File extension(s): ASN.1 SOAP messages are not required or expected to be stored as files. Person & email address to contact for further information: ITU-T ASN.1 Rapporteur (contact via tsb(a)itu.int) ISO/IEC JTC1/SC6 ASN.1 Rapporteur (contact via secretariat(a)jtc1sc06.org) Intended usage: COMMON Author/Change controller: Joint ITU-T | ISO/IEC balloting procedures in accordance with ITU-T Rec. A.23 Collaboration with the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) on information technology, Annex A and ISO/IEC JTC1 Directives, Annex K.

4 4

Review of update of text/t140
by Allison Mankin 18 Nov '04

18 Nov '04

The IESG has received a request for publication of draft-ietf-avt-rfc2793bis-09.txt, which includes updating the registration of text/t140. This a minor update, primarily to include an optional parameter, cps. Please consider giving a review of the update, in parallel with the IETF Last Call. Thanks, Allison

1 0

Updated MIME type proposal for 3GPP DRM RTP payload format
by Magnus Westerlund 15 Nov '04

15 Nov '04

Hi, Based on some of the feedback received on this list, I have included a proposal for an updated MIME type definition for 3GPP TS 26.234 Annex K. I have not defined a procedure for defining a single media type (application) and then secondary used media types that are indicated in SDP. The reason is that I think it makes it more difficult to find these in the registry. Also being the first doing this in a non IETF document seems to be problematic. Also having a lot of discussion and changing things for a basically approved specification is difficult. I think that 3GPP can suffice using the so far done IETF procedures. Changes done: - Renamed sub type name: rtp.enc.aescm128 to rtp-enc-aescm128 - Removed media type "image" and "application" Any feedback is desired as quickly as possible. The 3GPP SA4 which owns this specification will meet next week, and any feedback received before next Wednesday will be much simpler to incorporate. Sorry for the short heads up. Thanks Magnus ---- START OF MEDIA TYPE ---- MIME media type name: audio, video, text MIME subtype name: rtp-enc-aescm128 Required parameters: opt: The payload type number of the payload type contained in the encrypted payload. An integer value between 0-127. rate: The timestamp rate of this payload type, which shall be the same as that of the original payload type. This is an integer value between 1 and 2^32. ContentID: The OMA DRM content ID [75] used to identify the content when establishing a crypto context. The value is an RFC 2396 [60] URI, which shall be quoted using <">. RightsIssuerURL: The right issuer URL as defined by OMA DRM [75]. The value is an URI in accordance with RFC 2396 [60], which shall be quoted using <">. IVnonce: The value of this parameter is the nonce that forms the IV as specified by the crypto transform, encoded using Base 64 [69]. Optional parameters: SelectiveEncryption: Indicates if this stream is selectively encrypted. Allowed values are 0 (false) and 1 (true). If not present, selective encryption shall not be used. Please note that unless this indicator is integrity protected, it fulfils no purpose. Encoding considerations: This type is only defined for transfer via RTP (RFC 3550). Security considerations: See considerations raised in RTP RFC 3550 [9] and any applicable profile like RFC 3551 [10] or RFC 3711 [72]. Further see 3GPP TS 26.234, Release 6, Annex K for comments on security issues. The main issues that exists are: - This RTP payload format only confidentiality protects the RTP payload, thus header information is leaked, similarly to SRTP. - The use of stream ciphers as AES CM and no integrity protection allows an attacker to purposefully attack the content of the encrypted RTP payload by switching individual bits. - The usage of selective encryption without integrity protection allows for an attacker to perform any replacements of complete RTP payloads and packets it desires. - The payload format makes the receiver vulnerable to denial of service attacks that inserts RTP packets into the stream, that the receiver then interprets as being encrypted thus wasting computational resources. To prevent this attack, authentication needs to be used. Interoperability considerations: Published specification: 3GPP TS 26.234, Release 6. Open Mobile Alliance DRM Content Format V2.0 Applications which use this media type: Third Generation Partnership Project (3GPP) Packet-switched Streaming Service (PSS) clients and servers, which supports the Open Mobile Alliance's specification of Digital Rights Management version 2.0. Additional information: Magic number(s): N/A File extension(s): N/A Macintosh File Type Code(s): N/A Person & email address to contact for further information: magnus.westerlund(a)ericsson.com Intended usage: Common Author/Change controller: 3GPP TSG SA ---- END OF MEDIA TYPE ---- Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund(a)ericsson.com

1 0

RE: MIME Type Review Request: text/CSTA-type
by Onno Elzinga 09 Nov '04

09 Nov '04

Dear reviewers, Thanks for your constructive feedback. Task Group 11 has reviewed your comments and agrees that both MIME types are meant for machines. Therefore they propose to change the second MIME type from "text/CSTA-types" to "application/CSTAdata+xml". Hope this helps. We are meeting all week, so we would appreciate your speedy feedback. Thanks, Onno. -----Original Message----- From: Bruce Lilly [mailto:blilly@erols.com] Sent: Saturday, November 06, 2004 6:22 PM To: ietf-types(a)alvestrand.no Cc: Onno Elzinga; 'ietf-types(a)alvestrand.no'; 'sah(a)428cobrajet.net'; Hollenbeck, Scott Subject: Re: MIME Type Review Request: text/CSTA-type On Tue November 2 2004 08:54, Hollenbeck, Scott wrote: > Please review the MIME type registration template described below. The IESG > has received a request to register this MIME type in the standards tree. It > is a product of Ecma International. A URL for the formal specification is > included in the template. > > -Scott- > ---------- > MIME media type name: text > > MIME subtype name: CSTA-type [...] > Security considerations: > This content type is designed to carry CSTA data types over network > protocols. Appropriate precautions should be taken to insure that > applications observing these CSTA objects are authorized to do so. [...] > Applications which use this media type: > The text/CSTA-type MIME type is used to carry CSTA data types specified in > CSTA XML (ECMA-323) over various types of network protocols. > > Additional information: > CSTA XML (ECMA-323) is an application level protocol that enables an > application to control and observe communications involving various types of > media (voice calls, video calls, instant messages, Email, SMS, Page, etc.) > and devices associated with the media. Why is this being proposed for registration in the text media type tree? As far as I can tell, this media type appears to be an application data format containing control data, not textual information (in the sense of the use of "text" in the MIME standards (RFC 2046) and Internet Best Current Practice (RFC 2277): RFC 2046: The five discrete top-level media types are: (1) text -- textual information. The subtype "plain" in particular indicates plain text containing no formatting commands or directives of any sort. Plain text is intended to be displayed "as-is". No special software is required to get the full meaning of the text, aside from support for the indicated character set. Other subtypes are to be used for enriched text in forms where application software may enhance the appearance of the text, but such software must not be required in order to get the general idea of the content. Possible subtypes of "text" thus include any word processor format that can be read without resorting to software that understands the format. In particular, formats that employ embeddded binary formatting information are not considered directly readable. A very simple and portable subtype, "richtext", was defined in RFC 1341, with a further revision in RFC 1896 under the name "enriched". RFC 2277: All human-readable text has a language. Many operations, including high quality formatting, text-to-speech synthesis, searching, hyphenation, spellchecking and so on benefit greatly from access to information about the language of a piece of text. [WC 3.1.1.4]. Humans have some tolerance for foreign languages, but are generally very unhappy with being presented text in a language they do not understand; this is why negotiation of language is needed. In most cases, machines will not be able to deduce the language of a transmitted text by themselves; the protocol must specify how to transfer the language information if it is to be available at all. The interaction between language and processing is complex; for instance, if I compare "name-of-thing(lang=en)" to "name-of- thing(lang=no)" for equality, I will generally expect a match, while the word "ask(no)" is a kind of tree, and is hardly useful as a command verb. 4.2. Requirement for language tagging Protocols that transfer text MUST provide for carrying information about the language of that text. Buried in an Annex in the 530-page referenced ECMA document one finds: This annex specifies a schema for CSTA data types that can be used to encapulatate CSTA data objects so that they can be carried over various types of network protocols such as SIP. A specific MIME media type, text/CSTA-type is designed to contain these data objects. The formats of the data types are specified in Clause 9. I can see nothing in the proposed media type registration or in the referenced document that indicates that the media type is to be used to convey human-readable natural language text as opposed to application-specific data type, nor do I see any provision for carrying information about language of text as required by RFC 2277. A concrete example of how the proposed media type would be used to convey human-readable text in some specified language would help to provide justification for registration of the proposed subtype in the text media type tree.

1 0

MIME Type Review Request: text/CSTA-type
by Hollenbeck, Scott 06 Nov '04

06 Nov '04

Please review the MIME type registration template described below. The IESG has received a request to register this MIME type in the standards tree. It is a product of Ecma International. A URL for the formal specification is included in the template. -Scott- ---------- MIME media type name: text MIME subtype name: CSTA-type Required parameters: (none) Optional parameters: (none) Encoding considerations: This content type uses XML, employing UTF-8 character encoding. Security considerations: This content type is designed to carry CSTA data types over network protocols. Appropriate precautions should be taken to insure that applications observing these CSTA objects are authorized to do so. Interoperability considerations: text/CSTA-type documents are specified by the XML schemas standardized in ECMA-323. Published specification: The published Standard ECMA-323 is available at: http://www.ecma-international.org/publications/standards/Ecma-323.htm Applications which use this media type: The text/CSTA-type MIME type is used to carry CSTA data types specified in CSTA XML (ECMA-323) over various types of network protocols. Additional information: CSTA XML (ECMA-323) is an application level protocol that enables an application to control and observe communications involving various types of media (voice calls, video calls, instant messages, Email, SMS, Page, etc.) and devices associated with the media. Person & email address to contact for further information: Ecma Secretariat Rue du Rhone114 CH-1204 Geneva Switzerland secretariat(a)ecma-international.org Intended usage: common Author/change controller: The ECMA-323 Standard is developed and maintained by the Ecma TC32/TG11 Working Group.

3 2

Re: MIME Type Review Request: text/CSTA-type
by Martin Duerst 04 Nov '04

04 Nov '04

Question/comment: Why does this registration not use the -xml converntion? Regards, Martin. At 22:54 04/11/02, Hollenbeck, Scott wrote: >Please review the MIME type registration template described below. The IESG >has received a request to register this MIME type in the standards tree. It >is a product of Ecma International. A URL for the formal specification is >included in the template. > >-Scott- >---------- >MIME media type name: text > >MIME subtype name: CSTA-type > >Required parameters: (none) > >Optional parameters: (none) > >Encoding considerations: >This content type uses XML, employing UTF-8 character encoding. > >Security considerations: >This content type is designed to carry CSTA data types over network >protocols. Appropriate precautions should be taken to insure that >applications observing these CSTA objects are authorized to do so. > >Interoperability considerations: >text/CSTA-type documents are specified by the XML schemas standardized in >ECMA-323. > >Published specification: >The published Standard ECMA-323 is available at: >http://www.ecma-international.org/publications/standards/Ecma-323.htm > >Applications which use this media type: >The text/CSTA-type MIME type is used to carry CSTA data types specified in >CSTA XML (ECMA-323) over various types of network protocols. > >Additional information: >CSTA XML (ECMA-323) is an application level protocol that enables an >application to control and observe communications involving various types of >media (voice calls, video calls, instant messages, Email, SMS, Page, etc.) >and devices associated with the media. > >Person & email address to contact for further information: >Ecma Secretariat >Rue du Rhone114 >CH-1204 Geneva >Switzerland >secretariat(a)ecma-international.org > >Intended usage: common > >Author/change controller: >The ECMA-323 Standard is developed and maintained by the Ecma TC32/TG11 >Working Group.

1 0