doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

diff --git a/doc/rfc/rfc2422.txt b/doc/rfc/rfc2422.txt
new file mode 100644
index 0000000..da308b5
--- /dev/null
+++ b/doc/rfc/rfc2422.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                         G. Vaudreuil
+Request for Comments: 2422                             Lucent Technologies
+Obsoletes: 1911                                                 G. Parsons
+Category: Standards Track                                 Northern Telecom
+                                                            September 1998
+
+
+                  Toll Quality Voice - 32 kbit/s ADPCM
+                       MIME Sub-type Registration
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+Overview
+
+   This document describes the registration of the MIME sub-type
+   audio/32KADPCM for toll quality audio.  This audio encoding is
+   defined by the ITU-T in Recommendation G.726.
+
+1.  Abstract
+
+   This document describes the registration of the MIME sub-type
+   audio/32KADPCM for toll quality audio.  This audio encoding is
+   defined by the ITU-T in Recommendation G.726.  This document refines
+   an earlier sub-type registration in RFC 1911.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [REQ].
+
+2. ITU-T Definition
+
+   Recommendation G.726 [G726] defines the characteristics that are
+   recommended for the conversion of a 64 kbit/s A-law or m-law pulse
+   code modulation (PCM) channel at 8000 samples/second to and from a
+   40, 32, 24 or 16 kbit/s channel. The conversion is applied to the PCM
+
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                     [Page 1]
+
+RFC 2422                    32 kbit/s ADPCM               September 1998
+
+
+   bit stream using an adaptive differential pulse code modulation
+   (ADPCM) transcoding technique.  This Recommendation obsoletes G.721
+   which only defined the 32 kbit/s characteristics.
+
+   Recommendation G.726 was prepared by Study Group 15 of the
+   Telecommunications Standardization Sector of the International
+   Telecommunication Union (ITU-T) and was approved under the ITU's
+   Resolution No. 2 procedure on the 14 of December 1990.
+
+3. MIME Definition
+
+3.1 audio/32KADPCM
+
+   CCITT Recommendation G.726 [G726] describes the algorithm recommended
+   for conversion of a 64 kbit/s A-law or u-law PCM channel to and from
+   a 32 kbit/s channel (this is the same algorithm as described in the
+   deprecated G.721).  The conversion is applied to the PCM stream using
+   an Adaptive Differential Pulse Code Modulation (ADPCM) transcoding
+   technique.
+
+   The MIME sub-type audio/32KADPCM is defined to hold binary audio data
+   encoded in 32 kbit/s ADPCM exactly as defined by ITU-T Recommendation
+   G.726.  No header information shall be included as part of the audio
+   data.  The content transfer encoding is typically either binary or
+   base64.
+
+   An additional consideration that this document defines for clarity is
+   the choice of little endian ordering of the four bit code words.
+   This default ordering is defined in ITU-T Recommendation X.420 [X420]
+   for the equivalent X.400 body part, but is also detailed below in the
+   IANA Registration.
+
+3.2 VPIM Usage
+
+   The audio/32KADPCM sub-type is a primary component of the VPIM
+   specification [VPIM].  In this context, the Content-Description and
+   Content-Disposition headers are used to succinctly describe the
+   contents of the audio body.  As well, only the little endian bit
+   ordering is valid.  Refer to the VPIM Specifcation for proper usage.
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                     [Page 2]
+
+RFC 2422                    32 kbit/s ADPCM               September 1998
+
+
+4.  IANA Registration
+
+   To: ietf-types@iana.org
+   Subject: Registration of MIME media type audio/32KADPCM
+
+   MIME media type name: audio
+
+   MIME subtype name: 32KADPCM
+
+   Required parameters: none
+
+   Optional parameters: none
+
+   Encoding considerations:
+
+      Binary or Base-64 generally preferred
+
+   Security considerations:
+
+      There are no known security risks with the sending or
+      playing of raw audio data  Audio data is typically
+      interpreted only by an audio codec.  Unintended information
+      introduced into the data stream will result in noise.
+
+
+   Interoperability considerations:
+
+      The four bit code word ordering within a byte may differ
+      between existing implementations of G.726 codecs.  Since
+      this content only permits the little endian ordering, codecs
+      that support the opposite ordering must reorder the code
+      words before storing to or retrieving from this content
+      type.
+
+
+   Published specification:
+
+           ITU-T G.726 with little endian ordering
+
+   Applications which use this media type:
+
+           primarily voice messaging
+
+   Additional information:
+
+     Magic number(s): ?
+     File extension(s): .726
+
+
+
+
+Vaudreuil & Parsons         Standards Track                     [Page 3]
+
+RFC 2422                    32 kbit/s ADPCM               September 1998
+
+
+     Macintosh File Type Code(s):  APCM
+
+      Little Endian Ordering:
+
+      The 4-bit code words of the G.726 encoding MUST be packed
+      into octets/bytes as follows:  the first code word (A) is
+      placed in the four least significant bits of the first
+      octet, with the least significant bit (LSB) of the code word
+      (A0) in the least significant bit of the octet;  the second
+      code word (B) is placed in the four most significant bits of
+      the first octet, with the most significant bit (MSB) of the
+      code word (B3) in the most significant bit of the octet.
+      Subsequent pairs of the code words shall be packed in the
+      same way into successive octets, with the first code word of
+      each pair placed in the least significant four bits of the
+      octet.  It is preferred that the voice sample be extended
+      with silence such that the encoded value comprises an even
+      number of code words.  However, if the voice sample
+      comprises an odd number of code words, then the last code
+      word shall be discarded.
+
+
+              +--+--+--+--+--+--+--+--+
+              |B3|B2|B1|B0|A3|A2|A1|A0|
+              +--+--+--+--+--+--+--+--+
+      MSB ->  | 7| 6| 5| 4| 3| 2| 1| 0|  <- LSB
+              +--+--+--+--+--+--+--+--+
+
+              32K ADPCM / Octet Mapping
+
+
+   Person & email address to contact for further information:
+
+     Glenn W. Parsons
+     Glenn.Parsons@Nortel.ca
+
+     Gregory M. Vaudreuil
+     GregV@Lucent.Com
+
+   Intended usage: COMMON
+
+   Author/Change controller:
+
+     Glenn W. Parsons & Gregory M. Vaudreuil
+
+
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                     [Page 4]
+
+RFC 2422                    32 kbit/s ADPCM               September 1998
+
+
+5. Authors' Addresses
+
+   Glenn W. Parsons
+   Northern Telecom
+   P.O. Box 3511, Station C
+   Ottawa, ON  K1Y 4H7
+   Canada
+
+   Phone: +1-613-763-7582
+   Fax: +1-613-763-4461
+   EMail: Glenn.Parsons@Nortel.ca
+
+
+   Gregory M. Vaudreuil
+   Lucent Technologies
+   17080 Dallas Parkway
+   Dallas, TX  75248-1905
+   United States
+
+   Phone/Fax: +1-972-733-2722
+   EMail:GregV@Lucent.Com
+
+6. References
+
+   [G726] CCITT Recommendation G.726 (1990), General Aspects of Digital
+          Transmission Systems, Terminal Equipment - 40, 32, 24,16
+          kbit/s Adaptive Differential Pulse Code Modulation (ADPCM).
+
+   [MIME4] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
+           Mail Extensions (MIME) Part Four: Registration Procedures",
+           RFC 2048, November 1996.
+
+   [VPIM1] Vaudreuil, G., "Voice Profile for Internet Mail", RFC 1911,
+           February 1996.
+
+   [VPIM2] Vaudreuil, G., and G. Parsons, "Voice Profile for Internet
+           Mail - version 2", RFC 2421, September 1998.
+
+   [X420] ITU-T Recommendation X.420 (1996) - ISO/IEC 10021-7:1996,
+          Message handling systems: Interpersonal messaging.
+
+   [REQ] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                     [Page 5]
+
+RFC 2422                    32 kbit/s ADPCM               September 1998
+
+
+7.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implmentation may be prepared, copied, published and
+   distributed, in whole or in part, without restriction of any kind,
+   provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                     [Page 6]
+