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 offered only a
telephone user interface. The mapping of the dialed target number to
a routeable FQDN address allowing delivery to the destination system
can be accomplished through implementation-specific means.
To facilitate a local dial-by-name cache, an implementation may wish
to populate local directories with the first and last names, as well
as the address information extracted from received messages. It is
mandated that only address information from vCard attachments to VPIM
messages be used to populate such a directory when the vCard is
available. Addresses or names parsed from the header fields of VPIM
messages SHOULD NOT be used to populate directories as it only
provides partial data. Alternatively, bilateral agreements could be
made to allow the bulk transfer of vCards between systems.
The use of client/server desktop mailbox protocols like IMAP or POP
to retrieve VPIM messages from a IMAP or POP message store is
possible without any special modifications to this VPIM
specification. Email clients (and web browsers) typically have a
table for mapping from MIME type to displaying application. The
audio/*, image/tiff and text/directory contents can be configured so
that they invoke the correct player/recorder for rendering. In
addition with IMAP clients, the first multipart/mixed content (if
present) will not appear since it is a generic part. The user
instead will be presented with a message that has (for example) audio
and image contents.
8. 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 compliant message machine.
8.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].
9. Conformance Requirements
VPIM is a messaging application which must 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
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
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 compliance requirements is contained in Appendix A.
VPIM end systems are expected to be both transport and content
conformant. They should generate conforming content, reliably send
it to the next hop system, receive a message, decode the message and
present it to the user. Voice messaging systems and protocol
conversion gateways are considered end systems.
Relay systems are expected to be transport compliant in order to
receive and send conforming messages. However, they must also create
VPIM conforming delivery status notifications in the event of
Desktop Email clients that support VPIM and 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.
10. Security Considerations
10.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 of the Internet security
infrastructure, rather than a new mechanism or some other mechanism
outside of the Internet infrastructure.
10.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 which ensue from integrating the two
10.2.1 Spoofed sender
The actual sender of the voice message might not be the same as that
specified in the Sender or From header fields of the message content
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 senders 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.
10.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.
10.2.3 Message disclosure
Users of voice messaging systems have an expectation of a level of
message privacy which 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.
10.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.
[8BIT] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC
1426, February 1993.
[ADPCM] Vaudreuil, G., and G. Parsons, "Toll Quality Voice - 32
kbit/s ADPCM: MIME Sub-type Registration", RFC 2422,
[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 1830, October 1995.
[CODES] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893,
[MIMEDIR] Howes, T., Smith, M., and F. Dawson, "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", STD 13, RFC 1035, November 1987.
[DNS2] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[DRPT] Moore, K., "SMTP Service Extensions for Delivery Status
Notifications", RFC 1891, January 1996.
[DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for
Delivery Status Notifications", RFC 1894, January 1996.
[DUR] Vaudreuil, G., and G. Parsons, "Content Duration MIME Header
Definition", RFC 2424, September 1998.
[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., Freed, N., Rose, M., Stefferud, E., and D.
Crocker, "SMTP Service Extensions", RFC 1869, November 1995.
[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",
RFC 1766, March 1995.
[MDN] Fajman, R., "An Extensible Message Format for Message
Disposition Notifications", RFC 2298, March 1998.
[MIB II] Rose, M., "Management Information Base for Network
Management of TCP/IP-based internets: MIB-II", RFC 1158, May
[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
[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", RFC 1854, October 1995.
[REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the
Reporting of Mail System Administrative Messages", RFC 1892,
[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", RFC 1870, November 1995.
[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
[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 registraion", RFC 2302,
[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,
[X.400] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO
10021 and RFC 822", RFC 1327, May 1992.
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 VPIM Work Group, for their support of the
VPIM specification and the efforts they have made to ensure its
The EMA hosts the VPIM web page at http://www.ema.org/vpim.
13. Authors' Addresses
Glenn W. Parsons
P.O. Box 3511, Station C
Ottawa, ON K1Y 4H7
Gregory M. Vaudreuil
Octel Messaging Division
17080 Dallas Parkway
Dallas, TX 75248-1905
14. 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
Must not - prohibited
Footnote - special comment about conformance for a particular
6. Other un-profiled contents must only be sent by bilateral
7. If the content cannot be presented in some form, the entire
message MUST be returned with a negative delivery status
8. When the vCard is present in a message
15. 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 and a short
speech segment. The message is marked as important and private.
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;
Content-Disposition: inline; voice=Originator-Spoken-Name
(This is a sample of the base-64 Spoken Name data)
Content-Description: Brand X Voice Message
Content-Disposition: inline; voice=Voice-Message; filename=msg1.726
(This is a sample of the base64 message data) zb8tFdLTQt1PXj
Content-type: text/directory; charset=us-ascii; profile=vCard
The following example is for a message returned to the sender 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>
Subject: Returned voice message
MIME-Version: 1.0 (Voice 2.0)
Content-Type: multipart/report; report-type=delivery-status;
Content-Description: Spoken Delivery Status Notification
Content-Disposition: inline; voice= Voice-Message-Notification
(This is a voiced description of the error in base64)
Reporting-MTA: dns; vm1.company.com
Original-Recipient: rfc822; 2145551234@VM1.mycompany.com
Final-Recipient: rfc822; 2145551234@VM1.mycompany.com
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
[original VPIM message goes here]
The following example is for a receipt notification sent to the
original sender for a message which 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" <email@example.com>
Subject: Voice message played
MIME-Version: 1.0 (Voice 2.0)
Content-Description: Spoken Disposition Notification
Content-Disposition: inline; voice= Voice-Message-Notification
(Voiced description of the disposition action in base64)
Reporting-UA: gregs-laptop.dallas.company.com (Unified FooMail 3.0)
Original-Message-ID: <firstname.lastname@example.org >
Disposition: manual-action/MDN-sent-automatically; displayed
[original VPIM message goes here]
16. Appendix C - Example Error Voice Processing Error Codes
The following common voice processing errors and their corresponding
status codes are given as examples. Text after the error codes are
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.0 Persistent connection error
because remote system is busy - other
Analog delivery failed 4.4.1 Persistent protocol error
because remote system is - no answer from host
Remote system did not answer 5.5.5 Permanent protocol error
AMIS-Analog handshake ("D" in - wrong version
response to "C" at connect
Mailbox does not exist 5.1.1 Permanent mailbox error
- does not exist
Mailbox full or over quota 4.2.2 Persistent mailbox error
Disk full 4.3.1 Persistent system error
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
17. 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
18. Appendix E - IANA Registrations
18.1 vCard EMAIL Type Definition for VPIM
Subject: Registration of new parameter for text/directory MIME type
Type name: EMAIL
Type purpose: To specify the electronic mail address for
communication with the object the vCard represents (defined in
Type encoding: 8bit
Type value: A single text value.
Type special notes: The type may include the type parameter "TYPE" to
specify the format or preference of the electronic mail address. The
TYPE parameter values previously defined include: "internet" to
indicate an Internet addressing type, "x400" to indicate a X.400
addressing type and "pref" to indicate a preferred-use email address
when more than one is specified. The value of "vpim" is defined to
indicate that the address specified supports VPIM messages. Other
IANA registered address type may also be specified. The default email
type is "internet". A non-standard value may also be specified.
18.2 Voice Content-Disposition Parameter Definition
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
Spoken-Subject- the spoken subject of the message, typically
spoken by the originator
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
19. Appendix F - Change History: RFC 1911 to this Document
The updated profile in this document is based on the experience of a
proof of concept demonstration of VPIM at EMA'96 in April 1996 and a
subsequent demonstration of products at EMA'97 in April 1997. This
version of the profile is significantly different from the previous
described in [VPIM1]. The changes are categorized as general,
content, transport and compliance. They are detailed below:
- All definitions are now contained in separate documents that are
referenced by this profile. The new documents include:
- a refined multipart/voice-message definition
- a refined (i.e., added nibble order) audio/32KADPCM definition
- the definitions of TIFF-F and image/tiff for fax images
- the Content-Duration definition
- Changed the Voice version to 2.0
- Added Table of Contents and more examples
- Various editorial updates to improve readability
- Added more security considerations
- Modified multipart/voice-message content type by dropping the
positional dependence of contents while restricting its contents to
voice message specific content types
- Explicitly indicated other contents that may be present ina
multipart/mixed content type
- Explicitly defined the forwarding model using message/RFC822
- Explained the use of reply-to and from header fields for
addressing message replies
- Deprecated the special "loopback" address because of security
concerns and its use only for testing
- Defined the non-mail-user reserved address to support the case in
which replies to the originator are not possible
- Eliminated the text name in the "To" and "CC" header fields.
Deprecated ordering of text names in the "From" header.
- Added support for facsimile using TIFF-F in an image/tiff;
application=faxbw content type
- Profiled vCard in the text/directory body part for transport of
directory information about the originator
- Loosened text restriction
- Added additional details on delivery and receipt notifications
- Added support for message disposition notifications, also known
as receipt notifications.
- Added suggested addressing formats
- Described handling of private messages
- Described the handling of non-profiled contents in VPIM messages
- Described the use of Content-Disposition to semantically identify
- Moved binary support to optional
- Added optional ESMTP keywords for return of content, enhanced
status codes, original recipient, and envelope ID
- Described use of null MAIL FROM address
- Added an explicit section on conformance specifying conformance
to content or transport
- Improved conformance table in Appendix A
20. 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 implementation 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
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.