doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc3802.txt b/doc/rfc/rfc3802.txt
new file mode 100644
index 0000000..706afcf
--- /dev/null
+++ b/doc/rfc/rfc3802.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                       G. Vaudreuil
+Request for Comments: 3802                           Lucent Technologies
+Obsoletes: 2422                                               G. Parsons
+Category: Standards Track                                Nortel Networks
+                                                               June 2004
+
+
+    Toll Quality Voice - 32 kbit/s Adaptive Differential Pulse Code
+             Modulation (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 (2004).
+
+Abstract
+
+   This document describes the registration of the MIME sub-type
+   audio/32KADPCM Adaptive Differential Pulse Code Modulation for toll
+   quality audio.  This audio encoding is defined by the ITU-T in
+   Recommendation G.726.
+
+1.  Introduction
+
+   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
+   obsoletes an earlier sub-type registration contained in RFC 1911.
+   This document also obsoletes RFC 2422.
+
+   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].
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil, et al.           Standards Track                     [Page 1]
+
+RFC 3802                    32 kbit/s ADPCM                    June 2004
+
+
+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 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 Specification for proper usage.
+
+
+
+
+
+
+Vaudreuil, et al.           Standards Track                     [Page 2]
+
+RFC 3802                    32 kbit/s ADPCM                    June 2004
+
+
+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 Macintosh File Type
+         Code(s):  APCM
+
+
+
+
+
+
+
+Vaudreuil, et al.           Standards Track                     [Page 3]
+
+RFC 3802                    32 kbit/s ADPCM                    June 2004
+
+
+          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 gparsons@NortelNetworks.com
+
+        Gregory M. Vaudreuil GregV@ieee.org
+
+      Intended usage: COMMON
+
+      Author/Change controller:
+
+        Glenn W. Parsons & Gregory M. Vaudreuil
+
+5.  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.
+
+
+
+
+
+
+
+Vaudreuil, et al.           Standards Track                     [Page 4]
+
+RFC 3802                    32 kbit/s ADPCM                    June 2004
+
+
+6.  References
+
+6.1.  Normative 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).
+
+   [VPIM2R2]  Vaudreuil, G., and G. Parsons, "Voice Profile for Internet
+              Mail - version 2 (VPIMv2)", RFC 3801, June 2004.
+
+   [REQ]      Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+6.2.  Informative References
+
+   [RFC 3023] Murata, M., St. Laurent, S. and D. Kohn, "XML Media
+              Types", RFC 3023, January 2001.
+
+   [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.
+
+7.  Changes from RFC 2422
+
+   Only editorial and boilerplate changes from RFC 2422 have been made
+   to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil, et al.           Standards Track                     [Page 5]
+
+RFC 3802                    32 kbit/s ADPCM                    June 2004
+
+
+8.  Authors' Addresses
+
+   Gregory M. Vaudreuil
+   Lucent Technologies
+   7291 Williamson Rd
+   Dallas, TX  75214
+   United States
+
+   EMail: gregv@ieee.org
+
+
+   Glenn W. Parsons
+   Nortel Networks
+   P.O. Box 3511, Station C
+   Ottawa, ON  K1Y 4H7
+   Canada
+
+   Phone: +1-613-763-7582
+   Fax:   +1-613-763-2697
+   EMail: gparsons@nortelnetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil, et al.           Standards Track                     [Page 6]
+
+RFC 3802                    32 kbit/s ADPCM                    June 2004
+
+
+9.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+Vaudreuil, et al.           Standards Track                     [Page 7]
+