Network Working Group P. Frojdh, U. Lindgren, and M. Westerlund INTERNET-DRAFT Ericsson draft-lindgren-mime-dls-smf-00 Feb 9 2004 Expires: Aug 9 2004 MIME Type Registrations for Standard MIDI Files and Downloadable Sounds Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is an individual submission to the IETF. Comments should be directed to the author. Abstract This document serves to register and document standard MIME types for Standard MIDI Files, Scalable Polyphonic MIDI and Downloadable Sounds. Frojdh, Lindgren and Westerlund [Page 1]
INTERNET-DRAFT draft-lindgren-mime-dls-smf-00 Feb 9, 2004 TABLE OF CONTENTS 1. Conventions Used..............................................3 2. Introduction..................................................3 3. Security Considerations.......................................3 4. IANA Considerations...........................................4 4.1 Standard MIDI Files.......................................4 4.2 Scalable Polyphonic MIDI..................................6 4.3 Downloadable Sound........................................7 5. RFC Editor Considerations.....................................8 6. Authors' addresses............................................8 7. References....................................................8 Full Copyright Statement.........................................9 Intellectual Property Notice.....................................10 Frojdh, Lindgren and Westerlund [Page 2]
INTERNET-DRAFT draft-lindgren-mime-dls-smf-00 Feb 9, 2004 1 Conventions Used The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2 Introduction The present draft seeks to register MIME types for Standard MIDI Files (SMF) and Downloadable Sounds (DLS). The SMF format is used to encapsulate a protocol termed Musical Instrument Digital Interface (MIDI). SMF is defined in [RP-001] and is associated with the standards [GM1, GM2, GML, SP-MIDI]. The DLS format is used to define instruments for widely used wavetable synthesizers associated with the standards [DLS1, DLS2, MDLS]. The SMF, DLS, and their associated standards are maintained and defined by two organizations, the MIDI Manufacturers Association (MMA) and the Association of the Musical Electronics Industry (AMEI). The MIME types defined here are needed to correctly identify SMF and DLS files when they are served over HTTP, included in multi-part documents, or used in other places where MIME types are used. In addition a de-facto MIME type linked to SP-MIDI is also defined here. 3 Security Considerations The SMF format may contain audio, displayable text data, and commands for controlling devices such as synthesizers, recorders, stage lights, etc. There is currently no provision for 'active' elements (such as scripts) of any kind. Clearly it is possible to author malicious files (or badly authored) which, for example, attempt to set synthesizers in a non-desired state, e.g. start oscillators without ending them. The DLS format may contain audio, displayable text data, and modeling parameters (a.k.a. articulation parameters). In addition, the DLS format contains a so-called conditional chunk which is 'active' in the sense that it affects the execution of a DLS file parser. However, the DLS format does not currently define any scripting mechanism. Clearly it is possible to author malicious files which, for example, contain large amounts of data always blocked by a conditional statement, i.e. no synthesizer loads the instruments. However, for both SMF and DLS, clients can and usually protect themselves against these kinds of attacks. In the case of a badly authored SMF a good practice it to reset MIDI capable synthesizer by Frojdh, Lindgren and Westerlund [Page 3]
INTERNET-DRAFT draft-lindgren-mime-dls-smf-00 Feb 9, 2004 an appropriate command, e.g. 'All Sound Off' on all MIDI channels. When the reset action, if any, is made, will eventually be up to the implementation, a suggestion is at playback termination. Here playback termination can be at the end of an SMF or at termination of a player application or both. In the case of DLS content containing conditional chunks it is stressed that the chunk in question is optional, that is to say a parser do not have to execute this chunk. However, if a parser evaluates a conditional chunk it is still possible to parse the content and from that draw conclusion if the content is usable for a particular synthesizer engine. It should be noted that selected metadata fields may include information partly intended to protect the media against unauthorized use or distribution. In this case the intention is that alteration or removal of the data in the field would be treated as an offence under national agreements based on World Intellection Property Organization (WIPO) treaties. Both DLS and SMF have extensible structures, so that it is theoretically possible that metadata fields or media formats could be defined in the future which could be used to induce particular actions on the part of the recipient, thus presenting additional security risks. However, this type of capability is currently not supported in the referenced specifications. There is no current provision in the SMF and DLS standards for encryption, signing, or authentication within the file formats. 4 IANA Considerations The present document registers the MIME types audio/midi, audio/sp- midi and audio/dls. The MIME types audio/midi and audio/dls support an optional parameter. This registration applies to all files defined as using the 'DLS' and/or 'SMF' file formats. The usual file suffixes for 'DLS' and 'SMF' are ".dls " and ".mid", respectively. 4.1 Standard MIDI Files The MIME type supports an optional parameter, which serves the purpose to more specifically inform a client of the type of content provided. The parameter is a comma-separated list of numbers. Each number corresponds to what client capabilities the file addresses. The default value for this parameter is a list with one element equal to zero. Any unspecified numbers shall be ignored. A file can be authored to behave well on players for General MIDI Level 2 and Scalable polyphonic MIDI and the list is then 2,4. The last defined value (5) corresponds to non-standard content. Frojdh, Lindgren and Westerlund [Page 4]
INTERNET-DRAFT draft-lindgren-mime-dls-smf-00 Feb 9, 2004 MIME media type name: audio MIME subtype names: midi Required parameters: none Optional parameters: 'midi-type' A comma-separated list of the midi types that this content conforms to, with the following specified values: 0, 1, 2, 3, 4, and 5 signify General MIDI content, General MIDI Level 1 content, General MIDI Level 2 content, General MIDI Light content, SP- MIDI content, and, MIDI non- specific, respectively. If the parameter is not specified the content is General MIDI (0). Any unknown values SHALL be ignored. Encoding considerations: files are binary and should be transmitted in a suitable encoding without CR/LF conversion, 7-bit stripping etc.; base64 is a suitable encoding. Note that this MIME type is used only for files; separate types are used for real- time transfer, such as for the RTP payload format for MIDI, [Draft1]. Security considerations: see the security considerations section in RFC XXXX. Interoperability considerations: Published specification: General MIDI Level 1, General MIDI Level 2, General MIDI Light and Scalable Polyphonic MIDI. MMA specifications can be ordered from the MMA web site, www.midi.org. Applications which use this media type: Multi-media Additional information: Magic number(s): None. However, a file always begin with the hexadecimal number 4d546864. File extension(s): .mid is declared at http://www.nist.gov/nics Macintosh File Type Code(s): Not defined. Person & email address to contact for further information: Ulf A. Lindgren, ulf.a.lindgren@ericsson.com Intended usage: COMMON Frojdh, Lindgren and Westerlund [Page 5]
INTERNET-DRAFT draft-lindgren-mime-dls-smf-00 Feb 9, 2004 Change controller: Ulf A. Lindgren 4.2 Scalable Polyphonic MIDI SP-MIDI is distributed in an SMF which can be identified via the MIME type defined in section 4.1. "audio/sp-midi" is in fact equivalent to "audio/midi; midi-type=4". However, SP-MIDI is already referred to as the MIME type audio/sp-midi elsewhere, and to incorporate this practice the following definition is provided. It is recommended that if audio/sp-midi is supported then 'audio/midi' should be supported too. MIME media type name: audio MIME subtype names: sp-midi Required parameters: none Optional parameters: none Encoding considerations: files are binary and should be transmitted in a suitable encoding without CR/LF conversion, 7-bit stripping etc.; base64 is a suitable encoding. Note that this MIME type is used only for files; separate types are used for real- time transfer, such as for the RTP payload format for MIDI, [Draft1] Security considerations: see the security considerations section in RFC XXXX. Interoperability considerations: This MIME type is registered to support already deployed usage, however any implementation SHOULD also support the "audio/midi" MIME type. It is intended that the "audio/sp-midi" MIME type is deprecated in the future. Published specification: Scalable Polyphonic MIDI. MMA specifications can be ordered from the MMA web site, www.midi.org. Applications which use this media type: Multi-media Additional information: Magic number(s): None. However, the file always begins with the hexadecimal number 4d546864. File extension(s): .mid is declared at http://www.nist.gov/nics Macintosh File Type Code(s): Not defined. Frojdh, Lindgren and Westerlund [Page 6]
INTERNET-DRAFT draft-lindgren-mime-dls-smf-00 Feb 9, 2004 Person & email address to contact for further information: Ulf A. Lindgren, ulf.a.lindgren@ericsson.com Intended usage: COMMON Change controller: Ulf A. Lindgren 4.3 Downloadable Sound The MIME type supports an optional parameter, which serves the purpose to more specifically inform a client of the type of content provided. The parameter is a comma-separated list of numbers. Each number corresponds to what client capabilities the file addresses. The default value for this parameter is a list with one element equal to zero. Any unspecified number shall be ignored. A file can be authored to behave well on a system for Downloadable Sounds 1.1 and Downloadable Sounds 2.1 and the list is then 0,1. MIME media type name: audio MIME subtype name: dls Required parameters: none Optional parameters: 'dls-type' A comma-separated list of the midi types that this content conforms to, with the following specified values: 0, 1, and 2 signify Downloadable Sounds Level 1.1 content, Downloadable Sounds Level 2.1 content, Mobile Downloadable Sound content, respectively. If the parameter is not specified the content is Downloadable Sound level 1.1 (0). Any unknown values SHALL be ignored. Encoding considerations: files are binary and should be transmitted in a suitable encoding without CR/LF conversion, 7-bit stripping etc.; base64 is a suitable encoding. Note that this MIME type is used only for files. Security considerations: see the security considerations section in RFC XXXX. Interoperability considerations: Published specification: Downloadable Sounds Level 1.1, Downloadable Sounds Level 2.1, and Mobile Downloadable Sounds. MMA specifications can be ordered from the MMA web site, www.midi.org. Applications which use this media type: Multi-media Frojdh, Lindgren and Westerlund [Page 7]
INTERNET-DRAFT draft-lindgren-mime-dls-smf-00 Feb 9, 2004 Additional information: Magic number(s): None. However, the ninth to twelfth bytes of the file must equal (in hexadecimal notation) 44, 4c, 53, and 20, respectively. File extension(s): .dls is declared at http://www.nist.gov/nics Macintosh File Type Code(s): Not defined. Person & email address to contact for further information: Ulf A. Lindgren, ulf.a.lindgren@ericsson.com Intended usage: COMMON Change controller: Ulf A. Lindgren 5 RFC Editor Considerations The references to RFC XXXX in the MIME registrations need to be replaced with the actual RFC number when it is issued. 6 Authors' Addresses Per Frojdh Ericsson AB Ericsson Research SE-164 80 Stockholm Sweden electronic mail: per.frojdh@ericsson.com Ulf A. Lindgren Ericsson Mobile Platforms AB Nya Vattentornet SE-221 83 Lund Sweden electronic mail: ulf.a.lindgren@ericsson.com Magnus Westerlund Ericsson AB Ericsson Research SE-164 80 Stockholm Sweden electronic mail: magnus.westerlund@ericsson.com 7 References Normative: [DLS1] "Downloadable Sounds Level 1", MMA/AMEI specification v1.0, Los Angeles, CA, USA, 1997. Frojdh, Lindgren and Westerlund [Page 8]
INTERNET-DRAFT draft-lindgren-mime-dls-smf-00 Feb 9, 2004 [DLS2] "Downloadable Sounds Level 2.1", MMA/AMEI specification v1.0, Los Angeles, CA, USA, 2001. [MDLS] "Mobile Downloadable Sounds 1.0", MMA specification v1.0, Los Angeles, CA, USA, 2004. [RP-001] "Standard MIDI File", recommended practice #001 MMA/AMEI specification v1.0, Los Angeles, CA, USA, 1991 [GM1] "The complete MIDI 1.0 Detailed Specification", MMA/AMEI specification v1.0, Los Angeles, CA, USA. 1991 [GM2] "General MIDI level 2", MMA/AMEI specification v1.0, Los Angeles, CA, USA, 1999 [GML] "General MIDI Lite", MMA/AMEI specification v1.0, Los Angeles, CA, USA. 2001 [SP-MIDI] "Scalable polyhony MIDI specification", MMA/AMEI specification v1.0, Los Angeles, CA, USA. 2002 [SPM prof] "Scalable polyhony {MIDI} device 5-24 Note profile for 3GPP", MMA/AMEI specification v1.0, Los Angeles, CA, USA, 2002 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. Informative: [Draft1] draft-ietf-avt-rtp-midi-format-01.txt Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be Frojdh, Lindgren and Westerlund [Page 9]
INTERNET-DRAFT draft-lindgren-mime-dls-smf-00 Feb 9, 2004 followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property Notice The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. This Internet-Draft expires in August 2004. Frojdh, Lindgren and Westerlund [Page 10]