idnits 2.17.1 draft-lindgren-mime-dls-smf-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'DLS1' -- Possible downref: Non-RFC (?) normative reference: ref. 'DLS2' -- Possible downref: Non-RFC (?) normative reference: ref. 'MDLS' -- Possible downref: Non-RFC (?) normative reference: ref. 'RP-001' -- Possible downref: Non-RFC (?) normative reference: ref. 'GM1' -- Possible downref: Non-RFC (?) normative reference: ref. 'GM2' -- Possible downref: Non-RFC (?) normative reference: ref. 'GML' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP-MIDI' == Outdated reference: A later version (-15) exists of draft-ietf-avt-rtp-midi-format-01 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group P. Frojdh, U. Lindgren, and M. Westerlund 2 INTERNET-DRAFT Ericsson 3 draft-lindgren-mime-dls-smf-00 Feb 9 2004 4 Expires: Aug 9 2004 6 MIME Type Registrations for Standard MIDI Files 7 and Downloadable Sounds 9 Status of this memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or cite them other than as "work in progress". 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/lid-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 This document is an individual submission to the IETF. Comments 30 should be directed to the author. 32 Abstract 34 This document serves to register and document standard MIME types for 35 Standard MIDI Files, Scalable Polyphonic MIDI and Downloadable 36 Sounds. 38 TABLE OF CONTENTS 40 1. Conventions Used..............................................3 42 2. Introduction..................................................3 44 3. Security Considerations.......................................3 46 4. IANA Considerations...........................................4 48 4.1 Standard MIDI Files.......................................4 50 4.2 Scalable Polyphonic MIDI..................................6 52 4.3 Downloadable Sound........................................7 54 5. RFC Editor Considerations.....................................8 56 6. Authors' addresses............................................8 58 7. References....................................................8 60 Full Copyright Statement.........................................9 62 Intellectual Property Notice.....................................10 64 1 Conventions Used 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in RFC 2119 [RFC2119]. 70 2 Introduction 72 The present draft seeks to register MIME types for Standard MIDI 73 Files (SMF) and Downloadable Sounds (DLS). The SMF format is used to 74 encapsulate a protocol termed Musical Instrument Digital Interface 75 (MIDI). SMF is defined in [RP-001] and is associated with the 76 standards [GM1, GM2, GML, SP-MIDI]. The DLS format is used to define 77 instruments for widely used wavetable synthesizers associated with 78 the standards [DLS1, DLS2, MDLS]. The SMF, DLS, and their associated 79 standards are maintained and defined by two organizations, the MIDI 80 Manufacturers Association (MMA) and the Association of the Musical 81 Electronics Industry (AMEI). 83 The MIME types defined here are needed to correctly identify SMF and 84 DLS files when they are served over HTTP, included in multi-part 85 documents, or used in other places where MIME types are used. In 86 addition a de-facto MIME type linked to SP-MIDI is also defined here. 88 3 Security Considerations 90 The SMF format may contain audio, displayable text data, and commands 91 for controlling devices such as synthesizers, recorders, stage 92 lights, etc. There is currently no provision for 'active' elements 93 (such as scripts) of any kind. 95 Clearly it is possible to author malicious files (or badly authored) 96 which, for example, attempt to set synthesizers in a non-desired 97 state, e.g. start oscillators without ending them. 99 The DLS format may contain audio, displayable text data, and modeling 100 parameters (a.k.a. articulation parameters). In addition, the DLS 101 format contains a so-called conditional chunk which is 'active' in 102 the sense that it affects the execution of a DLS file parser. 103 However, the DLS format does not currently define any scripting 104 mechanism. 106 Clearly it is possible to author malicious files which, for example, 107 contain large amounts of data always blocked by a conditional 108 statement, i.e. no synthesizer loads the instruments. 110 However, for both SMF and DLS, clients can and usually protect 111 themselves against these kinds of attacks. In the case of a badly 112 authored SMF a good practice it to reset MIDI capable synthesizer by 113 an appropriate command, e.g. 'All Sound Off' on all MIDI channels. 114 When the reset action, if any, is made, will eventually be up to the 115 implementation, a suggestion is at playback termination. Here 116 playback termination can be at the end of an SMF or at termination of 117 a player application or both. In the case of DLS content containing 118 conditional chunks it is stressed that the chunk in question is 119 optional, that is to say a parser do not have to execute this chunk. 120 However, if a parser evaluates a conditional chunk it is still 121 possible to parse the content and from that draw conclusion if the 122 content is usable for a particular synthesizer engine. 124 It should be noted that selected metadata fields may include 125 information partly intended to protect the media against unauthorized 126 use or distribution. In this case the intention is that alteration or 127 removal of the data in the field would be treated as an offence under 128 national agreements based on World Intellection Property Organization 129 (WIPO) treaties. 131 Both DLS and SMF have extensible structures, so that it is 132 theoretically possible that metadata fields or media formats could be 133 defined in the future which could be used to induce particular 134 actions on the part of the recipient, thus presenting additional 135 security risks. However, this type of capability is currently not 136 supported in the referenced specifications. 138 There is no current provision in the SMF and DLS standards for 139 encryption, signing, or authentication within the file formats. 141 4 IANA Considerations 143 The present document registers the MIME types audio/midi, audio/sp- 144 midi and audio/dls. The MIME types audio/midi and audio/dls support 145 an optional parameter. This registration applies to all files defined 146 as using the 'DLS' and/or 'SMF' file formats. The usual file suffixes 147 for 'DLS' and 'SMF' are ".dls " and ".mid", respectively. 149 4.1 Standard MIDI Files 151 The MIME type supports an optional parameter, which serves the 152 purpose to more specifically inform a client of the type of content 153 provided. The parameter is a comma-separated list of numbers. Each 154 number corresponds to what client capabilities the file addresses. 155 The default value for this parameter is a list with one element equal 156 to zero. Any unspecified numbers shall be ignored. A file can be 157 authored to behave well on players for General MIDI Level 2 and 158 Scalable polyphonic MIDI and the list is then 2,4. The last defined 159 value (5) corresponds to non-standard content. 161 MIME media type name: audio 162 MIME subtype names: midi 163 Required parameters: none 164 Optional parameters: 'midi-type' 165 A comma-separated list of the midi 166 types that this content conforms 167 to, with the following specified 168 values: 0, 1, 2, 3, 4, and 5 169 signify General MIDI content, 170 General MIDI Level 1 content, 171 General MIDI Level 2 content, 172 General MIDI Light content, SP- 173 MIDI content, and, MIDI non- 174 specific, respectively. If the 175 parameter is not specified the 176 content is General MIDI (0). Any 177 unknown values SHALL be ignored. 179 Encoding considerations: files are binary and should be 180 transmitted in a suitable encoding 181 without CR/LF conversion, 7-bit 182 stripping etc.; base64 is a 183 suitable encoding. Note that this 184 MIME type is used only for files; 185 separate types are used for real- 186 time transfer, such as for the RTP 187 payload format for MIDI, [Draft1]. 189 Security considerations: see the security considerations 190 section in RFC XXXX. 192 Interoperability considerations: 193 Published specification: General MIDI Level 1, General MIDI 194 Level 2, General MIDI Light and 195 Scalable Polyphonic MIDI. MMA 196 specifications can be ordered from 197 the MMA web site, www.midi.org. 199 Applications which use this media type: Multi-media 201 Additional information: 202 Magic number(s): None. However, a file always begin 203 with the hexadecimal number 204 4d546864. 205 File extension(s): .mid is declared at 206 http://www.nist.gov/nics 207 Macintosh File Type Code(s): Not defined. 208 Person & email address to contact for further information: 209 Ulf A. Lindgren, 210 ulf.a.lindgren@ericsson.com 211 Intended usage: COMMON 212 Change controller: Ulf A. Lindgren 214 4.2 Scalable Polyphonic MIDI 216 SP-MIDI is distributed in an SMF which can be identified via the MIME 217 type defined in section 4.1. "audio/sp-midi" is in fact equivalent to 218 "audio/midi; midi-type=4". However, SP-MIDI is already referred to as 219 the MIME type audio/sp-midi elsewhere, and to incorporate this 220 practice the following definition is provided. It is recommended that 221 if audio/sp-midi is supported then 'audio/midi' should be supported 222 too. 224 MIME media type name: audio 225 MIME subtype names: sp-midi 226 Required parameters: none 227 Optional parameters: none 228 Encoding considerations: files are binary and should be 229 transmitted in a suitable encoding 230 without CR/LF conversion, 7-bit 231 stripping etc.; base64 is a 232 suitable encoding. Note that this 233 MIME type is used only for files; 234 separate types are used for real- 235 time transfer, such as for the RTP 236 payload format for MIDI, [Draft1] 238 Security considerations: see the security considerations 239 section in RFC XXXX. 241 Interoperability considerations: This MIME type is registered to 242 support already deployed usage, 243 however any implementation SHOULD 244 also support the "audio/midi" MIME 245 type. It is intended that the 246 "audio/sp-midi" MIME type is 247 deprecated in the future. 249 Published specification: Scalable Polyphonic MIDI. MMA 250 specifications can be ordered from 251 the MMA web site, www.midi.org. 253 Applications which use this media type: Multi-media 255 Additional information: 256 Magic number(s): None. However, the file always 257 begins with the hexadecimal number 258 4d546864. 259 File extension(s): .mid is declared at 260 http://www.nist.gov/nics 261 Macintosh File Type Code(s): Not defined. 263 Person & email address to contact for further information: 264 Ulf A. Lindgren, 265 ulf.a.lindgren@ericsson.com 266 Intended usage: COMMON 267 Change controller: Ulf A. Lindgren 269 4.3 Downloadable Sound 271 The MIME type supports an optional parameter, which serves the 272 purpose to more specifically inform a client of the type of content 273 provided. The parameter is a comma-separated list of numbers. Each 274 number corresponds to what client capabilities the file addresses. 275 The default value for this parameter is a list with one element equal 276 to zero. Any unspecified number shall be ignored. A file can be 277 authored to behave well on a system for Downloadable Sounds 1.1 and 278 Downloadable Sounds 2.1 and the list is then 0,1. 280 MIME media type name: audio 281 MIME subtype name: dls 282 Required parameters: none 283 Optional parameters: 'dls-type' 284 A comma-separated list of the midi 285 types that this content conforms 286 to, with the following specified 287 values: 0, 1, and 2 signify 288 Downloadable Sounds Level 1.1 289 content, Downloadable Sounds Level 290 2.1 content, Mobile Downloadable 291 Sound content, respectively. If 292 the parameter is not specified the 293 content is Downloadable Sound 294 level 1.1 (0). Any unknown values 295 SHALL be ignored. 297 Encoding considerations: files are binary and should be 298 transmitted in a suitable encoding 299 without CR/LF conversion, 7-bit 300 stripping etc.; base64 is a 301 suitable encoding. Note that this 302 MIME type is used only for files. 304 Security considerations: see the security considerations 305 section in RFC XXXX. 306 Interoperability considerations: 307 Published specification: Downloadable Sounds Level 1.1, 308 Downloadable Sounds Level 2.1, and 309 Mobile Downloadable Sounds. MMA 310 specifications can be ordered from 311 the MMA web site, www.midi.org. 312 Applications which use this media type: Multi-media 313 Additional information: 314 Magic number(s): None. However, the ninth to 315 twelfth bytes of the file must 316 equal (in hexadecimal notation) 317 44, 4c, 53, and 20, respectively. 318 File extension(s): .dls is declared at 319 http://www.nist.gov/nics 320 Macintosh File Type Code(s): Not defined. 321 Person & email address to contact for further information: 322 Ulf A. Lindgren, 323 ulf.a.lindgren@ericsson.com 324 Intended usage: COMMON 325 Change controller: Ulf A. Lindgren 327 5 RFC Editor Considerations 329 The references to RFC XXXX in the MIME registrations need to be 330 replaced with the actual RFC number when it is issued. 332 6 Authors' Addresses 334 Per Frojdh 335 Ericsson AB 336 Ericsson Research 337 SE-164 80 Stockholm 338 Sweden 339 electronic mail: per.frojdh@ericsson.com 341 Ulf A. Lindgren 342 Ericsson Mobile Platforms AB 343 Nya Vattentornet 344 SE-221 83 Lund 345 Sweden 346 electronic mail: ulf.a.lindgren@ericsson.com 348 Magnus Westerlund 349 Ericsson AB 350 Ericsson Research 351 SE-164 80 Stockholm 352 Sweden 353 electronic mail: magnus.westerlund@ericsson.com 355 7 References 357 Normative: 358 [DLS1] "Downloadable Sounds Level 1", MMA/AMEI specification 359 v1.0, Los Angeles, CA, USA, 1997. 361 [DLS2] "Downloadable Sounds Level 2.1", MMA/AMEI specification 362 v1.0, Los Angeles, CA, USA, 2001. 364 [MDLS] "Mobile Downloadable Sounds 1.0", MMA specification 365 v1.0, Los Angeles, CA, USA, 2004. 367 [RP-001] "Standard MIDI File", recommended practice #001 MMA/AMEI 368 specification v1.0, Los Angeles, CA, USA, 1991 370 [GM1] "The complete MIDI 1.0 Detailed Specification", MMA/AMEI 371 specification v1.0, Los Angeles, CA, USA. 1991 373 [GM2] "General MIDI level 2", MMA/AMEI specification v1.0, 374 Los Angeles, CA, USA, 1999 376 [GML] "General MIDI Lite", MMA/AMEI specification v1.0, 377 Los Angeles, CA, USA. 2001 379 [SP-MIDI] "Scalable polyhony MIDI specification", MMA/AMEI 380 specification v1.0, Los Angeles, CA, USA. 2002 382 [SPM prof] "Scalable polyhony {MIDI} device 5-24 Note profile for 383 3GPP", MMA/AMEI specification v1.0, Los Angeles, CA, USA, 384 2002 386 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 387 Requirement Levels", RFC 2119, March 1997. 389 Informative: 391 [Draft1] draft-ietf-avt-rtp-midi-format-01.txt 393 Full Copyright Statement 395 Copyright (C) The Internet Society (2004). All Rights Reserved. 397 This document and translations of it may be copied and furnished to 398 others, and derivative works that comment on or otherwise explain it 399 or assist in its implementation may be prepared, copied, published 400 and distributed, in whole or in part, without restriction of any 401 kind, provided that the above copyright notice and this paragraph are 402 included on all such copies and derivative works. 404 However, this document itself may not be modified in any way, such as 405 by removing the copyright notice or references to the Internet 406 Society or other Internet organizations, except as needed for the 407 purpose of developing Internet standards in which case the procedures 408 for copyrights defined in the Internet Standards process must be 409 followed, or as required to translate it into languages other than 410 English. 412 The limited permissions granted above are perpetual and will not be 413 revoked by the Internet Society or its successors or assigns. 415 This document and the information contained herein is provided on an 416 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 417 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 418 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 419 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 420 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 422 Intellectual Property Notice 424 The IETF takes no position regarding the validity or scope of any 425 intellectual property or other rights that might be claimed to 426 pertain to the implementation or use of the technology described in 427 this document or the extent to which any license under such rights 428 might or might not be available; neither does it represent that it 429 has made any effort to identify any such rights. Information on the 430 IETF's procedures with respect to rights in standards-track and 431 standards-related documentation can be found in BCP-11. Copies of 432 claims of rights made available for publication and any assurances of 433 licenses to be made available, or the result of an attempt made to 434 obtain a general license or permission for the use of such 435 proprietary rights by implementers or users of this specification can 436 be obtained from the IETF Secretariat. 438 The IETF invites any interested party to bring to its attention any 439 copyrights, patents or patent applications, or other proprietary 440 rights which may cover technology that may be required to practice 441 this standard. Please address the information to the IETF Executive 442 Director. 444 This Internet-Draft expires in August 2004.