level content-type of a DSN is Multipart/Report, which is defined in
[REPORT]. The content-type which distinguishes DSN’s from other
types of notifications is Message/Delivery-Status, which is defined
in [DSN].
SEND RULES
A VPIM-compliant implementation MUST be able to send DSN’s that
conform to [REPORT] and [DSN]. Unless requested otherwise, a non-
delivery DSN MUST be sent when any form of non-delivery of a message
occurs.
A VPIM-compliant implementation SHOULD provide a spoken delivery
status in the "human-readable" body part of the DSN, but MAY provide
a textual status.
RECEIVE RULES
A VPIM-compliant implementation MUST be able to receive DSN’s that
conform to [REPORT] and [DSN].
A VPIM-compliant implementation MUST be able to receive a DSN whose
"human-readable" body part contains a spoken delivery status phrase
or a textual description. Though subsequent use of the phrase or
text is a local implementation issue, the intent of the DSN MUST be
presented to the end user.
4.7. Message Disposition Notification (MDN)
An MDN is a notification indicating what happens to a message after
it is deposited in the recipient’s mailbox. An MDN can be positive
(message was read/played/rendered/etc.) or negative (message was
deleted before recipient could see it, etc.). The top-level
content-type of a MDN is Multipart/Report, which is defined in
[REPORT]. The content-type which distinguishes MDN’s from other
types of notifications is Message/Disposition-Notification, which is
defined in [MDN].
SEND RULES
A VPIM-compliant implementation SHOULD support the ability to request
MDNs. This is done via the use of the "Disposition-Notification-To:"
header field as defined in [MDN].
A VPIM-compliant implementation SHOULD support the ability to send
MDNs, but these MDNs MUST conform to [REPORT] and [MDN].
When sending an MDN, a VPIM-compliant implementation SHOULD provide a
spoken message disposition in the "human-readable" body part of the
MDN, but MAY provide a textual status.
RECEIVE RULES
A VPIM-compliant implementation SHOULD respond to an MDN request with
an MDN response.
A VPIM-compliant implementation MUST be able to receive MDNs that
conform to [REPORT] and [MDN], if it is capable of requesting MDNs.
If a VPIM-compliant implementation is capable of receiving MDNs, it
MUST be able to receive a MDN whose "human-readable" body part
contains a spoken message disposition phrase or a textual disposition
description. Though subsequent use of the phrase or text is a local
implementation issue, the intent of the MDN MUST be presented to the
end user.
4.8. Forwarded Messages
VPIM v2 explicitly supports the forwarding of voice and fax content
with voice or fax annotation. However, only the two constructs
described below are acceptable in a VPIM message. Since only the
first (i.e., Message/RFC822) can be recognized as a forwarded message
(or even multiple forwarded messages), it is RECOMMENDED that this
construct be used whenever possible.
Forwarded VPIM messages SHOULD be sent as a Multipart/Voice-Message
with the entire original message enclosed in a Message/RFC822
content-type and the annotation as a separate Audio/* or Image/* body
part. If the RFC822 header fields are not available for the
forwarded content, simulated header fields with available information
SHOULD be constructed to indicate the original sending timestamp, and
the original sender as indicated in the "From:" field. Note that at
least one of "From:", "Subject:", or "Date:" MUST be present. As
well, the Message/RFC822 content MUST include at least the "MIME-
Version:", and "Content-Type:" header fields. From: [MIME2]
In the event that forwarding information is lost, the entire audio
content MAY be sent as a single Audio/* segment without including any
forwarding semantics. An example of this loss is an AMIS message
being forwarded through an AMIS-to-VPIM gateway.
4.9. Reply Messages
VPIM v2 explicitly supports replying to received messages.
Support of multiple originator header fields in a reply message is
often not possible on voice messaging systems, so it may be necessary
to choose only one when gatewaying a VPIM message to another voice
message system. However, implementers should note that this may make
it impossible to send DSN’s, MDN’s, and replies to their proper
destinations.
In some cases, replying to a message is not possible, such as with a
message created by telephone answering (i.e., classic voice mail).
In this case, the From field SHOULD contain the special address non-
mail-user@domain (see 4.1.2). The recipient’s VPIM system SHOULD NOT
offer the option to reply to this kind of message (unless an
outcalling feature is offered - which is out of scope for VPIM).
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.