idnits 2.17.1 draft-kosonen-mobile-xmf-mimetype-00.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 269. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 242. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 249. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 255. ** 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([7], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (5 October 2005) is 6778 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) -- Missing reference section? '1' on line 40 looks like a reference -- Missing reference section? '7' on line 41 looks like a reference -- Missing reference section? '8' on line 49 looks like a reference -- Missing reference section? '3' on line 51 looks like a reference -- Missing reference section? '4' on line 51 looks like a reference -- Missing reference section? '2' on line 51 looks like a reference -- Missing reference section? '9' on line 64 looks like a reference -- Missing reference section? '5' on line 141 looks like a reference -- Missing reference section? '6' on line 141 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT T. Kosonen 3 draft-kosonen-mobile-xmf-mimetype-00.txt Nokia 4 Expires: April 2006 T. White 5 MMA 6 5 October 2005 8 Registration of MIME media type audio/mobile-xmf 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 months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This document is an individual submission to the IETF. Comments 34 should be directed to the authors. 36 Abstract 38 The MIDI Manufacturers Association (MMA) and the Association of Music 39 Electronics industry (AMEI) have produced the Mobile XMF standard 40 [1]. The Mobile XMF standard has been developed particularly for 41 mobile MIDI [7] applications. Mobile XMF is a very compact media 42 type providing high quality synthetic audio content for music 43 downloading and messaging applications that require MIME 44 registration. 46 1. Introduction 48 MIDI content is used commonly in the Internet. Commonly, MIDI data 49 is stored in the Standard MIDI File (SMF) format [8]. This MIME type 50 registration uses the Mobile XMF file format for the encapsulation of 51 SP-MIDI [3,4] and Mobile DLS [2] data. 53 2. Registration of audio/mobile-xmf 55 MIME media type name: audio 57 MIME subtype name: mobile-xmf 59 Required parameters: none 61 Optional parameters: 63 Optional parameters are encoded in Base16 encoding defined in RFC 64 3548 [9]. 66 revision: Mobile XMF file type revision ID 68 revision is the Mobile XMF file type revision ID number from 69 the XmfFileTypeRevisionID field of the XMF Meta File format 70 2.00. 72 prl: Playback resource list 74 prl is a string (inside double quotation marks "") 75 containing the playback resources included in all Content 76 Description MetaDataItems of the Mobile XMF file. The 77 string contains two digit hexadecimal numbers representing 78 data bytes from the Content Description Meta Data. The same 79 resource is listed only once. A playback resource contains 80 two parts: a prefix and data. If the file includes Playback 81 Resource Lists such as [00h 01h 00h 02h] and [00h 01h 00h 82 03h], the corresponding prl is 000100020003 containing 83 playback resources 01, 02, and 03 with the prefix 00. 85 minimum-pr: Minimum playback requirements 87 minimum-pr is a string containing the Maximum Instantaneous 88 Resource (MIR) values from the first row of all MIR Count 89 Tables corresponding to the playback resources listed in 90 prl. Only the largest value from the values of the same 91 resource is chosen. If the file includes first rows of MIR 92 Count Tables such as [02h 00h] and [01h 01h] corresponding 93 to the above Playback Resource Lists, the corresponding 94 minimum-pr is 020001. (02 is the largest of 2 and 1, 00 is 95 the largest of 0, and 01 is the largest of 1.) minimum-pr 96 requires the use of prl and the values in minimum-pr must be 97 in the same order as the resources in prl. minimum-pr is 98 the most important of minimum-pr and total-pr, because it 99 defines the minimum playback requirements. 101 total-pr: Total playback requirements 103 total-pr is a string containing the MIR values from the last 104 row of all MIR Count Tables corresponding to the playback 105 resources listed in prl. Only the largest value from the 106 values of the same resource is chosen. If the file includes 107 last rows of MIR Count Tables such as [05h 02h] and [06h 108 01h] corresponding to the above Playback Resource Lists, the 109 corresponding total-pr is 060201. (06 is the largest of 5 110 and 6, 02 is the largest of 2, and 01 is the largest of 1.) 111 total-pr requires the use of prl and the values in total-pr 112 must be in the same order as the resources in prl. 114 Encoding considerations: 116 mobile-xmf data is binary data and must be encoded for non-binary 117 transport; Base64 is suitable for Email. 119 Security considerations: 121 Many synthetic audio compositions have associated intellectual 122 property rights. It is conceivable that the rights owners of 123 mobile-xmf content will want to protect their rights by applying 124 security mechanisms that prohibit the rendering of the content 125 without a legally acquired license to do so. These mechanisms 126 would be applied externally to the Content-Type defined here; 127 mobile-xmf content itself is not encrypted internally. mobile-xmf 128 streams do not contain executable content. Mobile XMF players are 129 robust against corrupted mobile-xmf content, because Mobile XMF 130 players ignore unidentified content. prl, minimum-pr, and total- 131 pr parameters can be used to represent Mobile DLS playback memory 132 requirements for protecting against the excessive usage of 133 playback memory. 135 Interoperability considerations: 137 Mobile XMF is a Musical Instrument Digital Interface (MIDI) 138 specification developed by MMA and AMEI. mobile-xmf is based on 139 the XMF 2.00 specification [5,6], which standardizes a meta file 140 format for the electronic distribution of music. mobile-xmf data 141 is stored in XMF file format [5,6]. 143 Published specification: 145 There are no previous RFC documents on audio/mobile-xmf. 147 Normative references: 149 1 Mobile XMF Content Format Specification, MMA specification 150 v1.0., RP-42, Los Angeles, CA, USA. 2004. 151 2 Mobile DLS, MMA specification v1.0., RP-41, Los Angeles, CA, 152 USA. 2004. 153 3 Scalable Polyphony MIDI Specification. December 2001, RP-034, 154 The MIDI Manufacturers Association, Los Angeles, CA, USA. 155 4 Scalable Polyphony MIDI Device 5-24 Note Profile for 3GPP, 156 December 2001, RP-035, The MIDI Manufacturers Association, Los 157 Angeles, CA, USA. 158 5 Specification for XMF Meta File Format, Version 1.00b. The MIDI 159 Manufacturers Association, Los Angeles, CA, USA, 2001. 160 6 XMF Meta File Format 2.00, RP-043, MIDI Manufacturers 161 Association, Los Angeles, CA, USA, 2004 162 7 MIDI 1.0 Detailed Specification, Document Version 4.2. February 163 1996, In 'The Complete MIDI 1.0 Detailed Specification, Document 164 Version 96.1.' The MIDI Manufacturers Association., Los 165 Angeles, CA, USA. 166 8 Standard MIDI Files 1.0, In 'The Complete MIDI 1.0 Detailed 167 Specification, Document Version 96.1.' The MIDI Manufacturers 168 Association., Los Angeles, CA, USA. 169 9 Josefsson, S., Ed., "The Base16, Base32, and Base64 Data 170 Encodings", RFC 3548, July 2003. 172 Applications which use this media type: 174 mobile-xmf is a synthetic audio format for the flexible 175 presentation of SP-MIDI and Mobile DLS instrument data on a wide 176 range of playback devices, particularly portable appliances such 177 as mobile phones, PDAs, and palmtop computers. 179 Additional information: 181 Magic number(s): 183 First twelve bytes: 184 \130\115\106\137\062\056\060\060\000\000\000\002 186 File extension(s): mxmf 188 Macintosh File Type Code(s): mxmf 190 Intended usage: COMMON 191 3. IANA Considerations 193 Section 2 of this document registers one MIME subtype. 195 4. Security Considerations 197 Security considerations are specified in the MIME subtype 198 registration contained in Section 2. 200 5. Authors' Addresses 202 Timo Kosonen 203 Nokia 204 P.O. Box 100 205 33721 Tampere 206 Finland 207 Tel: +358 5048 35206 208 Fax: +358 7180 35899 210 Email: timo.kosonen@nokia.com 212 Tom White 213 MIDI Manufacturers Association 214 P.O. Box 3173 215 La Habra CA 216 90632-3173 217 Tel (714) 736-9774 218 Fax (714) 736-9775 220 Email: mma@midi.org 222 6. Change controller: 224 Tom White 225 MIDI Manufacturers Association 226 P.O. Box 3173 227 La Habra CA 228 90632-3173 229 Tel (714) 736-9774 230 Fax (714) 736-9775 232 Email: mma@midi.org 233 7. IPR Disclosure Acknowledgement 235 The IETF takes no position regarding the validity or scope of any 236 Intellectual Property Rights or other rights that might be claimed to 237 pertain to the implementation or use of the technology described in 238 this document or the extent to which any license under such rights 239 might or might not be available; nor does it represent that it has 240 made any independent effort to identify any such rights. Information 241 on the procedures with respect to rights in RFC documents can be 242 found in BCP 78 and BCP 79. 244 Copies of IPR disclosures made to the IETF Secretariat and any 245 assurances of licenses to be made available, or the result of an 246 attempt made to obtain a general license or permission for the use of 247 such proprietary rights by implementers or users of this 248 specification can be obtained from the IETF on-line IPR repository at 249 http://www.ietf.org/ipr. 251 The IETF invites any interested party to bring to its attention any 252 copyrights, patents or patent applications, or other proprietary 253 rights that may cover technology that may be required to implement 254 this standard. Please address the information to the IETF at ietf- 255 ipr@ietf.org. 257 8. Copyright notice 259 Copyright (C) The Internet Society (2005). This document is subject 260 to the rights, licenses and restrictions contained in BCP 78, and 261 except as set forth therein, the authors retain all their rights. 263 This document and the information contained herein are provided on an 264 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 265 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 266 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 267 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 268 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 269 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.