doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

diff --git a/doc/rfc/rfc2423.txt b/doc/rfc/rfc2423.txt
new file mode 100644
index 0000000..62585f9
--- /dev/null
+++ b/doc/rfc/rfc2423.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                         G. Vaudreuil
+Request for Comments: 2423                             Lucent Technologies
+Obsoletes: 1911                                                 G. Parsons
+Category: Standards Track                                 Northern Telecom
+                                                            September 1998
+
+
+                           VPIM Voice Message
+                       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
+   multipart/voice-message for use with the Voice Profile for Internet
+   Mail (VPIM).  A full description of usage can be found in the VPIM v2
+   specification.
+
+1.  Abstract
+
+   This document describes the registration of the MIME sub-type
+   multipart/voice-message for use with the Voice Profile for Internet
+   Mail (VPIM).  A full description of usage can be found in the VPIM v2
+   specification [VPIM2].  This document revises an earlier sub-type
+   registration in RFC 1911 [VPIM1].
+
+2. VPIM Scope
+
+   The VPIM specification defines a restricted profile of the Internet
+   multimedia messaging protocols for use between voice processing
+   platforms.  These platforms have historically been special-purpose
+   computers and often do not have the same facilities normally
+   associated with a traditional Internet Email-capable computer.  As a
+   result, VPIM also specifies additional functionality as it is needed.
+   The profile is intended to specify the minimum common set of features
+   to allow interworking between compliant systems.
+
+
+
+
+Vaudreuil & Parsons         Standards Track                     [Page 1]
+
+RFC 2423                multipart/voice-message           September 1998
+
+
+   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].
+
+3. Voice Message Interchange
+
+3.1 multipart/voice-message
+
+   The MIME sub-type multipart/voice-message is defined to hold specific
+   media contents that are interchanged in messages between voice
+   messaging systems described in [VPIM2].  Essentially, the sub-type
+   provides a simple wrapper that easily identifies the entire content
+   as being the components of a single voice message.  The sub-type is
+   identical in semantics and syntax to multipart/mixed, as defined in
+   [MIME2].  As such, it may be safely interpreted as a multipart/mixed
+   by systems that do not understand the sub-type (only the
+   identification as a voice message would be lost).
+
+   This mechanism allows the insertion of an explanatory preamble (e.g.
+   VPIM voice message attached) for recipients who read the message with
+   pre-MIME software, since the preamble will be ignored by MIME-
+   compliant software.
+
+   In addition to the MIME required boundary parameter, a version
+   parameter is also required for this sub-type.  This is to
+   distinguish, this refinement of the sub-type from the previous
+   definition in [VPIM1].  The value of the version parameter is "2.0"
+   if the content conforms to the requirements of [VPIM2].  Should there
+   be further revisions of this content type, there MUST be backwards
+   compatibility (i.e. systems implementing version n can read version
+   2, and systems implementing version 2 can read version 2 contents
+   within a version n).  The default version value (when the parameter
+   is missing) is 1, indicating the content conforms to the requirements
+   of [VPIM1].
+
+   [VPIM2] describes the restriction that only specific media types,
+   applicable to voice messaging, are valid `next-level' contents of
+   this sub-type (when version=2.0).  They are: audio/*, image/*,
+   message/rfc822 and application/directory.  The multipart provides for
+   the packaging of as many of these contents as is necessary.
+
+3.2 VPIM v2 Usage
+
+   The multipart/voice-message sub-type is a primary component of the
+   VPIM specification [VPIM2].  All VPIM Messages MUST contain this
+   sub-type to identify the wrapping of a voice message.  The contents
+   of this wrapper can vary from only one audio/32KADPCM content to a
+   complex set of related and nested contents.
+
+
+
+Vaudreuil & Parsons         Standards Track                     [Page 2]
+
+RFC 2423                multipart/voice-message           September 1998
+
+
+   Typically, if more than one audio segment is present, the first is
+   the spoken name of the originator, the second is the spoken subject,
+   and the third is the voice message itself.  This order, however, MUST
+   NOT be assumed in any case.  Further, the order that the contents
+   appear SHOULD be the order in which they are presented to the user.
+
+   The spoken name segment, if available, shall contain the name of the
+   message sender in the voice of the sender.  The length of the spoken
+   name segment must not exceed 12 seconds.
+
+   The spoken subject segment, if available, shall contain the subject
+   of the message sender in the voice of the sender.  The length of the
+   spoken subject segment must not exceed 20 seconds.
+
+   The directory information part, if present, will contain information
+   specific to the orginator of the voice message.
+
+   Refer to the VPIM v2 Specification for details on proper usage.
+
+4.  IANA Registration
+
+   To: ietf-types@iana.org
+   Subject: Registration of MIME media type
+             multipart/voice-message
+
+   MIME media type name: multipart
+
+   MIME subtype name: voice-message
+
+   Required parameters: boundary, version
+
+      The use of boundary is defined in [MIME2]
+
+      The version parameter that contains the value "2.0" if
+      enclosed content conforms to [VPIM2].  The absence of this
+      parameter indicates conformance to the previous version
+      defined in RFC 1911 [VPIM1].
+
+   Optional parameters: none
+
+   Encoding considerations: 7bit, 8bit or Binary
+
+   Security considerations:
+
+      This definition identifies the content as being a voice
+      message.  In some environments (though likely not the
+      majority), the loss of the anonymity of the content may be a
+      security issue.
+
+
+
+Vaudreuil & Parsons         Standards Track                     [Page 3]
+
+RFC 2423                multipart/voice-message           September 1998
+
+
+   Interoperability considerations:
+
+      Systems developed to conform with [VPIM1] may not conform to
+      this registration.  Specifically, the required version will
+      likely be absent, in this case the recipient system should
+      still be able to accept the message and will be able to
+      handle the content.  The VPIM v1 positional identification,
+      however, would likely be lost.
+
+   Published specification:
+       This document
+       [VPIM2]
+
+   Applications which use this media type:
+
+     Primarily voice messaging
+
+   Additional information:
+
+     Magic number(s): ?
+     File extension(s): .VPM
+     Macintosh File Type Code(s): VPIM
+
+   Person & email address to contact for further information:
+
+     Glenn W. Parsons
+     Glenn.Parsons@Nortel.ca
+
+     Gregory M. Vaudreuil
+     Greg.Vaudreuil@Octel.Com
+
+   Intended usage: COMMON
+
+   Author/Change controller:
+
+     Glenn W. Parsons & Gregory M. Vaudreuil
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                     [Page 4]
+
+RFC 2423                multipart/voice-message           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
+
+   [MIME2] Freed, N., and N. Borenstein,  "Multipurpose Internet Mail
+           Extensions (MIME) Part Two: Media Types ", RFC 2046, November
+           1996.
+
+   [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.
+
+   [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 2423                multipart/voice-message           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]
+