Request for Comments: 3801 Lucent Technologies
Obsoletes: 2421 G. Parsons
Category: Standards Track Nortel Networks
June 2004
Voice Profile for Internet Mail - version 2 (VPIMv2)
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 (2004).
Abstract
This document specifies a restricted profile of the Internet
multimedia messaging protocols for use between voice processing
server platforms. The profile is referred to as the Voice Profile
for Internet Mail (VPIM) in this document. 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. This profile is intended to specify
the minimum common set of features to allow interworking between
conforming systems.
This document obsoletes RFC 2421 and describes version 2 of the
profile with greater precision. No protocol changes were made in
this revision. A list of changes from RFC 2421 are noted in Appendix
F. Appendix A summarizes the protocol profiles of this version of
VPIM.
Table of Contents
1. Introduction...................................................3
1.1. Voice Messaging System Limitations.......................3
1.2. Design Goals.............................................4
1.3. Applicability for VPIM...................................5
2. Requirements Language..........................................5
3. Protocol Restrictions..........................................6
4. Voice Message Interchange Format...............................6
4.1. VPIM Message Addressing Formats..........................7
4.2. Message Header Fields....................................9
4.3. MIME Audio Content Descriptions.........................17
4.4. Voice Message Content Types.............................19
4.5. Other MIME Contents.....................................23
4.6. Delivery Status Notification (DSN)......................25
4.7. Message Disposition Notification (MDN)..................26
4.8. Forwarded Messages......................................26
4.9. Reply Messages..........................................27
5. Message Transport Protocol....................................27
5.1. Base SMTP Protocol......................................28
5.2. SMTP Service Extensions.................................28
5.3. ESMTP - SMTP Downgrading................................30
6. Directory Address Resolution..................................30
7. Management Protocols..........................................30
7.1. Network Management......................................31
8. Conformance Requirements......................................31
9. Security Considerations.......................................32
9.1. General Directive.......................................32
9.2. Threats and Problems....................................32
9.3. Security Techniques.....................................33
10. Normative References..........................................33
11. Acknowledgments...............................................36
12. Appendix A - VPIM Requirements Summary........................37
13. Appendix B - Example Voice Messages...........................43
14. Appendix C - Example Error Voice Processing Error Codes.......49
15. Appendix D - Example Voice Processing Disposition Types.......50
16. Appendix E - IANA Registrations...............................50
16.1. Voice Content-Disposition Parameter Definition.........51
16.2. Multipart/Voice-Message MIME Media Type Definition.....51
17. Appendix F - Change History: RFC 2421 (VPIM V2) To This Doc...53
18. Authors’ Addresses............................................54
19. Full Copyright Statement......................................55
1. Introduction
MIME is the Internet multipurpose, multimedia-messaging standard.
This document explicitly recognizes its capabilities and provides a
mechanism for the exchange of various messaging technologies,
primarily voice and facsimile.
Voice messaging evolved as telephone answering service into a full
send, receive, and forward messaging paradigm with unique message
features, semantics and usage patterns. Voice messaging was
introduced on special purpose computers that interface to a telephone
switch and provide call answering and voice messaging services.
Traditionally, messages sent from one voice messaging system to
another were transported using analog networking protocols based on
DTMF signaling and analog voice playback. As the demand for
networking increases, there was a need for a standard high-quality
digital protocol to connect these machines. VPIM has successfully
demonstrated its usefulness as this new standard. VPIM is widely
implemented and is seeing deployment in customer networks. This
document clarifies ambiguities found in the earlier specification and
is consistent with implementation practice. The profile is referred
to as Voice Profile for Internet Mail (VPIM) in this document.
This document specifies a restricted profile of the Internet
multimedia messaging protocols for use between voice processing
server 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. This profile is intended to specify the minimum common set
of features to allow interworking between conforming systems.
This document obsoletes RFC 2421 and describes VPIM version 2 of with
greater precision. No protocol changes were made in this revision.
A list of changes from RFC 2421 are noted in Appendix F. Appendix A
summarizes the protocol profiles of this version of VPIM.
1.1. Voice Messaging System Limitations
The following are typical limitations of voice messaging platforms
that were considered in creating this baseline profile.
1) Text messages are not normally received and often cannot be
easily displayed or viewed. They can often be processed only via
text-to-speech or text-to-fax features not currently present in
many of these machines.
2) Voice mail machines usually act as an integrated Message
Transfer Agent, Message Store and User Agent. There is typically
no relaying of messages. RFC822 header fields may have limited
use in the context of the limited messaging features currently
deployed.
3) Voice mail message stores are generally not capable of
preserving the full semantics of an Internet message. As such,
use of a voice mail machine for gatewaying is not supported. In
particular, storage of recipient lists, "Received:" lines, and
"Message-ID:" may be limited.
4) Internet-style distribution/exploder mailing lists are not
typically supported. Voice mail machines often implement only
local alias lists, with error-to-sender and reply-to-sender
behavior. Reply-all capabilities using a Cc list are not generally
available.
5) Error reports must be machine-parsable so that helpful
responses can be voiced to users whose only access mechanism is a
telephone.
6) The voice mail systems generally limit address entry to 16 or
fewer numeric characters, and normally do not support alphanumeric
mailbox names. Alpha characters are not generally used for
mailbox identification, as they cannot be easily entered from a
telephone terminal.
It should be noted that newer systems are based natively on SMTP/MIME
and do not suffer these limitations. In particular, some systems may
support media other than voice and fax.
1.2. Design Goals
It is a goal of this profile to make as few restrictions and
additions to the existing Internet mail protocols as possible while
satisfying the requirements for interoperability with current
generation voice messaging systems. This goal is motivated by the
desire to increase the accessibility to digital messaging by enabling
the use of proven existing networking software for rapid development.
This specification is intended for use on a TCP/IP network; however,
it is possible to use the SMTP protocol suite over other transport
protocols. The necessary protocol parameters for such use are
outside the scope of this document.
This profile is intended to be robust enough to be used in an
environment, such as the global Internet, with installed-base
gateways that do not understand MIME. Full functionality, such as
reliable error messages and binary transport, will require careful
selection of gateways (e.g., via MX records) to be used as VPIM
forwarding agents. Nothing in this document precludes use of
general-purpose MIME email packages to read and compose VPIM
messages. While no special configuration is required to receive VPIM
conforming messages, some may be required to originate conforming
structures.
It is expected that a system administrator who can perform TCP/IP
network configuration will manage a VPIM messaging system. When
using facsimile or multiple voice encodings, it is suggested that the
system administrator maintain a list of the capabilities of the
networked mail machines to reduce the sending of undeliverable
messages due to lack of feature support. Configuration,
implementation and management of these directory-listing capabilities
are local matters.
1.3. Applicability for VPIM
VPIM is intended for the exchange of voice messages between
traditional voice messaging systems and for systems that need to
interoperate with such systems. VPIM is intended connect voice-
messaging systems into special-purpose voice messaging networks.
VPIM may also be used between message store servers and VPIM-aware
clients such as web servers, TUI, and GUI clients. VPIM is not
intended or optimized for downloading to, or sending from commercial
email clients.
Internet Voice Messaging, the subject of a separate standards
initiative, is intended to enable general-purpose email clients to
send and receive voice content through general-purpose message stores
in an interoperable way. IVM may also be a suitable format for
downloading voice messages from a VPIM server to a commercial email
client. It may also be a suitable format for submission of a voice
message from a general-purpose client into a VPIM system.
2. Requirements Language
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. Protocol Restrictions
This protocol does not limit the number of recipients per message.
Where possible, server implementations should not restrict the number
of recipients in a single message. It is recognized that no
implementation supports unlimited recipients, and that the number of
supported recipients may be quite low.
This protocol does not limit the maximum message length.
Implementers should understand that some machines will be unable to
accept excessively long messages. A mechanism is defined in [SIZE]
to declare the maximum message size supported.
The following sections describe the restrictions and additions to
Internet mail protocols that are required to be conforming with this
VPIM v2 profile. Though various SMTP, ESMTP and MIME features are
described here, the implementer is referred to the relevant RFCs for
complete details. The table in Appendix A summarizes the protocol
details of this profile.
4. Voice Message Interchange Format
The voice message interchange format is a profile of the Internet
Mail Protocol Suite. Any Internet Mail message containing the format
defined in this section is referred to as a VPIM Message in this
document. As a result, this document assumes an understanding of the
Internet Mail specifications. Specifically, VPIM references
components from the message format standard for Internet messages
[RFC822], the Multipurpose Internet Message Extensions [MIME1-5], the
X.400 gateway specification [X.400], and the delivery status and
message disposition notifications [REPORT][DSN][DRPT][STATUS][MDN].
MIME, introduced in [MIME1], is a general-purpose message body format
that is extensible to carry a wide range of body parts. It provides
for encoding binary data so that it can be transported over the 7-bit
text-oriented SMTP protocol. This transport encoding (denoted by the
"Content-Transfer-Encoding:" MIME field) is in addition to the audio
encoding required to generate a binary object.
MIME defines two transport-encoding mechanisms to transform binary
data into a 7-bit representation, one designed for text-like data
("Quoted-Printable"), and one for arbitrary binary data ("Base64").
While Base64 is dramatically more efficient for audio data, either
will work. Where binary transport is available, no transport
encoding is needed, and the data can be labeled as "Binary".
4.1. VPIM Message Addressing Formats
VPIM addresses SHALL use the RFC 822 format based on the Domain Name
System. This naming system has two components: the local part, used
for username or mailbox identification; and the host part, used for
global machine identification.
4.1.1. VPIM Addresses
The local part of the address shall be a US-ASCII string uniquely
identifying a mailbox on a destination system. For voice messaging,
the local part SHALL be a printable string containing the mailbox ID
of the originator or recipient. While alpha characters and long
mailbox identifiers MAY be permitted, short numeric local parts
SHOULD be used as most voice mail networks rely on numeric mailbox
identifiers to retain compatibility with the limited 10-digit
telephone keypad. As a result, some voice messaging systems may only
be able to handle a numeric local part. The reception of
alphanumeric local parts on these systems may result in the address
being mapped to some locally unique (but confusing to the recipient)
number or, in the worst case the address could be deleted making the
message unreplyable. Additionally, it may be difficult to create
messages on these systems with an alphanumeric local part without
complex key sequences or some form of directory lookup (see 6). The
use of the Domain Name System should be transparent to the user. It
is the responsibility of the voice mail machine to lookup the fully-
qualified domain name (FQDN) based on the address entered by the user
(see 6).
In the absence of a global directory, specification of the local part
is expected to conform to international or private telephone
numbering plans. It is likely that private numbering plans will
prevail and these are left for local definition. However, it is
RECOMMENDED that public telephone numbers be noted according to the
international numbering plan described in [E.164]. The indication
that the local part is a public telephone number is given by a
preceding "+" (the "+" would not be entered from a telephone keypad,
it is added by the system as a flag). Since the primary information
in the numeric scheme is contained by the digits, other character
separators (e.g., "-") may be ignored (i.e., to allow parsing of the
numeric local mailbox) or may be used to recognize distinct portions
of the telephone number (e.g., country code). The specification of
the local part of a VPIM address can be split into the four groups
described below:
1) mailbox number
- for use as a private numbering plan (any number of digits)
- e.g., 2722@lucent.com
2) mailbox number+extension
- for use as a private numbering plan with extensions
any number of digits, use of "+" as separator
- e.g., 2722+111@Lucent.com
3) +international number
- for international telephone numbers conforming to E.164
maximum of 15 digits
- e.g., +16137637582@vm.nortel.ca
4) +international number+extension
- for international telephone numbers conforming to E.164
maximum of 15 digits, with an extension (e.g., behind a
PBX) that has a maximum of 15 digits.
- e.g., +17035245550+230@ema.org
Note that this address format is designed to be compatible with
current usage within the voice messaging industry. It is not
compatible with the addressing formats of RFCs 2303-2304. It is
expected that as telephony services become more widespread on the
Internet, these addressing formats will converge.
4.1.2. Special Addresses
Special addresses to represent the sender are provided for
compatibility with the conventions of Internet mail. These addresses
do not use numeric local addresses, both to conform to current
Internet practice and to avoid conflict with existing numeric
addressing plans. Two special addresses are RESERVED for use as
follows:
postmaster@domain
By convention, a special mailbox named "postmaster" MUST exist on all
systems. This address is used for diagnostics and should be checked
regularly by the system manager. This mailbox is particularly likely
to receive text messages, which is not normal on a voice-processing
platform. The specific handling of these messages is an individual
implementation choice.
non-mail-user@domain
If a reply to a message is not possible, such as a telephone-
answering message, then the special address "non-mail-user" SHOULD be
used as the originator’s address. Any text name such as "Telephone
Answering", or the telephone number if it is available, is permitted.
This special address is used as a token to indicate an unreachable
originator. A conforming implementation MUST NOT permit a reply to an
address from "non-mail-user". For compatibility with the installed
base of mail user agents, implementations MUST reject the message
when a message addressed to "non-mail-user" is received. The status
code for such NDN’s is 5.1.1 "Mailbox does not exist".
Example:
From: Telephone Answering <non-mail-user@mycompany.com>
4.1.3. Distribution Lists
There are many ways to handle distribution list (DL) expansions and
none are ’standard’. A VPIM implementation MAY support DLs. Using a
simple alias is a behavior closest to what many voice mail systems do
today and what is to be used with VPIM messages. A couple of
important features that need special care when DLs are used are:
Reply to the originator - (Address in the RFC822 "Reply-To:" or
"From" field)
Errors to the submitter - (Address in the MAIL FROM field of the
ESMTP exchange or the "Return-Path:"
RFC822 field)
Some proprietary voice messaging protocols include only the recipient
of the particular copy in the envelope and include no "header fields"
except date and per-message features. Most voice messaging systems
do not provide for "Header Information" in their messaging queues and
only include delivery information. As a result, recipient
information MAY be in either the "To:" or "Cc:" header fields. If all
recipients cannot be presented then the recipient header fields
SHOULD be omitted to indicate that an accurate list of recipients
(e.g., for use with a reply-all capability) is not known.
4.2. Message Header Fields
Internet messages contain a header information block. This header
block contains information required to identify the sender, the list
of recipients, the message send time, and other information intended
for user presentation. Except for specialized gateway and mailing
list cases, header fields do not indicate delivery options for the
transport of messages.
Distribution list processors are noted for modifying or adding to the
header fields of messages that pass through them. VPIM systems MUST
be able to accept and ignore header fields that are not defined here.
The following header lines are permitted for use with VPIM messages:
4.2.1. From
SEND RULES
The originator’s fully qualified domain address (a mailbox address
followed by the fully qualified domain name) MUST be present.
Systems conforming with this profile SHOULD provide the text personal
name of the voice message originator in a quoted phrase, if the name
is available. Text names of corporate or positional mailboxes MAY be
provided as a simple string. From: [RFC822]
Example:
From: "Joe S. User" <12145551212@mycompany.com>
From: Technical Support <611@serviceprovider.com>
From: Non-mail-user@myserver.mycompany.com
Voice mail machines may not be able to support separate attributes
for the "From:" header fields and the SMTP MAIL FROM, VPIM-conforming
systems SHOULD set these values to the same address. Use of
addresses different than those present in the "From:" header field
address may result in unanticipated behavior.
RECEIVE RULES
The user listed in the "From:" field MUST be presented in the voice
message envelope of the voice messaging system as the originator of
the message, though the exact presentation is an implementation
decision (e.g., the mailbox ID or the text name MAY be presented).
The "From:" address SHOULD be used for replies (see 4.9).
4.2.2. To
The "To:" field contains the recipient’s fully-qualified domain
address.
Example:
To: +12145551213@mycompany.com
SEND RULES
There MAY be one or more "To:" fields in any message. Systems SHOULD
provide a list of recipients only if all recipients are available.
Systems, such as gateways from protocols or legacy platforms that do
not indicate the complete list of recipients, MAY provide a "To:"
line. Because these systems cannot accurately enumerate all
recipients in the "To:" headers, recipients SHOULD NOT be enumerated.
RECEIVE RULES
Systems conforming to this profile MAY discard the addresses in the
"To:" fields if they are unable to store the information. This
would, of course, make a reply-to-all capability impossible. If
present, the addresses in the "To:" field MAY be used for a reply
message to all recipients.
4.2.3. Cc
The "Cc:" field contains additional recipients’ fully qualified
domain addresses. Many voice mail systems maintain only sufficient
envelope information for message delivery and are not capable of
storing or providing a complete list of additional recipients.
SEND RULES
Conforming implementations MAY send "Cc:" lists if all recipients are
known at the time of origination. If not, systems SHOULD omit the
"Cc:" fields to indicate that the full list of recipients is unknown
or otherwise unavailable. The list of disclosed recipients MUST NOT
include undisclosed recipients (i.e., those sent via a blind copy).
Example:
Cc: +12145551213@mycompany.com
RECEIVE RULES
Systems conforming to this profile MAY add all the addresses in the
"Cc:" field to the "To:" field, others MAY discard the addresses in
the "Cc:" fields. If a list of "Cc:" addresses is present, these
addresses MAY be used for a reply message to all recipients.
4.2.4. Date
The "Date:" field contains the date and time the message was sent by
the originator.
SEND RULES
The sending system MUST report the time the message was sent. The