idnits 2.17.1 draft-westerlund-mime-dls-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 289. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 260. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 267. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 273. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance 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.) -- The document date (February 10, 2006) is 6649 days in the past. Is this intentional? 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' ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) -- Obsolete informational reference (is this intentional?): RFC 3548 (Obsoleted by RFC 4648) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Frojdh 3 INTERNET-DRAFT U. Lindgren 4 draft-westerlund-mime-dls-01 M. Westerlund 5 Expires: August 2006 Ericsson 6 February 10, 2006 8 Media Type Registrations for Downloadable Sounds for MIDI 10 Status of this memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than as "work in 26 progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This document is an individual submission to the IETF. Comments 35 should be directed to the author. 37 Abstract 39 This document serves to register a media type for Downloadable 40 Sounds. 42 TABLE OF CONTENTS 44 1. Conventions Used.................................................3 45 2. Introduction.....................................................3 46 3. Security Considerations..........................................3 47 4. IANA Considerations..............................................4 48 4.1. Downloadable Sound.............................................4 49 5. RFC Editor Considerations........................................6 50 6. Authors' Addresses...............................................6 51 7. References.......................................................6 52 7.1. Normative......................................................6 53 7.2. Informative....................................................7 54 8. IPR Notice.......................................................7 55 9. Copyright Notice.................................................7 57 1. Introduction 59 The present document seeks to register a media type for 60 Downloadable Sounds (DLS). The DLS format is used to define 61 instruments for widely used wavetable synthesizers associated with 62 the standards [DLS1, DLS2, MDLS]. DLS, and their associated 63 standards are maintained and defined by two organizations, the MIDI 64 Manufacturers Association (MMA) and the Association of the Musical 65 Electronics Industry (AMEI). 67 The media type defined here is needed to correctly identify DLS 68 files when they are served over HTTP, included in multi-part 69 documents, or used in other places where media types are used. 71 2. Security Considerations 73 The DLS format may contain audio, displayable text data, and 74 modeling parameters (a.k.a. articulation parameters). In addition, 75 the DLS format contains a so-called conditional chunk which is 76 'active' in the sense that it affects the execution of a DLS file 77 parser. However, the DLS format does not currently define any 78 scripting mechanism. 80 Clearly it is possible to author malicious files which, for 81 example, contain large amounts of data always blocked by a 82 conditional statement, i.e. no synthesizer loads the instruments. 84 However, for DLS, clients can and usually do protect themselves 85 against these kinds of attacks. For DLS content containing 86 conditional chunks it is stressed that the chunk in question is 87 optional, that is to say a parser does not have to execute the 88 chunk. However, if a parser evaluates a conditional chunk, it is 89 still possible to parse its content and draw a conclusion whether 90 or not it is usable for a particular synthesizer engine. 92 It should be noted that selected metadata fields may include 93 information partly intended to protect the media against 94 unauthorized use or distribution. In this case the intention is 95 that alteration or removal of the data in the field would be 96 treated as an offence under national agreements based on World 97 Intellection Property Organization (WIPO) treaties. 99 DLS have an extensible structure, making it theoretically possible 100 to define metadata fields or media formats in the future which 101 could be used to induce particular actions of the recipient, and 102 thus present additional security risks. However, this type of 103 capability is currently not supported in the referenced 104 specifications. 106 There is no current provision in the DLS standard for encryption, 107 signing, or authentication within the file formats. 109 3. IANA Considerations 111 The present document requests that IANA registers the media type 112 audio/dls as specified in Section 3.1. The registration uses the 113 template present in [RFC4288]. 115 3.1. Media Type for Downloadable Sounds 117 Type name: audio 119 Subtype name: dls 121 Required parameters: none 123 Optional parameters: 'dls-type' 124 A comma-separated list of the 125 dls types (one or more) that the 126 file content conforms to. The 127 following values are specified: 128 0, 1, and 2 signify Downloadable 129 Sounds Level 1.1b content, 130 Downloadable Sounds Level 2.1 131 content, and Mobile Downloadable 132 Sound content, respectively. All 133 types that the content conforms 134 to should be indicated. Further 135 values (integers) may be 136 specified in the future, and any 137 unknown values shall be ignored. 138 If the parameter is not 139 specified, it corresponds to a 140 value equal to 0, i.e. the 141 content conforms to Downloadable 142 Sound level 1.1b. 144 Encoding considerations: DLS files are binary and should 145 be transmitted in a suitable 146 encoding without CR/LF 147 conversion, 7-bit stripping 148 etc.; base64 [RFC3548] is a 149 suitable encoding. 151 Security considerations: see the security considerations 152 in section 3 of RFC XXXX. 154 Interoperability considerations: This media type is for the 155 consumption by a MIDI player 156 capable of utilizing 157 downloadable sounds for its 158 synthesizers. A general purpose 159 audio player will not be capable 160 of utilizing the audio within 161 the format without explicit 162 support of the format. 164 Published specification: Downloadable Sounds Level 1.1b 165 [DLS1], Downloadable Sounds 166 Level 2.1 [DLS2], and Mobile 167 Downloadable Sounds [MDLS]. MMA 168 specifications can be ordered 169 from the MMA web site, 170 www.midi.org. 172 Applications which use this media type: Multi-media 174 Additional information: 176 Magic number(s): The ninth to twelfth bytes of 177 the file must equal (in 178 hexadecimal notation) 44, 4c, 179 53, and 20, respectively. 180 File extension(s): .dls is declared at 181 http://www.nist.gov/nics 183 Person & email address to contact for further information: 184 Ulf A. Lindgren, 185 ulf.a.lindgren@ericsson.com 187 Intended usage: COMMON 189 Restrictions on usage: None 191 Author: Per Frojdh 192 Ulf A. Lindgren 193 Magnus Westerlund 195 Change controller: MIDI Manufacturers Association 196 http://www.midi.org 197 info@midi.org 199 4. RFC Editor Considerations 201 The references to RFC XXXX in the media type registration need to 202 be replaced with the actual RFC number when it is issued. 204 Please remove this section before publication as RFC. 206 Authors' Addresses 208 Per Frojdh 209 Ericsson AB 210 Ericsson Research 211 SE-164 80 Stockholm 212 Sweden 213 electronic mail: per.frojdh@ericsson.com 215 Ulf A. Lindgren 216 Ericsson AB 217 Ericsson Research 218 SE-417 56 Goteborg 219 Sweden 220 electronic mail: ulf.a.lindgren@ericsson.com 222 Magnus Westerlund 223 Ericsson AB 224 Ericsson Research 225 SE-164 80 Stockholm 226 Sweden 227 electronic mail: magnus.westerlund@ericsson.com 229 6. References 231 6.1. Normative 233 [DLS1] "Downloadable Sounds Level 1.1b", MMA/AMEI 234 specificationv1.1b, Los Angeles, CA, USA, 2004. 236 [DLS2] "Downloadable Sounds Level 2.1", MMA/AMEI specification 237 v1.0, Los Angeles, CA, USA, 2001. 239 [MDLS] "Mobile Downloadable Sounds 1.0", MMA specification 240 v1.0, Los Angeles, CA, USA, 2004. 242 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications 243 and Registration Procedures", BCP 13, RFC 4288, 244 December 2005. 246 6.2. Informative 248 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 249 Encodings", RFC 3548, July 2003. 251 IPR Notice 253 The IETF takes no position regarding the validity or scope of any 254 Intellectual Property Rights or other rights that might be claimed 255 to pertain to the implementation or use of the technology described 256 in this document or the extent to which any license under such 257 rights might or might not be available; nor does it represent that 258 it has made any independent effort to identify any such rights. 259 Information on the procedures with respect to rights in RFC 260 documents can be found in BCP 78 and BCP 79. 262 Copies of IPR disclosures made to the IETF Secretariat and any 263 assurances of licenses to be made available, or the result of an 264 attempt made to obtain a general license or permission for the use 265 of such proprietary rights by implementers or users of this 266 specification can be obtained from the IETF on-line IPR repository 267 at http://www.ietf.org/ipr. 269 The IETF invites any interested party to bring to its attention any 270 copyrights, patents or patent applications, or other proprietary 271 rights that may cover technology that may be required to implement 272 this standard. Please address the information to the IETF at ietf- 273 ipr@ietf.org. 275 8. Copyright Notice 277 Copyright (C) The Internet Society (2006). This document is 278 subject to the rights, licenses and restrictions contained in BCP 279 78, and except as set forth therein, the authors retain all their 280 rights. 282 This document and the information contained herein are provided on 283 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 284 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 285 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 286 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 287 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 288 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 289 PARTICULAR PURPOSE. 291 This Internet-Draft expires in August 2006.