idnits 2.17.1 draft-ema-vpim-msgsm-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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == 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 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (April 1, 1999) is 9154 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: '6-3' is mentioned on line 198, but not defined == Missing Reference: '2-1' is mentioned on line 202, but not defined == Missing Reference: '6-1' is mentioned on line 196, but not defined == Missing Reference: '4-1' is mentioned on line 202, but not defined == Missing Reference: '5-1' is mentioned on line 200, but not defined -- Looks like a reference, but probably isn't: '5' on line 200 == Missing Reference: '4-3' is mentioned on line 202, but not defined == Missing Reference: '3-1' is mentioned on line 204, but not defined -- Looks like a reference, but probably isn't: '3' on line 204 == Unused Reference: 'MIME4' is defined on line 260, but no explicit reference was found in the text == Unused Reference: 'VPIM1' is defined on line 263, but no explicit reference was found in the text == Unused Reference: 'VPIM2' is defined on line 265, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'GSM' ** Obsolete normative reference: RFC 2048 (ref. 'MIME4') (Obsoleted by RFC 4288, RFC 4289) ** Obsolete normative reference: RFC 1911 (ref. 'VPIM1') (Obsoleted by RFC 2421, RFC 2422, RFC 2423) ** Obsolete normative reference: RFC 2421 (ref. 'VPIM2') (Obsoleted by RFC 3801) -- Possible downref: Non-RFC (?) normative reference: ref. 'VPIM3' Summary: 7 errors (**), 0 flaws (~~), 12 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Laile L. Di Silvestro (Microsoft) 2 Expires in 6 months Erik Hedberg (Microsoft) 3 Greg Baribault (Microsoft) 4 Microsoft Corporation 5 April 1, 1999 7 Toll Quality Voice - Microsoft GSM 8 MIME Sub-type Registration 9 11 Status of this memo: 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 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 25 "work in 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 This draft is being discussed by the Electronic Messaging 34 Association VPIM work group. To subscribe to the mailing list, send 35 a message to EMA Listserv Requests [listserv@listmail.ema.org] with 36 the line "subscribe VPIM-L" in the body of the message. 38 Internet Draft audio/ms-gsm 4/1/99 40 Abstract 42 This document describes the registration of the MIME sub-type 43 audio/ms-gsm for toll quality audio. This audio encoding is defined 44 by the European Telecommunications Standards Institute (ETSI) in 45 ETS 300 961. 47 1. Introduction 49 The MIME subtype "ms-gsm" is being defined primarily for use in 50 multimedia and voice messaging standards. The Voice Profile for 51 Internet Messaging, version 3 [VPIM3] working draft specifies that 52 all VPIM version 3 compliant implementations MAY generate 53 audio/ms-gsm bodyparts and MUST receive audio/ms-gsm bodyparts. 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in [REQ]. 59 2. ETSI Definition 61 ETS 300 961 (GSM 06.10 version 5.1.1) [GSM] was prepared by 62 European Telecommunications Standards Institute (ETSI) in May 1998. 63 It is a reproduction of recommendation T/L/03/11 "13kbit/s 64 Regular Pulse Excitation - Long Term Prediction - Linear Predictive 65 Coder for use in the digital cellular telecommunications system." 67 ETS 300 961 describes the detailed mapping between input blocks of 68 160 speech samples in 13 bit uniform PCM format to encoded blocks of 69 260 bits, and from encoded blocks of 260 bits to output blocks of 70 160 reconstructed speech samples. The sampling rate is 71 8000 sample/s leading to an average bit rate for the encoded bit 72 stream of 13 kbit/s. The coding scheme is the so-called Regular 73 Pulse Excitation - Long Term prediction - Linear Predictive 74 Coder, here-after referred to as RPE-LTP. 76 2.1 Parameter storage 78 ETS 300 961 provides a detailed description of the mapping of blocks 79 of 160 speech samples in 13 bit uniform PCM format to 76 encoder 80 parameters, and the mapping from those encoder parameters back to 81 160 reconstructed speech samples. The 76 encoder parameters vary in 82 width from 2 to 7 bits, so they all fit in 260 bits. 84 ETS 300 961 does not define the correct way to store these 76 85 parameters in a computer file, however. To promote interoperability, 86 this document describes the MS-GSM version of GSM 06.10 which is to 87 be used to encode audio/ms-gsm data. 89 Internet Draft audio/ms-gsm 4/1/99 91 Audio/ms-gsm implementations MUST pack two sets of encoder output 92 parameters into 65 bytes and MUST right justify the parameters in 93 a byte. Since each set of encoder output parameters occupies 32.5 94 bytes, the two sets will be offset by a nibble (4 bits). 96 In this illustration, as in ETS 300 961, arrays are 1-based and 97 the least significant bit is numbered 1. 98 The first eight encoder parameters are named LAR1 through LAR8, 99 and they vary from 6 to 3 bits in width. The notation LAR1[6-3] 100 indicates the 4 high order bits of LAR1, and LAR5[2-1] indicates 101 the 2 low-order bits of LAR5. The remaining 68 parameters are 102 packed similarly. 104 MSB LSB 105 Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 106 +-------+-------+-------+-------+-------+-------+-------+-------+ 107 | LAR2[2-1] | LAR1[6-1] | 108 +-------+-------+-------+-------+-------+-------+-------+-------+ 109 | LAR3[4-1] | LAR2[6-3] | 110 +-------+-------+-------+-------+-------+-------+-------+-------+ 111 | LAR5[2-1] | LAR4[5-1] |LAR3[5]| 112 +-------+-------+-------+-------+-------+-------+-------+-------+ 113 | LAR7[2-1] | LAR6[4-1] | LAR5[4-3] | 114 +-------+-------+-------+-------+-------+-------+-------+-------+ 115 | LAR8[3-1] |LAR7[3]| 116 +-------+-------+-------+-------+ 118 3. MIME Definition 120 3.1 audio/ms-gsm 122 European Telecommunications Standards Institute (ETSI) ETS 300 123 961 [GSM] describes the algorithm recommended for conversion of 124 blocks of 160 speech samples in 13 bit uniform PCM format to 125 encoded blocks of 260 bits, and the mapping back from those 260 126 bit blocks to output blocks of 160 reconstructed speech 127 samples. 129 The MIME sub-type audio/ms-gsm is defined to hold binary audio 130 data encoded exactly as defined by ETS 300 961 (GSM 06.10) No 131 header information shall be included as part of the audio data. 132 The content transfer encoding is typically either binary or 133 base64. 135 To enable interoperability, the audio data MUST conform to the 136 parameter storage definition provided in the section above and 137 in the IANA registration below. 139 Internet Draft audio/ms-gsm 4/1/99 141 3.2 VPIM Usage 143 The audio/ms-gsm sub-type is a component of the proposed VPIM 144 version 3 specification [VPIM3]. In this context, the 145 Content-Description headers is used to succinctly describe 146 the contents of the audio body. 148 All VPIM Version 3 systems MUST be capable of receiving audio 149 encoded in the MS-GSM version of GSM 06.10. Sending systems MAY 150 choose to send audio data encoded in MS-GSM. All receiving 151 systems MUST be able to process MS-GSM audio data. 153 Refer to the VPIM Specification for proper usage. 155 4. IANA Registration 157 To: ietf-types@iana.org 158 Subject: Registration of MIME media type audio/ms-gsm 160 MIME media type name: audio 162 MIME subtype name: ms-gsm 164 Required parameters: none 166 Optional parameters: none 168 Encoding considerations: 169 Binary or Base-64 generally preferred 171 Security considerations: 172 There are no known security risks with the sending or 173 playing of raw audio data. Audio data is typically interpreted 174 only by an audio codec. Unintended information introduced into 175 the data stream will result in noise. 177 Interoperability considerations: 178 MS-GSM is not compatible with other GSM 06.10 179 implementations. To be interoperable, Audio/ms-gsm 180 implementations MUST pack two encoder parameter blocks into 65 181 bytes and MUST right justify the parameters in a byte. 183 Internet Draft audio/ms-gsm 4/1/99 185 In this illustration, as in ETS 300 961, arrays are 1-based 186 and the least significant bit is numbered 1. The first 8 187 encoder parameters are named LAR1 through LAR8, and they vary 188 from 6 to 3 bits in width. The notation LAR1[6-3] indicates 189 the 4 high order bits of LAR1, and LAR5[2-1] indicates the 2 190 low-order bits of LAR5. The remaining 68 parameters are 191 packed similarly. 193 MSB LSB 194 Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 195 +-------+-------+-------+-------+-------+-------+-------+-------+ 196 | LAR2[2-1] | LAR1[6-1] | 197 +-------+-------+-------+-------+-------+-------+-------+-------+ 198 | LAR3[4-1] | LAR2[6-3] | 199 +-------+-------+-------+-------+-------+-------+-------+-------+ 200 | LAR5[2-1] | LAR4[5-1] |LAR3[5]| 201 +-------+-------+-------+-------+-------+-------+-------+-------+ 202 | LAR7[2-1] | LAR6[4-1] | LAR5[4-3] | 203 +-------+-------+-------+-------+-------+-------+-------+-------+ 204 | LAR8[3-1] |LAR7[3]| 205 +-------+-------+-------+-------+ 207 Published specification: 208 ETS 300 961 (May 1998), "Digital cellular telecommunications 209 system (Phase 2+); Full rate speech; Transcoding (GSM 06.10 210 version 5.1.1)". 212 Applications which use this media type: 213 Voice messaging applications 215 Additional information: 216 Magic number(s): ? 217 File extension(s): .gsm 218 Macintosh File Type Code(s): 'gsm ' 220 Person & email address to contact for further information: 221 Laile L. Di Silvestro 222 lailed@microsoft.com 224 Greg Baribault 225 gregbari@microsoft.com 227 Intended usage: COMMON 229 Author/Change controller: 230 Laile L. Di Silvestro 231 Greg Baribault 233 Internet Draft audio/ms-gsm 4/1/99 235 5. Authors' Addresses 237 Laile L. Di Silvestro 238 Microsoft Corporation 239 One Microsoft Way 240 Redmond, WA 98052 241 lailed@microsoft.com 243 Erik Hedberg 244 Microsoft Corporation 245 One Microsoft Way 246 Redmond, WA 98052 247 erikhe@microsoft.com 249 Greg Baribault 250 Microsoft Corporation 251 One Microsoft Way 252 Redmond, WA 98052 253 gregbari@microsoft.com 255 6. References 257 [GSM] ETS 300 961 (May 1998), "Digital cellular 258 telecommunications system (Phase 2+); Full rate 259 speech; Transcoding (GSM 06.10 version 5.1.1)". 260 [MIME4] Freed, N., Klensin, J., and J. Postel, "Multipurpose 261 Internet Mail Extensions (MIME) Part Four: 262 Registration Procedures", RFC 2048, November 1996. 263 [VPIM1] Vaudreuil, G., "Voice Profile for Internet Mail", RFC 264 1911, February 1996. 265 [VPIM2] Vaudreuil, G., and G. Parsons, "Voice Profile for 266 Internet Mail - version 2", RFC 2421, September 1998. 267 [VPIM3] Vaudreuil, Greg, "Voice Profile for Internet Mail, 268 Version 2", Work In Progress, , December 1998. 270 [REQ] Bradner, S., "Key words for use in RFCs to Indicate 271 Requirement Levels", BCP 14, RFC 2119, March 1997. 273 Internet Draft audio/ms-gsm 4/1/99 275 7. Full Copyright Statement 276 Copyright (C) The Internet Society (1999). All Rights Reserved. 277 This document and translations of it may be copied and furnished 278 to others, and derivative works that comment on or otherwise 279 explain it or assist in its implementation may be prepared, 280 copied, published and distributed, in whole or in part, without 281 restriction of any kind, provided that the above copyright notice 282 and this paragraph are included on all such copies and derivative 283 works. However, this document itself may not be modified in any 284 way, such as by removing the copyright notice or references to the 285 Internet Society or other Internet organizations, except as needed 286 for the purpose of developing Internet standards in which case the 287 procedures for copyrights defined in the Internet Standards process 288 must be followed, or as required to translate it into languages 289 other than English. 290 The limited permissions granted above are perpetual and will not 291 be revoked by the Internet Society or its successors or assigns. 293 Microsoft hereby grants to the IETF, a perpetual, nonexclusive, 294 non-sublicensable, non assignable, royalty-free, world-wide right 295 and license under any Microsoft copyrights in this contribution to 296 copy, publish and distribute the contribution, as well as a right 297 and license of the same scope to any derivative works prepared by 298 the IETF and based on, or incorporating all or part of the 299 contribution. 300 Microsoft further agrees that, upon adoption of this contribution 301 as an Internet Standard, Microsoft will grant to any party a 302 royalty-free license on other reasonable and non-discriminatory 303 terms under applicable Microsoft intellectual property rights to 304 implement and use the technology proposed in this contribution for 305 the purpose of supporting the Internet Standard . Microsoft 306 expressly reserves all other rights it may have in the material and 307 subject matter of this contribution. 308 Microsoft expressly disclaims any and all warranties regarding this 309 contribution including any warranty that (a) this contribution does 310 not violate the rights of others, (b) the owners, if any, of other 311 rights in this contribution have been informed of the rights and 312 permissions granted to IETF herein, and (c) any required 313 authorizations from such owners have been obtained. 314 This document and the information contained herein is provided on 315 an "AS IS" basis and MICROSOFT DISCLAIMS ALL WARRANTIES, EXPRESS OR 316 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 317 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 318 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 319 PURPOSE. 321 IN NO EVENT WILL MICROSOFT BE LIABLE TO ANY OTHER PARTY INCLUDING 322 THE IETF AND ITS MEMBERS FOR THE COST OF PROCURING SUBSTITUTE GOODS 323 OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY 324 INCIDENTAL, CONSEQUENTIAL, INDIRECT, OR SPECIAL DAMAGES WHETHER 325 UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY WAY 326 OUT OF THIS OR ANY OTHER AGREEMENT RELATING TO THIS DOCUMENT, 327 WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF 328 SUCH DAMAGES.