idnits 2.17.1 draft-ema-vpim-wav-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. ** 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 63 lines 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. ** There are 47 instances of lines with control characters 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 (June 20, 1999) is 9069 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: 'Specification' is mentioned on line 253, but not defined == Unused Reference: 'G726' is defined on line 361, but no explicit reference was found in the text == Unused Reference: 'MIME4' is defined on line 365, but no explicit reference was found in the text == Unused Reference: 'VPIM1' is defined on line 369, but no explicit reference was found in the text == Unused Reference: 'VPIM2' is defined on line 372, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'G726' ** 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' ** Downref: Normative reference to an Informational RFC: RFC 2361 (ref. 'WAVE') Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 4 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 Greg Baribault (Microsoft) 3 Microsoft Corporation 4 June 20, 1999 6 Waveform Audio File Format 7 MIME Sub-type Registration 8 10 Status of this memo: 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 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 18 distribute 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. 22 It is inappropriate to use Internet Drafts as reference material 23 or to cite them other than as a "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 To learn the current status of any Internet-Draft, please check the 32 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 33 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 34 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 35 ftp.isi.edu (US West Coast). 37 This draft is being discussed by the Electronic Messaging 38 Association VPIM work group. To subscribe to the mailing list, send 39 a message to EMA Listserv Requests [listserv@listmail.ema.org] with 40 the line "subscribe VPIM-L" in the body of the message. 42 Internet Draft audio/wav 4/1/99 44 Abstract 46 This document describes the registration of the MIME sub-type 47 audio/wav for Waveform Audio File Format. This audio file format 48 is based on RIFF and is defined by Microsoft in the Platform SDK. 50 1. Introduction 51 This document describes the registration of the MIME sub-type 52 audio/wav for the encapsulation of toll-quality audio in the 53 Waveform Audio File Format. This audio file format is based on 54 Resource Interchange File Format (RIFF), and is defined by Microsoft 55 in the Platform SDK. 57 The MIME subtype "wav" is being defined primarily for use in 58 multimedia and voice messaging standards. the Voice Profile for 59 Internet Messaging, version 3 [VPIM3] working draft specifies that 60 all VPIM version 3 compliant implementations MAY generate 61 audio/wav bodyparts and MUST receive audio/wav bodyparts. The VPIM 62 version 3 specification further states that all compliant 63 implementations MUST support receipt of wav-encapsulated 32KADPCM 64 (g.726 ADPCM), BASIC (g.711 mu-law), and MS-GSM (Microsoft g.610 65 GSM) encoded audio. 67 Because the Waveform Audio File format is not well-defined and has 68 not undergone a process of standardization, this document briefly 69 defines the format that will be supported by VPIM version 3. For 70 more detailed information, refer to the specification. 72 This document does not obsolete the informational draft RFC 2361 73 [WAVE] which describes audio/vnd.wav. Whereas RFC 2361 describes 74 a mechanism for indicating a codec registered in the wav or avi 75 vendor tree registries, this document proposes a standard for 76 specifying wav-encapsulated audio content in a MIME stream. 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 80 this document are to be interpreted as described in [REQ]. 82 2. WAV Definition 84 Waveform Audio File Format is a file format for the storing of 85 audio data in data chunks according to the Resource Interchange File 86 Format (RIFF). Although the Waveform format is described in detail 87 in xxxxxxx, lack of standardization and a proliferation of 88 interpretations and enhancements make the format difficult to 89 implement and support in an interoperable fashion. This document 90 seeks to rectify the situation by defining the Waveform Audio 91 File Format features that MUST be inplemented and supported for 92 conformance with the proposed VPIM version 3 standard. 94 Internet Draft audio/wav 4/1/99 96 2.1 Data Organization 97 Data MUST be stored in 8-bit bytes in little-endian order. 98 Multi-byte values MUST be stored with the low-order bytes first, 99 and the bits left-justified: 101 (lsb = least-significant bit, msb = most-significant bit) 103 7 6 5 4 3 2 1 0 104 +-----------------------+ 105 char: | msb lsb | 106 +-----------------------+ 108 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 109 +-----------------------+-----------------------+ 110 short: | msb byte 0 | byte 1 lsb | 111 +-----------------------+-----------------------+ 113 2.2 File Format 114 The Waveform Audio File Format follows the Resource Interchange File 115 Format (RIFF) standard in which all data is organized into 'chunks' 116 and 'sub-chunks.' Each chunk MUST comprise a 4-byte chunk ID, a 117 4-byte length field specifying the size of the data, and the chunk 118 data. 120 To be compliant with this proposed standard, wav-formatted audio 121 data MUST include the following chunks: 122 RIFF header chunk: ID = 'RIFF' 123 Format chunk: ID = 'fmt ' 124 Sound data chunk: ID = 'data' 125 Fact chunk: ID = 'fact' 127 The chunks MAY appear in any order except that the Format chunk 128 MUST be placed before the Sound data chunk (but not necessarily 129 contiguous to the Sound data chunk). Any additional chunks 130 MUST be expected and MAY be ignored. 132 2.2.1 The RIFF Header Chunk 133 The RIFF header corresponds to the outermost chunk. In an audio/wav 134 file, it MUST adhere to the following format: 136 OFFSET LENGTH VALUE DESCRIPTION 137 0 4 bytes 'RIFF' The file format ID. 138 4 4 bytes Length of the file minus (-) 8 bytes. 139 8 4 bytes 'WAVE' The data format ID. 141 2.2.2 The Format Chunk 142 The Format chunk specifies the characteristics of the audio data 143 necessary to decompress it and play it. Each audio/wav file MUST 144 include one and only one Format chunk. This chunk MUST include 145 the following fields: 147 Internet Draft audio/wav 4/1/99 149 OFFSET LENGTH VALUE DESCRIPTION 150 12 4 bytes 'fmt ' The chunk ID. 151 16 4 bytes 32 Length of the chunk excluding the 8 152 bytes for the ID and length. 153 20 4 bytes The codec ID. 154 24 4 bytes The number of channels. 155 28 8 bytes Samples per second. 156 36 8 bytes Average bytes per second. 157 44 4 bytes Block alignment. 158 48 4 bytes Bits per sample. 160 Codec ID: The codec ID indicates what codec was used to compress 161 the audio data. Three codecs are supported by the proposed VPIM 162 version 3 standard, and one of them SHOULD be specified in the 163 Codec ID field. The Codec ID field MAY indicate a codec other 164 that the three listed below only in situations where it is certain 165 that the recipient has the corresponding capabilities. 167 CODEC ID 168 g.711 mu-law 0x0007 169 g.610 MS-GSM 0x0031 170 g.726 32kADPCM 0x0064 172 Number of Channels: To preserve network bandwidth and minimize 173 memory requirements, the Format chunk SHOULD specify and the Data 174 chunk SHOULD provide only one channel (mono) unless it is certain 175 that the recipient supports multi-channel playback. 177 CHANNELS VALUE 178 one (mono) 1 180 Samples per Second: This field indicates the rate at which the 181 audio is to be played (once uncompressed), expressed in sample 182 frames per second. The following table specified the samples per 183 second that correspond to each VPIM version 3 codec: 185 CODEC RATE (samples per second) 186 g.711 mu-law 8000 187 g.610 MS-GSM 8000 188 g.726 32kADPCM 8000 190 Average Bytes per Second: This field specifies the number of 191 bytes that play per second. It provides an indication of 192 the buffer size needed to store the audio in order to avoid 193 latency. It SHOULD be calculated according to the following 194 formula: samples/second * block alignment (rounded up to nearest 195 whole number). 197 CODEC RATE (average bytes per second) 198 g.711 mu-law 8000 199 g.610 MS-GSM 1625 200 g.726 32kADPCM 4000 201 Internet Draft audio/wav 4/1/99 203 Block Alignment: This field indicates the size of a sample frame 204 in bytes. It SHOULD be calculated according to the following 205 formula: number of channels * (bits per sample / 8) 207 CODEC SIZE 208 g.711 mu-law 1 209 g.610 MS-GSM 65 210 g.726 32kADPCM 2 211 since there are 4 bits per sample, the frames will not 212 align on one byte. It is customary to add silence bits 213 (oxF) to the end of the sample to make the frame end on 214 a byte boundary. 216 Bits per Sample: This field specifies the bit resolution of a 217 sample point. 219 CODEC BITS (bits per sample) 220 g.711 mu-law 8 221 g.610 MS-GSM 0 222 data immediately followed by: 0x40 0x01 223 g.726 32kADPCM 4 225 2.2.3 The Data Chunk 226 The Data chunk contains the compressed audio data. This chunk 227 MUST be preceded (though not immediately) by the Format chunk. 228 The Data chunk MUST adhere to the following format: 230 OFFSET LENGTH VALUE DESCRIPTION 231 52 4 bytes 'data' The chunk ID. 232 56 4 bytes Length of the data 233 (chunk size minus (-) 8 bytes. 234 60 The compressed audio. 236 2.2.4 The Fact Chunk 237 All audio/wav files MUST include a Fact chunk as they contain 238 compressed data. The Fact chunk MUSt contain one field indicating 239 the size (in sample points) of the audio data after decompression. 240 The Fact chunk MUST adhere to the following format: 242 OFFSET LENGTH VALUE DESCRIPTION 243 4 bytes 'fact' The chunk ID. 244 4 bytes 8 Chunk size minus (-) 8 bytes. 245 8 bytes Sample length. 247 Internet Draft audio/wav 4/1/99 249 3. MIME Definition 251 3.1 audio/wav 253 [Specification] describes a file format for the encapsulation of 254 raw and compressed audio data. This Waveform Audio File Format (WAVE) 255 is based on the Resource Interchange File Format specification 256 developed by Microsoft and IBM in 1991. The WAVE format organizes 257 audio data and the information needed to decompress and play it in 258 chunks. 260 The MIME sub-type audio/WAV is defined to hold binary audio data 261 encoded in 32 kbit/s ADPCM (g.726), mu-law (g.711), or MS-GSM 262 (g.610), and encapsulated in the WAVE format. The content transfer 263 encoding is typically either binary or base64. 265 3.2 VPIM Usage 267 The audio/wav sub-type is a component of the proposed VPIM version 268 3 specification [VPIM3]. In this context, the Content-Description 269 headers is used to succinctly describe the contents of the audio 270 body. 272 All VPIM Version 3 systems MUST be capable of receiving audio 273 encapsulated in a WAVE file format. Sending systems MAY choose to 274 send raw audio data or encapsulate it in the WAVE file format. All 275 audio data MUST be compressed in one of the VPIM v3 codecs and 276 encapsulated according to the guidelines provided in the section 277 2.0 of this document. 279 Refer to the VPIM Specifcation for proper usage. 281 3.3 Relation to RFC 2361 283 RFC 2361, "WAVE and AVI Codec Registries," is an informational 284 draft describing IANA namespaces for codecs registered in 285 Microsoft's WAVE and AVI registries. Such codecs may be described 286 in the following format: audio/vnd.wave; codec = [codec ID]. 287 This format is not suited to the description of a wave file as 288 defined in this document, as it does not indicate the format 289 standard that audio/wav must adhere to for interoperability 290 between messaging systems. On desktop-oriented messaging systems, 291 audio/wav (rather than audio/vnd.wave) is the defacto standard. 293 Internet Draft audio/wav 4/1/99 295 4. IANA Registration 297 To: ietf-types@iana.org 298 Subject: Registration of MIME media type audio/wav 300 MIME media type name: audio 301 MIME subtype name: wav 303 Required parameters: none 304 Optional parameters: codec = [codec id] 306 Encoding considerations: 307 Binary or Base-64 generally preferred 309 Security considerations: 310 There are no known security risks with the sending or 311 playing of audio data. Wav-encapsulated audio data is 312 typically interpreted only by a codec supported by a 313 wav audio player. Unintended information introduced into 314 the data stream will result in noise. 316 Interoperability considerations: 318 Published specification: 319 None 321 Applications which use this media type: 322 Multimedia and voice messaging applications 324 Additional information: 325 Magic number(s): ? 326 File extension(s): .wav 327 Macintosh File Type Code(s): WAVE 329 Person & email address to contact for further information: 331 Laile L. Di Silvestro 332 lailed@microsoft.com 334 Greg Baribault 335 gregbari@microsoft.com 337 Intended usage: COMMON 339 Author/Change controller: 340 Laile L. Di Silvestro 341 Greg Baribault 343 Internet Draft audio/wav 4/1/99 345 5. Authors' Addresses 347 Laile L. Di Silvestro 348 Microsoft Corporation 349 One Microsoft Way 350 Redmond, WA 98052 351 lailed@microsoft.com 353 Greg Baribault 354 Microsoft Corporation 355 One Microsoft Way 356 Redmond, WA 98052 357 gregbari@microsoft.com 359 6. References 361 [G726] CCITT Recommendation G.726 (1990), General Aspects of Digital 362 Transmission Systems, Terminal Equipment - 40, 32, 24,16 363 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM). 365 [MIME4] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet 366 Mail Extensions (MIME) Part Four: Registration Procedures", 367 RFC 2048, November 1996. 369 [VPIM1] Vaudreuil, G., "Voice Profile for Internet Mail", RFC 1911, 370 February 1996. 372 [VPIM2] Vaudreuil, G., and G. Parsons, "Voice Profile for Internet 373 Mail - version 2", RFC 2421, September 1998. 375 [VPIM3] Vaudreuil, Greg, "Voice Profile for Internet Mail, Version 376 2", Work In Progress, , 377 December 1998. 379 [REQ] Bradner, S., "Key words for use in RFCs to Indicate 380 Requirement Levels", BCP 14, RFC 2119, March 1997. 382 [WAVE] Fleischman, E., "WAVE and AVI Codec Registries", RFC 2361, 383 June 1998. 385 Internet Draft audio/wav 4/1/99 387 7. Full Copyright Statement 388 Copyright (C) The Internet Society (1999). All Rights Reserved. 389 This document and translations of it may be copied and furnished 390 to others, and derivative works that comment on or otherwise 391 explain it or assist in its implementation may be prepared, 392 copied, published and distributed, in whole or in part, without 393 restriction of any kind, provided that the above copyright notice 394 and this paragraph are included on all such copies and derivative 395 works. However, this document itself may not be modified in any 396 way, such as by removing the copyright notice or references to the 397 Internet Society or other Internet organizations, except as needed 398 for the purpose of developing Internet standards in which case the 399 procedures for copyrights defined in the Internet Standards process 400 must be followed, or as required to translate it into languages 401 other than English. 402 The limited permissions granted above are perpetual and will not 403 be revoked by the Internet Society or its successors or assigns. 405 Microsoft hereby grants to the IETF, a perpetual, nonexclusive, 406 non-sublicensable, non assignable, royalty-free, world-wide right 407 and license under any Microsoft copyrights in this contribution to 408 copy, publish and distribute the contribution, as well as a right 409 and license of the same scope to any derivative works prepared by 410 the IETF and based on, or incorporating all or part of the 411 contribution. 412 Microsoft further agrees that, upon adoption of this contribution 413 as an Internet Standard, Microsoft will grant to any party a 414 royalty-free license on other reasonable and non-discriminatory 415 terms under applicable Microsoft intellectual property rights to 416 implement and use the technology proposed in this contribution for 417 the purpose of supporting the Internet Standard. Microsoft 418 expressly reserves all other rights it may have in the material and 419 subject matter of this contribution. 420 Microsoft expressly disclaims any and all warranties regarding this 421 contribution including any warranty that (a) this contribution does 422 not violate the rights of others, (b) the owners, if any, of other 423 rights in this contribution have been informed of the rights and 424 permissions granted to IETF herein, and (c) any required 425 authorizations from such owners have been obtained. 426 This document and the information contained herein is provided on 427 an "AS IS" basis and MICROSOFT DISCLAIMS ALL WARRANTIES, EXPRESS OR 428 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 429 OFTHE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 430 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 431 PURPOSE. 432 IN NO EVENT WILL MICROSOFT BE LIABLE TO ANY OTHER PARTY INCLUDING 433 THE IETF AND ITS MEMBERS FOR THE COST OF PROCURING SUBSTITUTE GOODS 434 OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY 435 INCIDENTAL, CONSEQUENTIAL, INDIRECT, OR SPECIAL DAMAGES WHETHER 436 UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY WAY 437 OUT OF THIS OR ANY OTHER AGREEMENT RELATING TO THIS DOCUMENT, 438 WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF 439 SUCH DAMAGES.