RFC 3801
Voice Profile for Internet Mail - version 2 (VPIMv2)
5. Message Transport Protocol
Messages are transported between voice mail machines using the Internet Extended Simple Mail Transfer Protocol (ESMTP). All information required for proper delivery of the message is included in the ESMTP dialog. This information, including the sender and recipient addresses, is commonly referred to as the message "envelope". This information is equivalent to the message control block in many analog voice messaging protocols. ESMTP is a general-purpose messaging protocol, designed both to send mail and to allow terminal console messaging. Simple Mail Transport Protocol (SMTP) was originally created for the exchange of US-ASCII 7-bit text messages. Binary and 8-bit text messages have
traditionally been transported by encoding the messages into a 7-bit text-like form. [ESMTP] formalized an extension mechanism for SMTP, and subsequent RFCs have defined 8-bit text networking, command streaming, binary networking, and extensions to permit the declaration of message size for the efficient transmission of large messages such as multi-minute voice mail. The following sections list ESMTP commands, keywords, and parameters that are required and those that are optional for conformance to this profile.5.1. Base SMTP Protocol
A conforming system MUST implement all mandatory SMTP and ESMTP commands. Any defined optional command or parameter MAY be supported.5.2. SMTP Service Extensions
VPIM utilizes a number of SMTP Service Extensions to provide full- featured voice messaging service. The following extensions are profiled for use with VPIM:5.2.1. DSN Extension
The DSN extension defines a mechanism which allows an SMTP client to specify (a) DSN's should be generated under certain conditions, (b) whether such DSN's should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent. The DSN extension MUST be supported by VPIM conforming implementations. In addition, beyond the requirements of [DRPT], conforming implementations MUST support NOTIFY parameter on the RCPT command to allow indication of when the originator requests a notification. The RET parameter SHOULD be supported to return the original message with the notification. Parameters ORCPT and ENVID MAY also be supported. From: [DRPT]5.2.2. SIZE Extension
The SIZE extension defines a mechanism whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. From: [SIZE]
The SIZE extension MUST be supported by VPIM-compliant implementations.5.2.3. ENHANCEDSTATUSCODES Extension
The ENHANCEDSTATUSCODES extension defines a mechanism whereby an SMTP server augments its responses with the enhanced mail system status codes defined in [CODES]. These codes can then be used to provide more informative explanations of error conditions. From: [STATUS] The ENHANCEDSTATUSCODES extension SHOULD be supported by VPIM- compliant implementations.5.2.4. PIPELINING Extension
The PIPELINING extension defines a mechanism whereby an SMTP server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. Using a single TCP send operation for multiple commands can improve SMTP performance significantly. From [PIPE] The PIPELINING extension SHOULD be supported by VPIM-compliant implementations.5.2.5. CHUNKING Extension
The CHUNKING extension defines a mechanism that enables an SMTP client and server to negotiate the use of the message data transfer command "BDAT" (in alternative to the DATA command) for efficiently sending large MIME messages. From: [BINARY] The CHUNKING extension MAY be supported by VPIM-compliant implementations.5.2.6. BINARYMIME Extension
The BINARYMIME extension defines a mechanism that enables an SMTP client and server to negotiate the transfer of unencoded binary message data utilizing the BDAT command. From: [BINARY] The BINARYMIME extension MAY be supported by VPIM-compliant implementations. Note that [BINARY] specifies that if BINARYMIME is to be supported, then CHUNKING has to be supported by definition.
5.3. ESMTP - SMTP Downgrading
The SMTP extensions suggested or required for conformance to VPIM fall into two categories. The first category includes features that increase the efficiency of the transport system such as SIZE, BINARYMIME, and PIPELINING. In the event of a downgrade to a less- functional transport system, these features can be dropped with no functional change to the sender or recipient. The second category of features is transport extensions in support of new functions. DSN and ENHANCEDSTATUSCODES provide essential improvements in the handling of delivery status notifications to bring email to the level of reliability expected of Voice Mail. To ensure a consistent level of service across an intranet or the global Internet, it is essential that VPIM-conforming ESMTP support the DSN extension at all hops between a VPIM originating system and the recipient system. In the situation where a "downgrade" is unavoidable a relay hop may be forced (by the next hop) to forward a VPIM message without the ESMTP request for delivery status notification. It is RECOMMENDED that the downgrading system should continue to attempt to deliver the message, but MUST send an appropriate delivery status notification to the originator, e.g., the message left an ESMTP host and was sent relayed to a non-DSN-aware destination, and this may be the last DSN received.6. Directory Address Resolution
It is the responsibility of a VPIM system to provide the fully- qualified domain name (FQDN) of the recipient based on the address entered by the user (if the entered address is not already a FQDN). This would typically be an issue on systems that offer only a telephone user interface. The mapping of the dialed target number to a routable FQDN address, allowing delivery to the destination system, can be accomplished through implementation-specific means. To facilitate a local cache, an implementation may wish to populate local directories with the first and last names, as well as the senders' spoken name information extracted from received messages. Addresses or names parsed from the header fields of VPIM messages MAY be used to populate directories.7. Management Protocols
The Internet protocols provide a mechanism for the management of messaging systems, from the management of the physical network through the management of the message queues. SNMP SHOULD be supported on a VPIM-conforming machine.
7.1. Network Management
The digital interface to the VM and the TCP/IP protocols MAY be managed. MIB II MAY be implemented to provide basic statistics and reporting of TCP and IP protocol performance [MIB II].8. Conformance Requirements
VPIM is a messaging application that will be supported in several environments and be supported on differing devices. These environments include traditional voice processing systems, desktop voice messaging systems, store-and-forward relays, and protocol translation gateways. In order to accommodate all environments, this document defines two areas of conformance: transport and content. Transport-conformant systems will pass VPIM messages in a store-and- forward manner with assured delivery notifications and without the loss of information. It is expected that most store-and-forward Internet mail-based messaging systems will be VPIM transport- conformant. Content-conformant systems will generate and interpret VPIM messages. Conformance in the generation of VPIM messages indicates that the restrictions of this profile are honored. Only contents specified in this profile or extensions agreed to by bilateral agreement may be sent. Conformance in the interpretation of VPIM messages indicates that all VPIM content types and constructs can be received; that all mandatory VPIM content types can be decoded and presented to the recipient in an appropriate manner; and that any unrenderable contents result in the appropriate notification. A summary of the conformance requirements is contained in Appendix A. VPIM end systems are expected to be both transport- and content- conformant. Voice messaging systems and protocol conversion gateways are considered end systems. Relay systems are expected to be transport-conformant in order to receive and send conforming messages. However, they must also create VPIM-conforming delivery status notifications in the event of delivery problems. Desktop Email clients that support VPIM are expected to be content- conformant. Desktop email clients use various protocols and API's for exchanging messages with the local message store and message transport system. While these clients may benefit from VPIM
transport capabilities, specific client-server requirements are out- of-scope for this document.9. Security Considerations
9.1. General Directive
This document is a profile of existing Internet mail protocols. To maintain interoperability with Internet mail, any security to be provided should be part of the Internet security infrastructure, rather than a new mechanism or some other mechanism outside of the Internet infrastructure.9.2. Threats and Problems
Both Internet mail and voice messaging have their own set of threats and countermeasures. As such, this specification does not create any security issues not already existing in the profiled Internet mail and voice mail protocols themselves. This section attends only to the set of additional threats that ensue from integrating the two services.9.2.1. Spoofed sender
The actual sender of the voice message might not be the same as that specified in the "Sender:" or "From:" message header fields or the MAIL FROM address from the SMTP envelope. In a tightly constrained environment, sufficient physical and software controls may be able to ensure prevention of this problem. In addition, the recognition of the sender's voice may provide confidence of the sender's identity irrespective of that specified in "Sender:" or "From:". It should be recognized that SMTP implementations do not provide inherent authentication of the senders of messages, nor are sites under obligation to provide such authentication.9.2.2. Unsolicited voice mail
Assigning an Internet mail address to a voice mailbox opens the possibility of receiving unsolicited messages (either text or voice mail). Traditionally, voice mail systems operated in closed environments and were not susceptible to unknown senders. Voice mail users have a higher expectation of mailbox privacy and may consider such messages as a security breach. Many Internet mail systems are choosing to block all messages from unknown sources in an attempt to curb this problem.
9.2.3. Message disclosure
Users of voice messaging systems have an expectation of a level of message privacy that is higher than the level provided by Internet mail without security enhancements. This expectation of privacy by users SHOULD be preserved as much as possible.9.3. Security Techniques
Sufficient physical and software control may be acceptable in constrained environments. Further, the profile specified in this document does not in any way preclude the use of any Internet object or channel security protocol to encrypt, authenticate, or non- repudiate the messages.10. Normative References
[8BIT] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994. [ADPCM] Vaudreuil, G. and G. Parsons, "Toll Quality Voice - 32 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM) MIME Sub-type Registration", RFC 3802, June 2004. [AMIS-A] Audio Messaging Interchange Specifications (AMIS) - Analog Protocol Version 1, Issue 2, February 1992. [AMIS-D] Audio Messaging Interchange Specifications (AMIS) - Digital Protocol Version 1, Issue 3, August 1993. [BINARY] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000. [CODES] Vaudreuil, G. "Enhanced Mail System Status Codes", RFC 1893, January 1996. [MIMEDIR] Dawson, F., Howes, T. and M. Smith, "A MIME Content-Type for Directory Information", RFC 2425, September 1998. [DISP] Troost, R. and S. Dorner, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header", RFC 2183, August 1997. [DNS1] Mockapetris, P., "Domain names - implementation and specification", RFC 1035, November 1987.
[DNS2] Mockapetris, P., "Domain names - concepts and facilities", RFC 1034, November 1987. [DRPT] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003. [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003. [DUR] Parsons, G. and G. Vaudreuil, "Content Duration MIME Header Definition", RFC 3803, June 2004. [E164] CCITT Recommendation E.164 (1991), Telephone Network and ISDN Operation, Numbering, Routing and Mobile Service - Numbering Plan for the ISDN Era. [ESMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [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). [HOSTREQ] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989. [LANG] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001. [MDN] Hansen, T., Ed. and G. Vaudreuil, Ed., "Message Disposition Notification", RFC 3798, May 2004. [MIB II] Rose, M., "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", RFC 1213, March 1991. [MIME1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [MIME2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types ", RFC 2046, November 1996.
[MIME3] Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part Three: Message Header Extensions for Non-ASCII Text ", RFC 2047, November 1996. [MIME4] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996. [MIME5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples ", RFC 2049, November 1996. [PIPE] Freed, N.and A. Cargille, "SMTP Service Extension for Command Pipelining" STD 60, RFC 2920, September 2000. [REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003. [REQ] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982. [SIZE] Klensin, J., Freed, N. and K. Moore, "SMTP Service Extensions for Message Size Declaration" STD 10, RFC 1870, November 1995. [STATUS] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996. [TIFF-F] Parsons, G. and J. Rafferty, "Tag Image File Format: Application F", RFC 2306, March 1998. [TIFFREG] Parsons, G., Rafferty, J. and S. Zilles, "Tag Image File Format: image/tiff - MIME sub-type registration", RFC 2302, March 1998. [V-MSG] Vaudreuil, G. and G. Parsons, "VPIM Voice Message MIME Sub-type Registration", RFC 2423, September 1998. [VCARD] Dawson, F. and T. Howes, "vCard MIME Directory Profile" RFC 2426, September 1998. [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. [X.400] CCITT/ISO, "CCITT Recommendations X.400/ ISO/IEC 10021-1, Message Handling: System and Service Overview", December 1988.11. Acknowledgments
The authors would like to offer a special thanks to the Electronic Messaging Association (EMA), especially the members of the Voice Messaging Committee, and the IETF VPIM Work Group, for their support of the VPIM specification and the efforts they have made to ensure its success.
12. Appendix A - VPIM Requirements Summary
The following table summarizes the profile of VPIM version 2 detailed in this document. Since in many cases it is not possible to simplify the qualifications for supporting each feature this appendix is informative. The reader is recommended to read the complete explanation of each feature in the referenced section. The text in the previous sections shall be deemed authoritative if any item in this table is ambiguous. The conformance table is separated into various columns: Feature - name of protocol feature (note that the indenting indicates a hierarchy of conformance, i.e., the conformance of a lower feature is only relevant if there is conformance to the higher feature) Section - reference section in main text of this document Area - conformance area to which each feature applies: C - content T - transport Status - whether the feature is mandatory, optional, or prohibited. The key words used in this table are to be interpreted as described in [REQ], though the following list gives a quick overview of the different degrees of feature conformance: Must - mandatory Should - required in the absence of a compelling need to omit. May - optional Should not - prohibited in the absence of a compelling need. Must not - prohibited Footnote - special comment about conformance for a particular feature
VPIM version 2 Conformance
| | | | |S| |
| | | | | |H| |F
| | | | | |O|M|o
| | | |S| |U|U|o
| | | |H| |L|S|t
| |A|M|O| |D|T|n
| |R|U|U|M| | |o
| |E|S|L|A|N|N|t
| |A|T|D|Y|O|O|t
FEATURE |SECTION | | | | |T|T|e
-------------------------------------------|----------|-|-|-|-|-|-|-
| | | | | | | |
Message Addressing Formats: | | | | | | | |
Use DNS host names |4.1 |C|x| | | | |
Use only numbers in mailbox IDs |4.1.1 |C| |x| | | |
Numbers in mailbox IDs follow E.164 |4.1.1 |C| |x| | | |
Use alpha-numeric mailbox IDs |4.1.1 |C| | |x| | |
Support of postmaster@domain |4.1.2 |C|x| | | | |
Support of non-mail-user@domain |4.1.2 |C| |x| | | |
Support of distribution lists |4.1.3 |C| | |x| | |
| | | | | | | |
Message Header Fields: | | | | | | | |
Sending outbound messages | | | | | | | |
From |4.2.1 |C|x| | | | |
Addition of text name |4.2.1 |C| |x| | | |
Same value as MAIL FROM |4.2.1 |C| |x| | | |
To |4.2.2 |C| |x| | | |1
cc |4.2.3 |C| | |x| | |1
Date |4.2.4 |C|x| | | | |
Sender |4.2.5 |C| | |x| | |
Return-Path |4.2.6 |C| | | | |x|
Message-ID |4.2.7 |C|x| | | | |
Reply-To |4.2.8 |C| | | |x| |
Received |4.2.9 |C|x| | | | |
MIME Version: 1.0 (Voice 2.0) |4.2.10 |C| |x| | | |
Content-Type |4.2.11 |C|x| | | | |
Content-Transfer-Encoding |4.2.12 |C|x| | | | |
Sensitivity |4.2.13 |C| | |x| | |
Importance |4.2.14 |C| | |x| | |
Subject |4.2.15 |C| |x| | | |
Disposition-notification-to |4.7 |C| |x| | | |
Other Headers |4.2 |C| | |x| | |
| | | | | | | |
| | | | | |H| |F
| | | | | |O|M|o
| | | |S| |U|U|o
| | | |H| |L|S|t
| |A|M|O| |D|T|n
| |R|U|U|M| | |o
| |E|S|L|A|N|N|t
| |A|T|D|Y|O|O|t
FEATURE |SECTION | | | | |T|T|e
-------------------------------------------|----------|-|-|-|-|-|-|-
Receiving inbound messages | | | | | | | |
From |4.2.1 |C|x| | | | |
Present text personal name |4.2.1 |C| | |x| | |
To |4.2.2 |C|x| | | | |
cc |4.2.3 |C| | |x| | |
Date |4.2.4 |C|x| | | | |
Conversion of Date to local time |4.2.4 |C| |x| | | |
Sender |4.2.5 |C| | |x| | |
Return-Path |4.2.6 |C| |x| | | |
Message-ID |4.2.7 |C| | |x| | |
MDN requested |4.2.7 |C|x| | | | |
Reply-To |4.2.8 |C| | |x| | |
Received |4.2.9 |C| | |x| | |
MIME Version: 1.0 (Voice 2.0) |4.2.10 |C| |x| | | |
Content Type |4.2.11 |C|x| | | | |
Content-Transfer-Encoding |4.2.12 |C|x| | | | |
Sensitivity |4.2.13 |C|x| | | | |2
Importance |4.2.14 |C| | |x| | |
Subject |4.2.15 |C| | |x| | |
Disposition-notification-to |4.7 |C| |x| | | |
Other Headers |4.2 |C|x| | | | |3
| | | | | | | |
Message Content Encoding: | | | | | | | |
Sending outbound audio/fax contents | | | | | | | |
7BIT |4.2.12 |C| | | | |x|
8BIT |4.2.12 |C| | | | |x|
Quoted Printable |4.2.12 |C| | | | |x|
Base64 |4.2.12 |C|x| | | | |4
Binary |4.2.12 |C| |x| | | |5
Receiving inbound message contents | | | | | | | |
7BIT |4.2.12 |C|x| | | | |
8BIT |4.2.12 |C|x| | | | |
Quoted Printable |4.2.12 |C|x| | | | |
Base64 |4.2.12 |C|x| | | | |
Binary |4.2.12 |C|x| | | | |5
| | | | | | | |
| | | | |S| |
| | | | | |H| |F
| | | | | |O|M|o
| | | |S| |U|U|o
| | | |H| |L|S|t
| |A|M|O| |D|T|n
| |R|U|U|M| | |o
| |E|S|L|A|N|N|t
| |A|T|D|Y|O|O|t
FEATURE |SECTION | | | | |T|T|e
-------------------------------------------|----------|-|-|-|-|-|-|-
Message Content Types: | | | | | | | |
Sending outbound messages | | | | | | | |
Multipart/Voice-Message |4.4.1 |C|x| | | | |
Message/RFC822 |4.4.2 |C| |x| | | |
Audio/32KADPCM |4.4.3 |C|x| | | | |
Content-Description |4.3.1 |C| | |x| | |
Content-Disposition |4.3.2 |C|x| | | | |
Content-Duration |4.3.3 |C| | |x| | |
Content-Language |4.3.4 |C| | |x| | |
Image/TIFF; application=faxbw |4.4.4 |C|x| | | | |7
Text/Directory |4.5.2 |C| | | |x| |9
Text/plain |4.5.4 |C| | | |x| |
Audio/* or Image/* (other encodings) |4.5.3 |C| | | |x| |
Other contents |4.5 |C| | | | |x|
Multipart/Mixed |4.5.1 |C| | |x| | |
Text/plain |4.5.4 |C| | |x| | |
Multipart/Report |4.6, 4.7 |C|x| | | | |
human-readable part is voice |4.6, 4.7 |C| |x| | | |
human-readable part is text |4.6, 4.7 |C| | |x| | |
Message/Delivery-Status |4.6 |C|x| | | | |
Message/Disposition-Notification |4.7 |C| |x| | | |
Other contents |4.5 |C| | | |x| |6
Receiving in inbound messages | | | | | | | |
Multipart/Voice-Message |4.4.1 |C|x| | | | |
Message/RFC822 |4.4.2 |C|x| | | | |
Audio/32KADPCM |4.4.3 |C|x| | | | |
Content-Description |4.3.1 |C| | |x| | |
Content-Disposition |4.3.2 |C| |x| | | |
Content-Duration |4.3.3 |C| | |x| | |
Content-Language |4.3.4 |C| | |x| | |
Image/TIFF; application=faxbw |4.4.4 |C| |x| | | |8
Text/Directory |4.5.2 |C|x| | | | |9
Text/plain |4.5.4 |C| | |x| | |
Audio/* or Image/* (other encodings) |4.5.3 |C| | |x| | |
Other contents |4.5 |C| | |x| | |
Multipart/Mixed |4.5.1 |C| | |x| | |
| | | | | |S| |
| | | | | |H| |F
| | | | | |O|M|o
| | | |S| |U|U|o
| | | |H| |L|S|t
| |A|M|O| |D|T|n
| |R|U|U|M| | |o
| |E|S|L|A|N|N|t
| |A|T|D|Y|O|O|t
FEATURE |SECTION | | | | |T|T|e
------------------------------------------|-----------|-|-|-|-|-|-|-
| | | | | | | |
Text/plain |4.5.4 |C|x| | | | |
Multipart/Report |4.6, 4.7 |C|x| | | | |
human-readable part is voice |4.6, 4.7 |C|x| | | | |
human-readable part is text |4.6, 4.7 |C|x| | | | |
Message/Delivery-Status |4.6 |C|x| | | | |
Message/Disposition-Notification |4.7 |C| |x| | | |
Other contents |4.5 |C| | |x| | |6
| | | | | | | |
Forwarded Messages | | | | | | | |
use Message/RFC822 construct |4.8 |C| |x| | | |
simulate headers if none available |4.8 |C| |x| | | |
| | | | | | | |
Reply Messages |4.9 |C|x| | | | |
send to Reply-To, else From address |4.2.8 |C| | |x| | |
send to non-mail-user |4.9 |C| | | |x| |
| | | | | | | |
Notifications | | | | | | | |
use Multipart/Report format |4.6, 4.7 |C|x| | | | |
always send error on non-delivery |4.6 |C|x| | | | |
send error messages to return-path |4.2.6 |C|x| | | | |
| | | | | | | |
Message Transport Protocol: | | | | | | | |
Base ESMTP Commands | | | | | | | |
HELO |5.1 |T|x| | | | |
MAIL FROM |5.1 |T|x| | | | |
RCPT TO |5.1 |T|x| | | | |
DATA |5.1 |T|x| | | | |
TURN |5.1 |T| | | | |x|
QUIT |5.1 |T|x| | | | |
RSET |5.1 |T|x| | | | |
VRFY |5.1 |T| | |x| | |
EHLO |5.1 |T|x| | | | |
BDAT |5.1 |T| | |x| | |5
| | | | |S| |
| | | | | |H| |F
| | | | | |O|M|o
| | | |S| |U|U|o
| | | |H| |L|S|t
| |A|M|O| |D|T|n
| |R|U|U|M| | |o
| |E|S|L|A|N|N|t
| |A|T|D|Y|O|O|t
FEATURE |SECTION | | | | |T|T|e
-------------------------------------------|----------|-|-|-|-|-|-|-
| | | | | | | |
ESMTP Keywords & Parameters | | | | | | | |
DSN |5.2.1 |T|x| | | | |
NOTIFY |5.2.1 |T|x| | | | |
RET |5.2.1 |T| |x| | | |
ENVID |5.2.1 |T| | |x| | |
ORCPT |5.2.1 |T| | |x| | |
SIZE |5.2.2 |T|x| | | | |
ENHANCEDSTATUSCODES |5.2.3 |T| |x| | | |
PIPELINING |5.2.4 |T| |x| | | |
CHUNKING |5.2.5 |T| | |x| | |
BINARYMIME |5.2.6 |T| | |x| | |
| | | | | | | |
ESMTP-SMTP Downgrading | | | | | | | |
send delivery report upon downgrade |5.3 |T|x| | | | |
| | | | | | | |
Directory Address Resolution | | | | | | | |
provide facility to resolve addresses |6 |C| |x| | | |
use headers to populate local directory |6 |C| | |x| | |
| | | | | | | |
Management Protocols: | | | | | | | |
Network management |7.1 |T| | |x| | |
-------------------------------------------|----------|-|-|-|-|-|-|-
Footnotes:
1. SHOULD leave blank if all recipients are not known or resolvable.
2. If a sensitive message is received by a system that does not
support sensitivity, then it MUST be returned to the originator
with an appropriate error notification. Also, a received
sensitive message MUST NOT be forwarded to anyone.
3. If the additional header fields are not understood they MAY
be ignored.
4. When binary transport is not available.
5. When binary transport is available.
6. Other un-profiled contents MUST only be sent by bilateral
agreement.
7. If fax is supported.
8. If the fax content cannot be presented it MAY be dropped.
9. Handling of a vCard in text/directory is no longer defined.
13. Appendix B - Example Voice Messages
The following message is a full-featured message addressed to two
recipients. The message includes the sender's spoken name, spoken
subject and a short speech segment. The message is marked as
important and private.
To: +19725551212@vm1.mycompany.com
To: +16135551234@VM1.mycompany.com
From: "Parsons, Glenn" <12145551234@VM2.mycompany.com>
Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT)
MIME-Version: 1.0 (Voice 2.0)
Content-type: Multipart/Voice-Message; Version=2.0;
Boundary="MessageBoundary"
Content-Transfer-Encoding: 7bit
Message-ID: 123456789@VM2.mycompany.com
Sensitivity: Private
Importance: High
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Disposition: inline; voice=Originator-Spoken-Name
Content-Language: en-US
Content-ID: part1@VM2-4321
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd
(This is a sample of the base-64 Spoken Name data)
fgdhgddlkgpokpeowrit09==
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Disposition: inline; voice=Spoken-Subject
Content-Language: en-US
Content-ID: part2@VM2-4321
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd
(This is a sample of the base-64 Spoken Subject data)
fgdhgddlkgpokpeowrit09==
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Description: Brand X Voice Message
Content-Disposition: inline; voice=Voice-Message; filename=msg1.726
Content-Duration: 25
iIiIiIjMzN3czdze3s7d7fwfHhcvESJVe/4yEhLz8/FOQjVFRERCESL/zqrq
(This is a sample of the base64 message data) zb8tFdLTQt1PXj
u7wjOyRhws+krdns7Rju0t4tLF7cE0K0MxOTOnRW/Pn30c8uHi9==
--MessageBoundary- - - -
The following message is a forwarded single segment voice. Both the
forwarded message and the forwarding message contain the senders spoken
names.
To: +12145551212@vm1.mycompany.com
From: "Vaudreuil, Greg" <+19725552345@VM2.mycompany.com>
Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT)
MIME-Version: 1.0 (Voice 2.0)
Content-type: Multipart/Voice-Message; Version=2.0;
Boundary="MessageBoundary"
Content-Transfer-Encoding: 7bit
Message-ID: ABCD-123456789@VM2.mycompany.com
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Disposition: inline; voice=Originator-Spoken-Name
Content-Language: en-US
Content-ID: part3@VM2-4321
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd
(This is a sample of the base-64 Spoken Name data)
fgdhgd dlkgpokpeowrit09==
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Description: Forwarded Message Annotation
Content-Disposition: inline; voice=Voice-Message
Content-Transfer-Encoding: Base64
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd
(This is the voiced introductory remarks encoded in base64)
jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW
dlkgpokpeowrit09==
--MessageBoundary
Content-type: Message/RFC822
Content-Transfer-Encoding: 7bit
To: +19725552345@VM2.mycompany.com
From: "Parsons, Glenn, W." <+16135551234@VM1.mycompany.com>
Date: Mon, 26 Aug 93 8:23:10 -0500 (EST)
Content-type: Multipart/Voice-Message; Version=2.0;
Boundary="MessageBoundary2"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0 (Voice 2.0)
--MessageBoundary2
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Disposition: inline; voice=Originator-Spoken-Name
Content-Language: en-US
Content-ID: part6@VM2-4321
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd
(This is a sample of the base-64 Spoken Name data) fgdhgd
dlkgpokpeowrit09==
--MessageBoundary2
Content-type: Audio/32KADPCM
Content-Disposition: inline; voice=Voice-Message
Content-Transfer-Encoding: Base64
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd
(This is the original message audio data) fgwersdfmniwrjj
jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW
dlkgpokpeowrit09==
--MessageBoundary2--
--MessageBoundary--
The following example is for a DSN sent to the sender of a message by
a VPIM gateway at VM1.company.com for a mailbox which does not exist.
Date: Thu, 7 Jul 1994 17:16:05 -0400
From: Mail Delivery Subsystem <MAILER-DAEMON@vm.company.com>
Message-ID: <199407072116.RAA14128@vm1.company.com>
Subject: Returned voice message
To: 2175552345@VM2.mycompany.com
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="RAA14128.773615765/VM1.COMPANY.COM"
--RAA14128.773615765/VM1.COMPANY.COM
Content-type: Audio/32KADPCM
Content-Description: Spoken Delivery Status Notification
Content-Disposition: inline; voice= Voice-Message-Notification
Content-Transfer-Encoding: Base64
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadadffsssddasdasd
(This is a voiced description of the error in base64)
jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gdffkjpokfgW
dlkgpokpeowrit09==
--RAA14128.773615765/VM1.COMPANY.COM
Content-type: Message/Delivery-Status
Reporting-MTA: dns; vm1.company.com
Original-Recipient: rfc822; 2145551234@VM1.mycompany.com
Final-Recipient: rfc822; 2145551234@VM1.mycompany.com
Action: failed
Status: 5.1.1 (User does not exist)
Diagnostic-Code: smtp; 550 Mailbox not found
Last-Attempt-Date: Thu, 7 Jul 1994 17:15:49 -0400
--RAA14128.773615765/VM1.COMPANY.COM
content-type: Message/RFC822
[original VPIM message goes here]
--RAA14128.773615765/VM1.COMPANY.COM--
The following example is for an MDN sent to the original sender for a
message that has been played. This delivered VPIM message was
received by a corporate gateway and relayed to a unified mailbox.
Date: Thu, 7 Jul 1994 17:16:05 -0400
From: "Greg Vaudreuil" <22722@vm.company.com>
Message-ID: <199407072116.RAA14128@exchange.company.com>
Subject: Voice message played
To: 2175552345@VM2.mycompany.com
MIME-Version: 1.0
Content-Type: multipart/report;
Report-type=disposition-notification;
Boundary="RAA14128.773615765/EXCHANGE.COMPANY.COM"
--RAA14128.773615765/EXCHANGE.COMPANY.COM
Content-type: Audio/32KADPCM
Content-Description: Spoken Disposition Notification
Content-Disposition: inline; voice= Voice-Message-Notification
Content-Transfer-Encoding: Base64
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadadffsssddasdasd
(Voiced description of the disposition action in base64)
jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gdffkjpokfgW
dlkgpokpeowrit09==
--RAA14128.773615765/EXCHANGE.COMPANY.COM
Content-type: Message/Disposition-Notification
Reporting-UA: gregs-laptop.dallas.company.com (Unified FooMail 3.0)
Original-Recipient: rfc822;22722@vm.company.com
Final-Recipient: rfc822;Greg.Vaudreuil@foomail.company.com
Original-Message-ID: <199509192301.12345@vm2.mycompany.com>
Disposition: manual-action/MDN-sent-automatically; displayed
--RAA14128.773615765/EXCHANGE.COMPANY.COM
Content-type: Message/RFC822
[original VPIM message goes here]
--RAA14128.773615765/EXCHANGE.COMPANY.COM--
14. Appendix C - Example Error Voice Processing Error Codes
The following common voice processing errors and their corresponding status codes are given as examples. The text after the error codes is intended only for reference to describe the error code. Implementations should provide implementation-specific informative comments after the error code rather than the text below. Error condition RFC 1893 Error codes ----------------------------- -------------------------------- Analog delivery failed 4.4.1 Persistent connection error because remote system is busy - busy Analog delivery failed 4.4.1 Persistent protocol error because remote system is - no answer from host ring-no-answer Remote system did not answer 5.5.5 Permanent protocol error AMIS-Analog handshake ("D" in - wrong version response to "C" at connect time) Mailbox does not exist 5.1.1 Permanent mailbox error - does not exist Mailbox full or over quota 4.2.2 Persistent mailbox error - full Disk full 4.3.1 Persistent system error - full Command out of sequence 5.5.1 Permanent protocol error - invalid command Frame Error 5.5.2 Permanent protocol error - syntax error Mailbox does not support FAX 5.6.1 Permanent media error - not supported Mailbox does not support TEXT 5.6.1 Permanent media error - not supported Sender is not authorized 5.7.1 Permanent security error - sender not authorized
Message marked private, but 5.3.3 Permanent system error
system is not private capable - not feature capable
15. Appendix D - Example Voice Processing Disposition Types
The following common voice processing disposition conditions and
their corresponding MDN Disposition (which contains the disposition
mode, type and modifier, if applicable) are given as examples.
Implementers should refer to [MDN] for a full description of the
format of message disposition notifications.
Notification event MDN Disposition mode, type & modifier
------------------------------ ------------------------------------
Message played by recipient, manual-action/MDN-sent-automatically;
receipt automatically returned displayed
Message deleted from mailbox manual-action/MDN-sent-automatically;
by user without listening deleted
Message cleared when mailbox manual-action/MDN-sent-automatically;
deleted by admin deleted/mailbox-terminated
Message automatically deleted automatic-action/
when older than administrator MDN-sent-automatically; deleted/
set threshold expired
Message processed, however manual-action/MDN-sent-automatically;
audio encoding unknown - processed/error
unable to play to user Error: unknown audio encoding
16. Appendix E - IANA Registrations
There are no changes to the registration per [DISP] of the voice
content disposition parameter defined in the earlier VPIM V2
document, RFC 2421. There are no changes to the registration per
[MIME4] of the Multipart/voice-message content type defines in the
earlier VPIM v2 document, RFC 2423.
Both are presented here for information.
16.1. Voice Content-Disposition Parameter Definition
To: IANA@IANA.ORG Subject: Registration of new Content-Disposition parameter Content-Disposition parameter name: voice Allowable values for this parameter: Voice-Message - the primary voice message, Voice-Message-Notification - a spoken delivery notification or spoken disposition notification, Originator-Spoken-Name - the spoken name of the originator, Recipient-Spoken-Name - the spoken name of the recipient if available to the originator and present if there is ONLY one recipient, Spoken-Subject- the spoken subject of the message, typically spoken by the originator Description: In order to distinguish between the various types of audio contents in a VPIM voice message a new disposition parameter "voice" is defined with the preceding values to be used as appropriate. Note that there SHOULD only be one instance of each of these types of audio contents per message level. Additional instances of a given type (i.e., parameter value) may occur within an attached forwarded voice message.16.2. Multipart/Voice-Message MIME Media Type Definition
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 [VPIM2R2]. 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.
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
Applications that use this media type:
Primarily voice messaging
Additional information:
Magic number(s): none
File extension(s): .VPM
Macintosh File Type Code(s): VPIM
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
17. Appendix F - Change History: RFC 2421 (VPIM V2) to this Document
The updated profile in this document is based on the implementation
and operational deployment experience of several vendors. The
changes are categorized as general, content, transport and
conformance. They are summarized below:
1. General
- Various and substantial editorial updates to improve
readability.
- Separated send rules from receive rules to aid clarity.
- Clarified the behavior upon reception of unrecognized content
types expected with the interworking between voice and unified
messaging systems. (E.g., Unsupported non-audio contents should
be discarded to deliver the audio message.)
- Reworked the sensitivity requirements to align them with X.400.
Eliminated dependencies upon the MIXER documents.
- Reorganized the content-type descriptions for clarity
2. Content
- Changed handling of received lines by a gateway to SHOULD NOT
delete in a gateway. In gateways to systems such as AMIS, it is
not possible to preserve this information. It is intended that
such systems be able to claim conformance.
- Eliminated the vCard as a supported VPIM V2 content type.
- Merged in text from RFC 2423 (Multipart/voice-message)
3. Transport
- None
4. Conformance
- Aligned the table of Appendix A to the requirements in the text.
18. 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
19. 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.