idnits 2.17.1 draft-alvestrand-audio-l16-00.txt: 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 112 has weird spacing: '...hannels des...' == Line 120 has weird spacing: '... lc c ...' -- 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 () is 739384 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 200 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 draft Audio/L16 November 97 3 The Audio/L16 MIME content type 5 Tue Jun 14 11:04:18 MET DST 1994 7 James Salsman 8 james@bovik.org 10 Harald Tveit Alvestrand 11 UNINETT 12 Harald.T.Alvestrand@uninett.no 14 Status of this Memo 16 This draft document is being circulated for comment. 18 Please send comments to the authors. 20 The following text is required by the Internet-draft rules: 22 This document is an Internet Draft. Internet Drafts are working 23 documents of the Internet Engineering Task Force (IETF), its 24 Areas, and its Working Groups. Note that other groups may also 25 distribute working documents as Internet Drafts. 27 Internet Drafts are draft documents valid for a maximum of six 28 months. Internet Drafts may be updated, replaced, or obsoleted by 29 other documents at any time. It is not appropriate to use 30 Internet Drafts as reference material or to cite them other than 31 as a "working draft" or "work in progress." 33 Please check the I-D abstract listing contained in each Internet 34 Draft directory to learn the current status of this or any other 35 Internet Draft. 37 The file name of this version is draft-alvestrand-audio-l16-00.txt 39 draft Audio/L16 November 97 41 1. Introduction 43 This document defines the audio/L16 MIME type, a reasonable 44 quality audio format for use in Internet applications. 46 Possible application areas include E-mail, Web served content, 47 file upload in Web forms, and more. 49 2. The need for the Audio/L16 MIME type 51 The set of IETF standard MIME types for audio is small; it 52 consists of only the audio/basic and audio/32kadpcm types, which 53 have a sampling rate of 8000 Kbits/second. 55 Rates below 11025 may obscure consonant information, even for 56 single-voice speech. Common compressions, such as LPC, are known 57 to be microphone-dependant and lossy. Thus far all IETF MIME 58 Audio types either default to 8000 samples per second or use LPC. 60 In order for advanced speech recognition and related educational 61 applications to make use of internet transports (such as RFC 1867 62 file uploading) which use MIME typing, higher standards are 63 required. 65 This type repairs that lack by registering a very simple MIME type 66 that allows higher rate, linear-encoded audio with multiple 67 channels. 69 This is an IESG approved MIME type, and its definition is 70 therefore published as an RFC. 72 Please note that there are many other Audio types described in RFC 73 1890 [1] which IANA may wish to formally register; this one, of 74 all of them, seems to be most immediately needed. This document 75 may also serve as a template for further registrations of these 76 audio types. 78 3. The definition of Audio/L16 80 Audio/L16 is based on the well know audio format "L16" described 81 in RFC 1890 section 4.4.8 for use with RTP transport. 83 draft Audio/L16 November 97 85 L16 denotes uncompressed audio data, using 16-bit signed 86 representation in twos-complement notation and network byte order. 87 (From section 4.4.8 of RFC 1890) 89 It may be parametrized by varying the sample rate and the number 90 of channels; the parameters are given on the MIME type header. 92 In order to promote interoperability, only a few rate values are 93 standardized here. Other values may NOT be used except by 94 bilateral agreement. 96 If multiple audio channels are used, channels are numbered left- 97 to- right, starting at one. Samples are put into the data stream 98 from each channel in succession; information from lower-numbered 99 channels precedes that from higher-numbered channels. 101 For more than two channels, the convention followed by the AIFF-C 102 audio interchange format should be followed [1], using the 103 following notation: 105 l left 106 r right 107 c center 108 S surround 109 F front 110 R rear 112 channels description channel 113 1 2 3 4 5 6 114 ___________________________________________________________ 115 2 stereo l r 116 3 l r c 117 4 quadrophonic Fl Fr Rl Rr 118 4 l c r S 119 5 Fl Fr Fc Sl Sr 120 6 l lc c r rc S 122 (From RFC 1890 section 4.1) 124 4. IANA registration form for Audio/L16 126 MIME media type name : Audio 128 draft Audio/L16 November 97 130 MIME subtype name : L16 132 Required parameters 133 rate: number of samples per second -- Permissible values for 134 rate are 8000, 11025, 1600, 22050, 24000, 32000, 44100, and 135 48000 samples per second. 137 Optional parameters 138 channels: how many audio streams are interleaved -- defaults 139 to 1; stereo would be 2, etc. Interleaving takes place 140 between individual two-byte samples. 142 Encoding considerations 143 Audio data is binary data, and must be encoded for non-binary 144 transport; the Base64 encoding is suitable for Email. Note 145 that audio data does not compress easily using lossless 146 compression. 148 Security considerations 149 Audio data is believed to offer no security risks. 151 Interoperability considerations 153 This type is compatible with the encoding used in the WAV 154 (Microsoft Windows RIFF) and Apple AIFF union types, and with 155 the public domain "sox" and "rateconv" programs. 157 Published specification 158 <<< Replace with RFC number at publication >>> 160 Applications which use this media 161 The public domain "sox" and "rateconv" programs accept this 162 type. 164 1. Magic number(s) : None 165 2. File extension(s) : WAV L16 166 3. Macintosh file type code : AIFF 168 draft Audio/L16 November 97 170 Person to contact for further information 172 1. Name : James Salsman 173 2. E-mail : jps-L16@bovik.org 175 Intended usage 176 Common 178 It is expected that many audio and speech applications will 179 use this type. Already the most popular platforms provide 180 this type with the rate=11025 parameter referred to as "radio 181 quality speech." 183 Author/Change controller 184 James Salsman 186 5. Security considerations 188 The audio data is believed to offer no security risks. 190 Note that RFC 1890 permits an application to choose to play a 191 single channel from a multichannel tranmission; an attacker who 192 knows that two different users will pick different channels could 193 concievably construct some confusing messages; this, however, is 194 ridiculous. 196 This type is perfect for hiding data using steganography. 198 6. References 200 [1] Audio-Video Transport Working Group, H. Schulzrinne: RTP 201 Profile for Audio and Video Conferences with Minimal Control, 202 RFC 1890, January 1996 204 7. Author's address 205 James Salsman 206 575 S. Rengstorff Avenue 207 Mountain View, CA 94040-1982 US 209 draft Audio/L16 November 97 211 James@bovik.org 213 Harald Tveit Alvestrand 214 UNINETT 215 N-7034 TRONDHEIM 216 NORWAY 218 +47 73 59 70 94 219 Harald.T.Alvestrand@uninett.no