From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2423.txt | 339 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 339 insertions(+) create mode 100644 doc/rfc/rfc2423.txt (limited to 'doc/rfc/rfc2423.txt') 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] + -- cgit v1.2.3