idnits 2.17.1 draft-ema-vpim-32kadpcm-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Abstract' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' Security considerations: none' ) ** 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 30 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], [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 129: '...s of the G.726 encoding MUST be packed...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (July 29, 1997) is 9768 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? 'G726' on line 188 looks like a reference -- Missing reference section? 'X420' on line 203 looks like a reference -- Missing reference section? 'VPIM' on line 84 looks like a reference -- Missing reference section? 'MIME4' on line 192 looks like a reference -- Missing reference section? 'VPIM1' on line 196 looks like a reference -- Missing reference section? 'VPIM2' on line 199 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Greg Vaudreuil 3 Internet Draft Octel Communications 4 Expires in six months Glenn Parsons 5 Obsoletes: RFC 1911 Nortel Technology 6 July 29, 1997 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. Internet Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its Areas, 17 and its Working Groups. Note that other groups may also distribute 18 working documents as Internet Drafts. 20 Internet Drafts are valid for a maximum of six months and may be 21 updated, replaced, or obsoleted by other documents at any time. It 22 is inappropriate to use Internet Drafts as reference material or to 23 cite them other than as a "work in progress". 25 To learn the current status of any Internet-Draft, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 29 ftp.isi.edu (US West Coast). 31 Overview 33 This document describes the registration of the MIME sub-type 34 audio/32KADPCM for toll quality audio. This audio encoding is 35 defined by the ITU-T in Recommendation G.726. 37 1. Abstract 39 This document describes the registration of the MIME sub-type 40 audio/32KADPCM for toll quality audio. This audio encoding is 41 defined by the ITU-T in Recommendation G.726. This document refines 42 an earlier sub-type registration in RFC 1911. 44 2. ITU-T Definition 46 Recommendation G.726 [G726] defines the characteristics that are 47 recommended for the conversion of a 64 kbit/s A-law or m-law pulse 48 code modulation (PCM) channel at 8000 samples/second to and from a 49 40, 32, 24 or 16 kbit/s channel. The conversion is applied to the 50 PCM bit stream using an adaptive differential pulse code modulation 51 (ADPCM) transcoding technique. This Recommendation obsoletes G.721 52 which only defined the 32 kbit/s characteristics. 54 Recommendation G.726 was prepared by Study Group 15 of the 55 Telecommunications Standardization Sector of the International 56 Telecommunication Union (ITU-T) and was approved under the ITU's 57 Resolution No. 2 procedure on the 14 of December 1990. 59 3. MIME Definition 61 3.1 audio/32KADPCM 63 CCITT Recommendation G.726 [G726] describes the algorithm 64 recommended for conversion of a 64 kbit/s A-law or u-law PCM channel 65 to and from a 32 kbit/s channel (this is the same algorithm as 66 described in the deprecated G.721). The conversion is applied to 67 the PCM stream using an Adaptive Differential Pulse Code Modulation 68 (ADPCM) transcoding technique. 70 The MIME sub-type audio/32KADPCM is defined to hold binary audio 71 data encoded in 32 kbit/s ADPCM exactly as defined by ITU-T 72 Recommendation G.726. No header information shall be included as 73 part of the audio data. The content transfer encoding is typically 74 either binary or base64. 76 An additional consideration that this document defines for clarity 77 is the choice of little endian ordering of the four bit code words. 78 This default ordering is defined in ITU-T Recommendation X.420 79 [X420] for the equivalent X.400 body part, but is also detailed 80 below in the IANA Registration. 82 3.2 VPIM Usage 83 The audio/32KADPCM sub-type is a primary component of the VPIM 84 specification [VPIM]. In this context, the Content-Description and 85 Content-Disposition headers are used to succinctly describe the 86 contents of the audio body. As well, only the little endian bit 87 ordering is valid. Refer to the VPIM Specifcation for proper usage. 89 4. IANA Registration 91 To: ietf-types@iana.org 92 Subject: Registration of MIME media type audio/32KADPCM 94 MIME media type name: audio 96 MIME subtype name: 32KADPCM 98 Required parameters: none 100 Optional parameters: none 102 Encoding considerations: Binary or Base-64 generally preferred 104 Security considerations: none 106 Interoperability considerations: 108 The four bit code word ordering within a byte may differ 109 between existing implementations of G.726 codecs. Since 110 this content only permits the little endian ordering, codecs 111 that support the opposite ordering must reorder the code 112 words before storing to or retrieving from this content 113 type. 115 Published specification: ITU-T G.726 with little endian 116 ordering 118 Applications which use this media type: primarily voice 119 messaging 121 Additional information: 123 Magic number(s): ? 124 File extension(s): .721 125 Macintosh File Type Code(s): APCM 127 Little Endian Ordering: 129 The 4-bit code words of the G.726 encoding MUST be packed 130 into octets/bytes as follows: the first code word (A) is 131 placed in the four least significant bits of the first 132 octet, with the least significant bit (LSB) of the code word 133 (A1) in the least significant bit of the octet; the second 134 code word (B) is placed in the four most significant bits of 135 the first octet, with the most significant bit (MSB) of the 136 code word (B4) in the most significant bit of the octet. 137 Subsequent pairs of the code words shall be packed in the 138 same way into successive octets, with the first code word of 139 each pair placed in the least significant four bits of the 140 octet. It is preferred that the voice sample be extended 141 with silence such that the encoded value comprises an even 142 number of code words. However, if the voice sample 143 comprises an odd number of code words, then the last code 144 word shall be discarded. 146 +--+--+--+--+--+--+--+--+ 147 |A1|A2|A3|A4|B1|B2|B3|B4| 148 +--+--+--+--+--+--+--+--+ 149 LSB -> | 0| 1| 2| 3| 4| 5| 6| 7| <- MSB 150 +--+--+--+--+--+--+--+--+ 152 32K ADPCM / Octet Mapping 154 Person & email address to contact for further information: 156 Glenn W. Parsons 157 Glenn.Parsons@Nortel.ca 159 Gregory M. Vaudreuil 160 Greg.Vaudreuil@Octel.Com 162 Intended usage: COMMON 164 Author/Change controller: 166 Glenn W. Parsons & Gregory M. Vaudreuil 168 5. Authors' Addresses 170 Glenn W. Parsons 171 Nortel Technology 172 P.O. Box 3511, Station C 173 Ottawa, ON K1Y 4H7 174 Canada 175 Phone: +1-613-763-7582 176 Fax: +1-613-763-8385 177 Glenn.Parsons@Nortel.ca 178 Gregory M. Vaudreuil 179 Octel Communications 180 17080 Dallas Parkway 181 Dallas, TX 75248-1905 182 United States 183 Phone/Fax: +1-972-733-2722 184 Greg.Vaudreuil@Octel.Com 186 6. References 188 [G726] CCITT Recommendation G.726 (1990), General Aspects of Digital 189 Transmission Systems, Terminal Equipment - 40, 32, 24,16 kbit/s 190 Adaptive Differential Pulse Code Modulation (ADPCM). 192 [MIME4] N. Freed and N. Borenstein, "Multipurpose Internet Mail 193 Extensions (MIME) Part Four: Registration Procedures", RFC 194 2048, Innosoft, First Virtual, Nov 1996. 196 [VPIM1] Vaudreuil, Greg, "Voice Profile for Internet Mail", RFC 197 1911, Feb 1996. 199 [VPIM2] Greg Vaudreuil and Glenn Parsons, "Voice Profile for 200 Internet Mail - version 2", Work in Progress, July 1997. 203 [X420] ITU-T Recommendation X.420 (1996) - ISO/IEC 10021-7:1996, 204 Message handling systems: Interpersonal messaging.