idnits 2.17.1 draft-ietf-vpim-vpimv2r2-32k-03.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 4. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 40 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([VPIM], [X420], [MIME4], [VPIM2R2], [REQ], [VPIM1], [VPIM2], [G726]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 153: '...s of the G.726 encoding MUST be packed...' -- The abstract seems to indicate that this document obsoletes RFC2422, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [REQ], but that reference does not seem to mention RFC 2119 either. -- 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 14, 2002) is 8106 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? 'REQ' on line 244 looks like a reference -- Missing reference section? 'G726' on line 223 looks like a reference -- Missing reference section? 'X420' on line 241 looks like a reference -- Missing reference section? 'VPIM' on line 99 looks like a reference -- Missing reference section? 'MIME4' on line 227 looks like a reference -- Missing reference section? 'VPIM1' on line 231 looks like a reference -- Missing reference section? 'VPIM2' on line 234 looks like a reference -- Missing reference section? 'VPIM2R2' on line 237 looks like a reference Summary: 11 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 Greg Vaudreuil 3 Internet Draft Lucent Technologies 4 Expires in six months Glenn Parsons 5 Obsoletes: RFC 2422 Nortel Networks 6 February 14, 2002 8 Toll Quality Voice - 32 kbit/s ADPCM 9 MIME Sub-type Registration 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. Internet-Drafts are draft documents valid for a maximum of 22 six months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- Drafts 24 as reference material or to cite them other than as "work in 25 progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document is an Internet-Draft and is in full conformance with 36 This document describes the registration of the MIME sub-type 37 audio/32KADPCM for toll quality audio. This audio encoding is 38 defined by the ITU-T in Recommendation G.726. 40 This document obsoletes RFC 2422. 42 Copyright Notice 44 Copyright (C) The Internet Society (2002). All Rights Reserved. 46 1. Introduction 48 This document describes the registration of the MIME sub-type 49 audio/32KADPCM for toll quality audio. This audio encoding is 50 defined by the ITU-T in Recommendation G.726. This document 51 obsoletes an earlier sub-type registration contained in RFC 1911. 52 This document also obsoletes RFC 2422. 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 56 this document are to be interpreted as described in [REQ]. 58 2. ITU-T Definition 60 Recommendation G.726 [G726] defines the characteristics that are 61 recommended for the conversion of a 64 kbit/s A-law or m-law pulse 62 code modulation (PCM) channel at 8000 samples/second to and from a 63 40, 32, 24 or 16 kbit/s channel. The conversion is applied to the 64 PCM bit stream using an adaptive differential pulse code modulation 65 (ADPCM) transcoding technique. This Recommendation obsoletes G.721 66 which only defined the 32 kbit/s characteristics. 68 Recommendation G.726 was prepared by Study Group 15 of the 69 Telecommunications Standardization Sector of the International 70 Telecommunication Union (ITU-T) and was approved under the ITU's 71 Resolution No. 2 procedure on the 14 of December 1990. 73 3. MIME Definition 75 3.1 audio/32KADPCM 77 CCITT Recommendation G.726 [G726] describes the algorithm 78 recommended for conversion of a 64 kbit/s A-law or u-law PCM channel 79 to and from a 32 kbit/s channel (this is the same algorithm as 80 described in the deprecated G.721). The conversion is applied to 81 the PCM stream using an Adaptive Differential Pulse Code Modulation 82 (ADPCM) transcoding technique. 84 The MIME sub-type audio/32KADPCM is defined to hold binary audio 85 data encoded in 32 kbit/s ADPCM exactly as defined by ITU-T 86 Recommendation G.726. No header information shall be included as 87 part of the audio data. The content transfer encoding is typically 88 either binary or base64. 90 An additional consideration that this document defines for clarity 91 is the choice of little endian ordering of the four bit code words. 92 This default ordering is defined in ITU-T Recommendation X.420 93 [X420] for the equivalent X.400 body part, but is also detailed 94 below in the IANA Registration. 96 3.2 VPIM Usage 98 The audio/32KADPCM sub-type is a primary component of the VPIM 99 specification [VPIM]. In this context, the Content-Description and 100 Content-Disposition headers are used to succinctly describe the 101 contents of the audio body. As well, only the little endian bit 102 ordering is valid. Refer to the VPIM Specifcation for proper usage. 104 4. IANA Registration 106 To: ietf-types@iana.org 107 Subject: Registration of MIME media type audio/32KADPCM 109 MIME media type name: audio 111 MIME subtype name: 32KADPCM 113 Required parameters: none 115 Optional parameters: none 117 Encoding considerations: 119 Binary or Base-64 generally preferred 121 Security considerations: 123 There are no known security risks with the sending or 124 playing of raw audio data Audio data is typically 125 interpreted only by an audio codec. Unintended information 126 introduced into the data stream will result in noise. 128 Interoperability considerations: 130 The four bit code word ordering within a byte may differ 131 between existing implementations of G.726 codecs. Since 132 this content only permits the little endian ordering, codecs 133 that support the opposite ordering must reorder the code 134 words before storing to or retrieving from this content 135 type. 137 Published specification: 139 ITU-T G.726 with little endian ordering 141 Applications which use this media type: 143 Primarily voice messaging 145 Additional information: 147 Magic number(s): ? 148 File extension(s): .726 149 Macintosh File Type Code(s): APCM 151 Little Endian Ordering: 153 The 4-bit code words of the G.726 encoding MUST be packed 154 into octets/bytes as follows: the first code word (A) is 155 placed in the four least significant bits of the first 156 octet, with the least significant bit (LSB) of the code word 157 (A0) in the least significant bit of the octet; the second 158 code word (B) is placed in the four most significant bits of 159 the first octet, with the most significant bit (MSB) of the 160 code word (B3) in the most significant bit of the octet. 161 Subsequent pairs of the code words shall be packed in the 162 same way into successive octets, with the first code word of 163 each pair placed in the least significant four bits of the 164 octet. It is preferred that the voice sample be extended 165 with silence such that the encoded value comprises an even 166 number of code words. However, if the voice sample 167 comprises an odd number of code words, then the last code 168 word shall be discarded. 170 +--+--+--+--+--+--+--+--+ 171 |B3|B2|B1|B0|A3|A2|A1|A0| 172 +--+--+--+--+--+--+--+--+ 173 MSB -> | 7| 6| 5| 4| 3| 2| 1| 0| <- LSB 174 +--+--+--+--+--+--+--+--+ 176 32K ADPCM / Octet Mapping 178 Person & email address to contact for further information: 180 Glenn W. Parsons 181 gparsons@NortelNetworks.com 183 Gregory M. Vaudreuil 184 GregV@ieee.org 186 Intended usage: COMMON 188 Author/Change controller: 190 Glenn W. Parsons & Gregory M. Vaudreuil 192 4. Security Considerations 194 There are no known security risks with the sending or playing of raw 195 audio data Audio data is typically interpreted only by an audio 196 codec. Unintended information introduced into the data stream will 197 result in noise. 199 5. Authors' Addresses 201 Glenn W. Parsons 202 Nortel Networks 203 P.O. Box 3511, Station C 204 Ottawa, ON K1Y 4H7 205 Canada 207 Phone: +1-613-763-7582 208 Fax: +1-613-763-2697 210 Email: gparsons@nortelnetworks.com 212 Gregory M. Vaudreuil 213 Lucent Technologies 214 7291 Williamson Rd 215 Dallas, TX 75214 216 United States 218 Phone/Fax: +1-972-733-2722 219 Email: gregv@ieee.org 221 6. References 223 [G726] CCITT Recommendation G.726 (1990), General Aspects of Digital 224 Transmission Systems, Terminal Equipment - 40, 32, 24,16 kbit/s 225 Adaptive Differential Pulse Code Modulation (ADPCM). 227 [MIME4] N. Freed and N. Borenstein, "Multipurpose Internet Mail 228 Extensions (MIME) Part Four: Registration Procedures", RFC 229 2048, Innosoft, First Virtual, Nov 1996. 231 [VPIM1] Vaudreuil, Greg, "Voice Profile for Internet Mail", RFC 232 1911, Feb 1996. 234 [VPIM2] Vaudreuil, G., and G. Parsons, "Voice Profile for Internet 235 Mail - version 2", RFC 2421, September 1998. 237 [VPIM2R2] Vaudreuil, G., and G. Parsons, "Voice Profile for Internet 238 Mail - version 2", , October 239 22, 2001. 241 [X420] ITU-T Recommendation X.420 (1996) - ISO/IEC 10021-7:1996, 242 Message handling systems: Interpersonal messaging. 244 [REQ] S. Bradner, "Key words for use in RFCs to Indicate Requirement 245 Levels", RFC 2119, March 1997. 247 7. Changes from RFC 2422 249 Only editoral and boilerplate changes from RFC 2424 have been made 250 to this document. 252 8. Full Copyright Statement 254 Copyright (C) The Internet Society (2002). All Rights Reserved. 256 This document and translations of it may be copied and furnished to 257 others, and derivative works that comment on or otherwise explain 258 it or assist in its implementation may be prepared, copied, 259 published and distributed, in whole or in part, without restriction 260 of any kind, provided that the above copyright notice and this 261 paragraph are included on all such copies and derivative works. 262 However, this document itself may not be modified in any way, such 263 as by removing the copyright notice or references to the Internet 264 Society or other Internet organizations, except as needed for the 265 purpose of developing Internet standards in which case the 266 procedures for copyrights defined in the Internet Standards process 267 must be followed, or as required to translate it into languages 268 other than English. 270 The limited permissions granted above are perpetual and will not be 271 revoked by the Internet Society or its successors or assigns. 273 This document and the information contained herein is provided on 274 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 275 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 276 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 277 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 278 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.