As per Relevance of the word september, we have this rfc below:
Network Working Group G.
Request for Comments: 2421 Lucent
Obsoletes: 1911 G.
Category: Standards Track Northern
September 1998
Voice Profile for Internet Mail - version 2
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document profiles Internet mail for voice messaging.
obsoletes RFC 1911 which describes version 1 of the profile. A
of changes from that document are noted in Appendix F. As well
Appendix A summarizes the protocol profiles of this version of VPIM
Please send comments on this document to the EMA VPIM Work
mailing list:
Working Group
This profile is not the product of an IETF working group,
several have reviewed the document. It is instead the product of
VPIM Work Group of the Electronic Messaging Association (EMA).
work group, which has representatives from most major voice
vendors and several email vendors, has held several
demonstrations between voice messaging vendors and is
promoting VPIM trials and deployment
Vaudreuil & Parsons Standards Track [Page 1]
RFC 2421 VPIM v2 September 1998
Table of
1. ABSTRACT .........................................................3
2. SCOPE ............................................................3
2.1 Voice Messaging System Limitations ............................3
2.2 Design Goals ..................................................4
3. PROTOCOL RESTRICTIONS ............................................5
4. VOICE MESSAGE INTERCHANGE FORMAT .................................6
4.1 Message Addressing Formats ....................................6
4.2 Message Header Fields .........................................9
4.3 Voice Message Content Types ..................................15
4.4 Other Message Content Types ..................................21
4.5 Forwarded Messages ...........................................23
4.6 Reply Messages ...............................................23
4.7 Notification Messages ........................................24
5. MESSAGE TRANSPORT PROTOCOL ......................................24
5.1 ESMTP Commands ...............................................25
5.2 ESMTP Keywords ...............................................27
5.3 ESMTP Parameters - MAIL FROM .................................28
5.4 ESMTP Parameters - RCPT TO ...................................29
5.5 ESMTP - SMTP Downgrading .....................................29
6. DIRECTORY ADDRESS RESOLUTION ....................................30
7. IMAP ............................................................30
8. MANAGEMENT PROTOCOLS ............................................30
8.1 Network Management ...........................................31
9. CONFORMANCE REQUIREMENTS ........................................31
10. SECURITY CONSIDERATIONS ........................................32
10.1 General Directive ...........................................32
10.2 Threats and Problems ........................................32
10.3 Security Techniques .........................................33
11. REFERENCES .....................................................33
12. ACKNOWLEDGMENTS ................................................36
13. AUTHORS' ADDRESSES .............................................36
14. APPENDIX A - VPIM REQUIREMENTS SUMMARY .........................37
15. APPENDIX B - EXAMPLE VOICE MESSAGES ............................45
16. APPENDIX C - EXAMPLE ERROR VOICE PROCESSING ERROR CODES ........50
17. APPENDIX D - EXAMPLE VOICE PROCESSING DISPOSITION TYPES ........51
18. APPENDIX E - IANA REGISTRATIONS ................................52
18.1 vCard EMAIL Type Definition for VPIM ........................52
18.2 Voice Content-Disposition Parameter Definition ..............52
19. APPENDIX F - CHANGE HISTORY: RFC 1911 TO THIS DOCUMENT .........54
20. FULL COPYRIGHT NOTICE ..........................................56
Vaudreuil & Parsons Standards Track [Page 2]
RFC 2421 VPIM v2 September 1998
1.
A class of special-purpose computers has evolved to provide
messaging services. These machines generally interface to
telephone switch and provide call answering and voice
services. Traditionally, messages sent to a non-local machine
transported using analog networking protocols based on DTMF
and analog voice playback. As the demand for networking increases
there is a need for a standard high-quality digital protocol
connect these machines. The following document is a profile of
Internet standard MIME and ESMTP protocols for use as a digital
messaging networking protocol. The profile is referred to as
(Voice Profile for Internet Mail) in this document
This profile is based on earlier work in the Audio
Interchange Specification (AMIS) group that defined a voice
protocol based on X.400 technology. This profile is intended
satisfy the user requirements statement from that earlier work
the industry standard ESMTP/MIME mail protocol
already used within corporate intranets. This second version of
is based on implementation experience and obsoletes RFC 1911
describes version 1 of the profile
2.
MIME is the Internet multipurpose, multimedia messaging standard
This document explicitly recognizes its capabilities and provides
mechanism for the exchange of various messaging technologies
primarily voice and facsimile
This document specifies a restricted profile of the
multimedia messaging protocols for use between voice
server platforms. These platforms have historically been special
purpose computers and often do not have the same facilities
associated with a traditional Internet Email-capable computer. As
result, VPIM also specifies additional functionality as it is needed
This profile is intended to specify the minimum common set
features to allow interworking between compliant systems
2.1 Voice Messaging System
The following are typical limitations of voice messaging
which were considered in creating this baseline profile
1) Text messages are not normally received and often cannot
easily displayed or viewed. They can often be processed only
text-to-speech or text-to-fax features not currently present
many of these machines
Vaudreuil & Parsons Standards Track [Page 3]
RFC 2421 VPIM v2 September 1998
2) Voice mail machines usually act as an integrated
Transfer Agent, Message Store and User Agent. There is no
of messages, and RFC 822 header fields may have limited use in
context of the limited messaging features currently deployed
3) Voice mail message stores are generally not capable
preserving the full semantics of an Internet message. As such,
of a voice mail machine for gatewaying is not supported.
particular, storage of recipient lists, "Received" lines,
"Message-ID" may be limited
4) Internet-style distribution/exploder mailing lists are
typically supported. Voice mail machines often implement
local alias lists, with error-to-sender and reply-to-
behavior. Reply-all capabilities using a CC list are not
available
5) Error reports must be machine-parsable so that helpful
can be voiced to users whose only access mechanism is a telephone
6) The voice mail systems generally limit address entry to 16
fewer numeric characters, and normally do not support
mailbox names. Alpha characters are not generally used for
identification as they cannot be easily entered from a
terminal
2.2 Design
It is a goal of this profile to make as few restrictions
additions to the existing Internet mail protocols as possible
satisfying the requirements for interoperability with
generation voice messaging systems. This goal is motivated by
desire to increase the accessibility to digital messaging by
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
protocols. The necessary protocol parameters for such use is
the scope of this document
This profile is intended to be robust enough to be used in
environment, such as the global Internet with installed-base
which do not understand MIME, though typical use is expected to
within corporate intranets. Full functionality, such as
error messages and binary transport, will require careful
of gateways (e.g., via MX records) to be used as VPIM
agents. Nothing in this document precludes use of general
MIME email packages to read and compose VPIM messages. While
Vaudreuil & Parsons Standards Track [Page 4]
RFC 2421 VPIM v2 September 1998
special configuration is required to receive VPIM compliant messages
some may be required to originate compliant structures
It is expected that a VPIM messaging system will be managed by
system administrator who can perform TCP/IP network configuration
When using facsimile or multiple voice encodings, it is
that the system administrator maintain a list of the capabilities
the networked mail machines to reduce the sending of
messages due to lack of feature support. Configuration
implementation and management of these directory listing
are local matters
3. Protocol
This protocol does not limit the number of recipients per message
Where possible, server implementations should not restrict the
of recipients in a single message. It is recognized that
implementation supports unlimited recipients, and that the number
supported recipients may be quite low
This protocol does not limit the maximum message length
Implementers should understand that some machines will be unable
accept excessively long messages. A mechanism is defined in the
1425 SMTP service extensions to declare the maximum message
supported
The message size indicated in the ESMTP SIZE parameter is in bytes
not minutes or seconds. The number of bytes varies by voice
format and includes the MIME wrapper overhead. If the length must
known before sending, an approximate translation into minutes
seconds can be performed if the voice encoding is known
The following sections describe the restrictions and additions
Internet mail protocols that are required to be compliant with
VPIM v2 profile. Though various SMTP, ESMTP and MIME features
described here, the implementer is referred to the relevant RFCs
complete details. It is also advisable to check for IETF drafts
various Internet Mail specifications that are later than the
recent RFCs since, for example, MIME has yet to be published as
full IETF Standard. The table in Appendix A summarizes the
details of this profile
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in [REQ].
Vaudreuil & Parsons Standards Track [Page 5]
RFC 2421 VPIM v2 September 1998
4. Voice Message Interchange
The voice message interchange format is a profile of the
Mail Protocol Suite. Any Internet Mail message containing the
defined in this section is referred to as a VPIM Message in
document. As a result, this document assumes an understanding of
Internet Mail specifications. Specifically, VPIM
components from the message format standard for Internet
[RFC822], the Multipurpose Internet Message Extensions [MIME],
X.400 gateway specification [X.400], delivery status and
disposition notifications [REPORT][DSN][DRPT][STATUS][MDN], and
electronic business card [MIMEDIR][VCARD].
4.1 Message Addressing
RFC 822 addresses are based on the domain name system. This
system has two components: the local part, used for username
mailbox identification; and the host part, used for global
identification
4.1.1 VPIM
The local part of the address shall be a US-ASCII string
identifying a mailbox on a destination system. For voice messaging
the local part is a printable string containing the mailbox ID of
originator or recipient. While alpha characters and long
identifiers are permitted, most voice mail networks rely on
mailbox identifiers to retain compatibility with the limited 10
telephone keypad. As a result, some voice messaging systems may
be able to handle a numeric local part. The reception
alphanumeric local parts on these systems may result in the
being mapped to some locally unique (but confusing to the recipient
number or, in the worst case the address could be deleted making
message un-replyable. Additionally, it may be difficult to
messages on these systems with an alphanumeric local part
complex key sequences or some form of directory lookup (see 6).
The use of the domain naming system should be transparent to
user. It is the responsibility of the voice mail machine to
the fully-qualified domain name (FQDN) based on the address
by the user (see 6).
In the absence of a global directory, specification of the local
is expected to conform to international or private
numbering plans. It is likely that private numbering plans
prevail and these are left for local definition. However, it
RECOMMENDED that public telephone numbers be noted according to
international numbering plan described in [E.164]. The
Vaudreuil & Parsons Standards Track [Page 6]
RFC 2421 VPIM v2 September 1998
that the local part is a public telephone number is given by
preceding `+' (the `+' would not be entered from a telephone keypad
it is added by the system as a flag). Since the primary
in the numeric scheme is contained by the digits, other
separators (e.g. `-') may be ignored (i.e. to allow parsing of
numeric local mailbox) or may be used to recognize distinct
of the telephone number (e.g. country code). The specification
the local part of a VPIM address can be split into the four
described below
1) mailbox
- for use as a private numbering plan (any number of digits
- e.g. 2722@lucent.
2) mailbox number+
- for use as a private numbering plan with
any number of digits, use of `+' as
- e.g. 2722+111@Lucent.
3) +international
- for international telephone numbers conforming to E.164
maximum of 15
- e.g. +16137637582@vm.nortel.
4) - for international telephone numbers conforming to E.164
maximum of 15 digits, with an extension (e.g. behind
PBX) that has a maximum of 15 digits
- e.g. +17035245550+230@ema.
Note that this address format is designed to be compatible
current usage within the voice messaging industry. It is
compatible with the addressing formats of RFCs 2303-2304. It
expected that as telephony services become more widespread on
Internet, these addressing formats will converge
4.1.2 Special
Special addresses are provided for compatibility with the
of Internet mail. These addresses do not use numeric
addresses, both to conform to current Internet practice and to
conflict with existing numeric addressing plans. Two
addresses are RESERVED for use as follows
postmaster@
By convention, a special mailbox named "postmaster" MUST exist on
systems. This address is used for diagnostics and should be
regularly by the system manager. This mailbox is particularly
Vaudreuil & Parsons Standards Track [Page 7]
RFC 2421 VPIM v2 September 1998
to receive text messages, which is not normal on a voice
platform. The specific handling of these messages is an
implementation choice
non-mail-user@
If a reply to a message is not possible, such as a
answering message, then the special address "non-mail-user" must
used as the originator's address. Any text name such as "
Answering", or the telephone number if it is available, is permitted
This special address is used as a token to indicate an
originator. For compatibility with the installed base of mail
agents, implementations that generate this special address MUST
a negative delivery status notification (DSN) for reply messages
to the undeliverable address. The status code for such NDN's
5.1.1 "Mailbox does not exist".
Example
From: Telephone Answering
4.1.3 Distribution
There are many ways to handle distribution list (DL) expansions
none are 'standard'. Simple alias is a behavior closest to what
voice mail systems do today and what is to be used with
messages. That is
Reply to the originator - (Address in the RFC822 Reply-to or
field
Errors to the submitter - (Address in the MAIL FROM: field of
ESMTP exchange and the Return-Path
RFC 822 field
Some proprietary voice messaging protocols include only the
of the particular copy in the envelope and include no "header fields
except date and per-message features. Most voice messaging
do not provide for "Header Information" in their messaging queues
only include delivery information. As a result,
information MAY be in either the To or CC header fields. If
recipients cannot be presented (e.g. unknown DL expansion) then
recipient header fields MUST be omitted to indicate that an
list of recipients (e.g. for use with a reply-all capability) is
known
Vaudreuil & Parsons Standards Track [Page 8]
RFC 2421 VPIM v2 September 1998
4.2 Message Header
Internet messages contain a header information block. This
block contains information required to identify the sender, the
of recipients, the message send time, and other information
for user presentation. Except for specialized gateway and
list cases, header fields do not indicate delivery options for
transport of messages
Distribution list processors are noted for modifying or adding to
header fields of messages that pass through them. VPIM systems
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
The originator's fully-qualified domain address (a mailbox
followed by the fully-qualified domain name). The user listed
this field should be presented in the voice message envelope as
originator of the message
Systems compliant with this profile SHOULD provide the text
name of the voice message originator in a quoted phrase, if the
is available. Text names of corporate or positional mailboxes MAY
provided as a simple string. From [RFC822]
Example
From: "Joe S. User" <12145551212@mycompany.com
From: Technical Support <611@serviceprovider.com
The From address SHOULD be used for replies (see 4.6). However,
the From address contains , the user SHOULD
be offered the option to reply, nor should notifications be sent
this address
Voice mail machines may not be able to support separate
for the FROM, REPLY-TO, and SENDER header field and the SMTP
FROM command, VPIM conforming systems SHOULD set these values to
same address. Use of addresses different than those present in
From header field address may result in unanticipated behavior
Vaudreuil & Parsons Standards Track [Page 9]
RFC 2421 VPIM v2 September 1998
4.2.2
The To header contains the recipient's fully-qualified
address. There may be one or more To: fields in any message
Example
To: +12145551213@mycompany.
Systems compliant to this profile SHOULD provide a list of
only if all recipients are provided. The To header MUST NOT
included in the message if the sending message transport agent (MTA
cannot resolve all the addresses in it, e.g. if an address is a
alias for which the expansion is unknown (see 4.1.3). If present
the addresses in the To header MAY be used for a reply message to
recipients
Systems compliant to this profile MAY also discard the To
of incoming messages because of the inability to store
information. This would, of course, make a reply-to-all
impossible
4.2.3
The cc header contains additional recipients' fully-qualified
addresses. Many voice mail systems maintain only sufficient
information for message delivery and are not capable of storing
providing a complete list of recipients
Systems compliant to this profile SHOULD provide a list of
only if all disclosed recipients can be provided. The list
disclosed recipients does not include those sent via a blind copy.
not, systems SHOULD omit the To and Cc header fields to indicate
the full list of recipients is unknown
Example
Cc: +12145551213@mycompany.
Systems compliant to this profile MAY discard the Cc addresses
incoming messages as necessary. If a list of Cc or to addresses
present, these addresses MAY be used for a reply message to
recipients
Vaudreuil & Parsons Standards Track [Page 10]
RFC 2421 VPIM v2 September 1998
4.2.4
The Date header contains the date, time, and time zone in which
message was sent by the originator. The time zone SHOULD
represented in a four-digit time zone offset, such as -0500 for
American Eastern Standard Time. This may be supplemented by a
zone name in parentheses, e.g., "-0900 (PDT)".
implementations SHOULD be able to convert RFC 822 date and
stamps into local time
Example
Date: Wed, 28 Jul 96 10:08:49 -0800 (PST
The sending system MUST report the time the message was sent. If
VPIM sender is relaying a message from a system which does
provide a time stamp, the time of arrival at the VPIM system
be used as the date. From [RFC822]
4.2.5
The Sender header field contains the actual address of the
if the message is sent by an agent on behalf of the author
in the From: field. This header field MAY be sent by VPIM
system. If it is present in a VPIM message, the receiving
implementation may ignore the field and only present the From
field
4.2.6 Return
The Return-path header is added by the final delivering SMTP server
If present, it contains the address from the MAIL FROM parameter
the ESMTP exchange (see 5.1.2). Any error messages resulting from
delivery failure MUST be sent to this address (see [DRPT]
additional details). Note that if the Return-path is null ("<>"),
e.g. no path, loop prevention or confidential, a notification
NOT be sent. If the Return path address is not available (
from this header or the MAIL FROM parameter) the From address may
used to deliver notifications
4.2.7 Message-
The Message-id header contains a unique per-message identifier.
unique message-id MUST be generated for each message sent from
compliant implementation
The message-id is not required to be stored on the receiving system
This identifier MAY be used for tracking, auditing, and
Vaudreuil & Parsons Standards Track [Page 11]
RFC 2421 VPIM v2 September 1998
receipt notification reports. From [RFC822]
Example
Message-id: <12345678@mycompany.com
4.2.8 Reply-
If present, the reply-to header provides a preferred address to
reply messages should be sent (see 4.6). Typically, voice
systems can only support one originator of a message so it
unlikely that this field can be supported. A compliant system
NOT send a Reply-To header. However, if a reply-to header is present
a reply-to sender message MAY be sent to the address specified (
is, overwriting From). From [RFC822] This preferred address of
originator must also be provided in the originator's vCard
attribute, if present (see 4.3.3).
4.2.9
The Received header contains trace information added to the
of a RFC 822 message by MTAs. This is the only header permitted
be added by an MTA. Information in this header is useful
debugging when using an US-ASCII message reader or a header
tool
A compliant system MUST add Received header fields when acting as
gateway and MUST NOT remove any Received fields when
messages to other MTAs or gateways.. These header fields MAY
ignored or deleted when the message is received at the
destination. From [RFC822]
4.2.10 MIME
The MIME-Version header indicates that the message conforms to
MIME message format specification. Systems compliant with
specification SHOULD include a comment with the words "(Voice 2.0)".
RFC 1911 defines an earlier version of this profile and uses
token (Voice 1.0). From [MIME1][VPIM1]
Example
MIME-Version: 1.0 (Voice 2.0)
This identifier is intended for information only and SHOULD NOT
used to semantically identify the message as being a VPIM message
Instead, the presence of the content defined in [V-MSG] SHOULD
used if identification is necessary
Vaudreuil & Parsons Standards Track [Page 12]
RFC 2421 VPIM v2 September 1998
4.2.11 Content-
The content-type header declares the type of content enclosed in
message. The typical top level content in a VPIM Message SHOULD
multipart/voice-message, a mechanism for bundling several
into a single identifiable voice message. The allowable contents
detailed in section 4.3 of this document. From [MIME2]
4.2.12 Content-Transfer-
Because Internet mail was initially specified to carry only 7-
US-ASCII text, it may be necessary to encode voice and fax data
a representation suitable for that environment. The content
transfer-encoding header describes this transformation if it
needed. Compliant implementations MUST recognize and decode
standard encodings, "Binary", "7bit, "8bit", "Base64" and "Quoted
Printable". The allowable content-transfer-encodings are
in section 4.3. From [MIME1]
4.2.13
The sensitivity header, if present, indicates the requested
level. The case-insensitive values "Personal" and "Private"
specified. If no privacy is requested, this field is omitted
If a sensitivity header is present in the message, a compliant
MUST prohibit the recipient from forwarding this message to any
user. A compliant system, however, SHOULD allow the responder
reply to a sensitive message, but SHOULD NOT include the
message content. The sensitivity of the reply message MAY be set
the responder
If the receiving system does not support privacy and the
is one of "Personal" or "Private", a negative delivery
notification must sent to the originator with the appropriate
code indicating that privacy could not be assured. The
contents SHOULD be returned to the sender to allow for a
context with the notification. A non-delivery notification to
private message SHOULD NOT be tagged private since it will be sent
the originator. From: [X.400]
4.2.14
Indicates the requested importance to be given by the
system. The case-insensitive values "low", "normal" and "high"
specified. If no special importance is requested, this header may
omitted and the value assumed to be "normal".
Vaudreuil & Parsons Standards Track [Page 13]
RFC 2421 VPIM v2 September 1998
Compliant implementations MAY use this header to indicate
importance of a message and may order messages in a recipient'
mailbox. From: [X.400]
4.2.15
The subject field is often provided by email systems but is
widely supported on Voice Mail platforms. For compatibility with
based mailbox interfaces, a text subject field SHOULD be generated
a compliant implementation but MAY be discarded if present by
receiving system. From [RFC822]
It is recommended that voice messaging systems that do not
any text user interfaces (e.g. access only by a telephone) insert
generic subject header of "VPIM Message" for the benefit of
enabled recipients
4.2.16 Disposition-Notification-
This header MAY be present to indicate that the sender is
a receipt notification from the receiving user agent. This
disposition notification (MDN) is typically sent by the user
after the user has listened to the message and consented to an
being
Example
Disposition-notification-to: +12145551213@mycompany.
The presence of a Disposition-notification-to header in a message
merely a request for an MDN described in 4.4.5. The recipients'
agents are always free to silently ignore such a request so
header does not burden any system that does not support it.
[MDN].
4.2.17 Disposition-Notification-
This header MAY be present to define future extensions parameters
an MDN requested by the presence of the header in the
section. Currently no parameters are defined by this document or
[MDN]. However, this header MUST be parsed if present, if MDNs
supported. If it contains a extension parameter that is required
proper MDN generation (noted with "=required"), then an MDN MUST
be sent if the parameter is not understood. See [MDN] for
details
Vaudreuil & Parsons Standards Track [Page 14]
RFC 2421 VPIM v2 September 1998
Example
Disposition-notification-options
whizzbang=required,
4.3 Voice Message Content
MIME, introduced in [MIME1], is a general-purpose message body
that is extensible to carry a wide range of body parts. It
for encoding binary data so that it can be transported over the 7-
text-oriented SMTP protocol. This transport encoding (denoted by
Content-Transfer-Encoding header field) is in addition to the
encoding required to generate a binary object
MIME defines two transport encoding mechanisms to transform
data into a 7 bit representation, one designed for text-like
("Quoted-Printable"), and one for arbitrary binary data ("Base64").
While Base64 is dramatically more efficient for audio data,
will work. Where binary transport is available, no
encoding is needed, and the data can be labeled as "Binary".
An implementation in compliance with this profile SHOULD send
and/or facsimile data in binary form when binary message transport
available. When binary transport is not available,
MUST encode the audio and/or facsimile data as Base64. The
and decoding of "Quoted-Printable", "7bit", and "8bit" MUST
supported in order to meet MIME requirements and to
interoperability with the fullest range of possible devices
However, if a content is received in a transfer encoding that
be rendered to the user, an appropriate negative delivery
notification MUST be sent
The content types described in this section are identified for
within the multipart/voice-message content. This content, which
the fundamental part of a VPIM message, is referred to as a
voice message in this document
Only the contents profiled subsequently can be sent within a
voice message construct (i.e., the mulitpart/voice-message
type) to form a simple or a more complex structure (several
are given in Appendix B). The presence of other contents within
VPIM voice message is an error condition and SHOULD result in
negative delivery status notification. When multiple contents
present within the multipart/voice-message, they SHOULD be
to the user in the order that they appear in the message
Vaudreuil & Parsons Standards Track [Page 15]
RFC 2421 VPIM v2 September 1998
4.3.1 Multipart/Voice-
This MIME multipart structure provides a mechanism for packaging
voice message into one container that is tagged as VPIM v2 compliant
The semantic of multipart/Voice-Message (defined in [V-MSG])
identical to multipart/mixed and may be interpreted as that
systems that do not recognize this content-type
The Multipart/Voice-Message content-type MUST only contain
profiled media and content types specified in this section (i.e
audio/*, image/*, message/rfc822 and text/directory). The
common will be: spoken name, spoken subject, the message itself
attached fax and directory info. Forwarded messages are created
simply using the message/rfc822 construct
Conformant implementations MUST send the multipart/voice-message in
VPIM message. In most cases, this Multipart/Voice-Message
will be the top level (i.e. in the Content-Type header).
implementations MUST recognize the Multipart/Voice-Message
(whether it is a top level content or below a multipart/mixed) and
able to separate the contents (e.g. spoken name or spoken subject).
4.3.2 Message/RFC822
MIME requires support of the Message/RFC822 message
body part. This body part is used within a multipart/voice-
to forward complete messages (see 4.5) or to reply with
content (see 4.6). From [MIME2]
4.3.3 Text/
This content allows for the inclusion of a Versit vCard [VCARD
electronic business card within a VPIM message. The format
suitable as an interchange format between applications or systems
and is defined independent of the method used to transport it.
provides a useful mechanism to transport information about
originator that can be used by the receiving VPIM system (see 6)
other local
Each vCard MUST be contained within a Text/Directory content
[MIMEDIR] within a VPIM message. [MIMEDIR] requires that
character set MUST be defined as a parameter value (typically us
ascii for VPIM) and that the profile SHOULD be defined (the
MUST be vCard within VPIM messages).
Each VPIM message SHOULD be created with a Text/Directory (
profile) content type that MUST contain the preferred email address
telephone number, and text name of the message originator as well
Vaudreuil & Parsons Standards Track [Page 16]
RFC 2421 VPIM v2 September 1998
the vCard version. The vCard SHOULD contain the spoken name and
of the originator, as well as the revision date. Any other
attribute MAY also be present. The intent is that the vCard be
as the source of information to contact the originator (e.g., reply
call).If the text/directory content-type is included in a
message, the vCard profile [VCARD] MUST be used and MUST specify
least the following attributes
TEL - Public switched telephone number in international (E.164)
format (various types, typically VOICE
EMAIL - email address (various types, typically INTERNET;
type VPIM is optionally used to denote an address
supports VPIM messages(see 18.1))
VERSION - Indicates the version of the vCard profile. Version 3.0
[VCARD] MUST be used
The following attributes SHOULD be specified
N - Family Name, Given Name, Additional Names,
Prefixes, and Suffixes. Because it is expected
recipients using a telephone user interface will use
information in the vCard to identify the originator,
the GUI will see the information presented in the
line, all present components in the text name of the
header field MUST match the values provided by the Vcard
ROLE - The role of the person identified in `N' or `FN', but
also be used to distinguish when the sender is a
or positional
SOUND - spoken name sound data (various types, typically 32KADPCM
REV - Revision of vCard in ISO 8601 date
The vCard MAY use other attributes as defined in [VCARD]
extensions attributes not yet defined (e.g. capabilities).
If present, the spoken name attribute MUST be denoted by a content
pointing to an audio/* content elsewhere in the VPIM message
A typical VPIM message (i.e. no forwarded parts), MUST only
one vCard -- more than one is an error condition. A VPIM
that contains forwarded messages, though, may contain
vCards. However, these vCards MUST be associated with
originator(s) of the forwarded message(s) and the originator of
forwarding message. As a result, all forwarded vCards will
Vaudreuil & Parsons Standards Track [Page 17]
RFC 2421 VPIM v2 September 1998
contained in message/rfc822 contents -- only the vCard of
originator will be at the top-level
Example
Content-Type: text/directory; charset=us-ascii; profile=
Content-Transfer-Encoding: 7
BEGIN:
N:Parsons;
ORG:Northern
TEL;TYPE=VOICE;MSG;WORK:+1-613-763-7582
EMAIL;TYPE=INTERNET;glenn.parsons@nortel.
EMAIL;TYPE=INTERNET;VPIM:6137637582@vm.nortel.
SOUND;TYPE=32KADPCM;ENCODING=URI: CID:
REV:19960831T103310
VERSION: 3.0
END:
4.3.4 Audio/32
An implementation compliant to this profile MUST send Audio/32
by default for voice [ADPCM]. Receivers MUST be able to accept
decode Audio/32KADPCM. Typically this body contains several
of message content, however if used for spoken name or subject
content should be considerably shorter (i.e. about 10 and 20
respectively).
If an implementation can only handle one voice body, then
voice bodies (if present) SHOULD be concatenated, and SHOULD NOT
discarded. It is RECOMMENDED that this be done in the same order
they were sent. Note that if an Originator Spoken Name audio body
a vCard are both present in a VPIM message, the vCard SOUND
MUST point to this audio body (see 4.3.3).
While any valid MIME body header MAY be used, several header
have the following semantics when included with this body part
4.3.4.1 Content-Description
This field MAY be present to facilitate the text identification
these body parts in simple email readers. Any values may be used
though it may be useful to use values similar to those for Content
Disposition
Example
Content-Description: Big Telco Voice
Vaudreuil & Parsons Standards Track [Page 18]
RFC 2421 VPIM v2 September 1998
4.3.4.2 Content-Disposition
This field MUST be present to allow the parsable identification
these body parts. This is especially useful if, as is typical,
than one Audio/32KADPCM body occurs within a single level (e.g
multipart/voice-message). Since a VPIM voice message is intended
be automatically played upon display of the message, in the order
which the audio contents occur, the audio contents must always be
type inline. However, it is still useful to include a
value, so this should be present if this information is available
From [DISP
In order to distinguish between the various types of audio
in a VPIM voice message a new disposition parameter "voice"
defined with the parameter values below to be used as
(see 18.2):
Voice-Message - the primary voice message
Voice-Message-Notification - a spoken delivery
or spoken disposition notification
Originator-Spoken-Name - the spoken name of the originator
Recipient-Spoken-Name - the spoken name of the recipient
available to the originator and present if there is ONLY
recipient
Spoken-Subject- the spoken subject of the message,
spoken by the
Note that there SHOULD only be one instance of each of these types
audio contents per message level. Additional instances of a
type (i.e., parameter value) may occur within an attached
voice message
Implementations that do not understand the "voice" parameter (or
Content-Disposition header) can safely ignore it, and will
the audio bodyparts in order (but will not be able to
between them).
Example
Content-Disposition: inline; voice=spoken-subject
filename="msg001.726"
4.3.4.3 Content-Duration
This field MAY be present to allow the specification of the length
the audio bodypart in seconds. The use of this field on reception
a local implementation issue. From [DUR
Vaudreuil & Parsons Standards Track [Page 19]
RFC 2421 VPIM v2 September 1998
Example
Content-Duration: 33
4.3.4.4 Content-Language
This field MAY be present to allow the specification of the
language of the audio bodypart. The encoding is defined in [LANG].
The use of this field on reception is a local implementation issue
Example for UK English
Content-Language: en-
4.3.5 Image/
A common image encoding for facsimile, known as TIFF-F, is
derivative of the Tag Image File Format (TIFF) and is described
several documents. For the purposes of VPIM, the F Profile of
for Facsimile (TIFF-F) is defined in [TIFF-F] and the image/tiff
content type is defined in [TIFFREG]. While there are
formats of TIFF, only TIFF-F is profiled for use in a VPIM
message. Further, since the TIFF-F file format is used in a store
and-forward mode with VPIM, the image MUST be encoded so that
is only one image strip per facsimile page
All VPIM implementations that support facsimile SHOULD
TIFF-F compatible facsimile contents in the image/tiff
application=faxbw sub-type encoding by default. An
MAY send this fax content in VPIM voice messages and MUST be able
recognize and display it in received messages. If a fax message
received that cannot be rendered to the user (e.g. the receiving
system does not support fax), then the system MUST return the
with a negative delivery status notification with a media
supported status code
While any valid MIME body header MAY be used (e.g., Content
Disposition to indicate the filename), none are specified to
special semantics for VPIM and MAY be ignored. Note that the
type parameter application=faxbw MUST be included in
messages. However, inbound messages with or without this
MUST be rendered to the user (if the rendering software encounters
error in the file format, some form of negative delivery
notification MUST be sent to the originator).
Vaudreuil & Parsons Standards Track [Page 20]
RFC 2421 VPIM v2 September 1998
4.3.6 Proprietary Voice or Fax
Proprietary voice or fax encoding formats or other standard
MAY be supported under this profile provided a unique identifier
registered with the IANA prior to use (see [MIME4]). The
encodings should be registered as sub-types of Audio and the
encodings should be registered as sub-types of
Use of any other encoding except audio/32kadpcm or image/tiff
application=faxbw reduces interoperability in the absence of
manual system configuration. A compliant implementation MAY use
other encoding with explicit per-destination configuration
4.4 Other Message Content
An implementation compliant with this profile MAY send
contents in a VPIM message, but ONLY outside of the multipart/voice
message. The content types described in this section are
for use with this profile. Additional contents not defined in
profile MUST NOT be used without prior explicit per-
configuration. If an implementation receives a VPIM message
contains content types not specified in this profile, their
is a local implementation issue (e.g. the unknown contents MAY
discarded if they cannot be presented to the recipient). Conversely
if an implementation receives a non-VPIM message (i.e., without
mulitpart/voice-message content type) with any of the
defined in 4.3 & 4.4, it SHOULD deliver those contents, but the
message handling is a local issue (e.g. the unknown contents _or_
entire message MAY be discarded). Implementations MUST
negative delivery status notifications to the originator when
form of non-delivery to the recipient occurs
The multipart contents defined below MAY be sent as the top level
a VPIM message (with other noted contents below them as required.)
well, the multipart/mixed content SHOULD be used as the top level
a VPIM message to form a more complex structure (e.g.,
additional content types). When multiple contents are present,
SHOULD be presented to the user in the order that they appear in
message. Several examples are given in Appendix B
4.4.1 Multipart/
MIME provides the facilities for enclosing several body parts in
single message. Multipart/Mixed SHOULD only be used for
complex voice or multimedia messages. That is, as the top
Content-Type when sending one of the following contents (in
to the VPIM voice message) in a VPIM message. Compliant systems
accept multipart/mixed body parts. From [MIME2]
Vaudreuil & Parsons Standards Track [Page 21]
RFC 2421 VPIM v2 September 1998
4.4.2 Text/
MIME requires support of the basic Text/Plain content type.
content type has limited applicability within the voice
environment. However, because VPIM is a MIME profile,
requirements should be met. Compliant VPIM implementations
NOT send the Text/Plain content-type. Compliant implementations
accept Text/Plain messages, however, specific handling is left as
implementation decision. From [MIME2]
There are several mechanisms that can be used to support text (
accepted) on voice messaging systems including text-to-speech
text-to-fax conversions. If no rendering of the text is
(i.e., it is not possible for the recipient to determine if the
is a critical part of the message), the entire message MUST
returned to the sender with a negative delivery status
and a media-unsupported status code
4.4.3 Multipart/
The Multipart/Report is used for enclosing human-readable and
parsable notification (e.g. Message/delivery-status) body parts
any returned message content. The multipart/report content-type
used to deliver both delivery status reports indicating
success or failure and message disposition notifications to
post-delivery events such as receipt notification.
implementations MUST use the Multipart/Report construct.
implementations MUST recognize and decode the Multipart/
content type and its components in order to present the report to
user. From [REPORT
Multipart/Report messages from VPIM implementations SHOULD
the human-readable description of the error as a spoken audio/*
content (this speech SHOULD also be made available to
notification recipient). As well, VPIM implementations MUST be
to handle (and MAY generate) Multipart/Report messages that
the human-readable description of the error as text. Note that
[DSN] the human-readable part MUST always be present
4.4.4 Message/Delivery-
This MIME body part is used for sending machine-parsable
status notifications. Compliant implementations MUST use
Message/delivery-status construct when returning messages or
warnings. Compliant implementations MUST recognize and decode
Message/delivery-status content type and present the reason
failure to the sender of the message. From [DSN
Vaudreuil & Parsons Standards Track [Page 22]
RFC 2421 VPIM v2 September 1998
4.4.5 Message/Disposition-
This MIME body part is used for sending machine-parsable
notification message disposition notifications.
implementations SHOULD use the Message/Disposition-
construct when sending post-delivery message status notifications
These MDNs, however, MUST only be sent in response to the presence
the Disposition-notification-to header in 4.2.16.
implementations should recognize and decode the Message/Disposition
notification content type and present the notification to the user
From [MDN
4.5 Forwarded
VPIM version 2 explicitly supports the forwarding of voice and
content with voice or fax annotation. However, only the
constructs described below are acceptable in a VPIM message.
only the first (i.e. message/rfc822) can be recognized as a
message (or even multiple forwarded messages), it is RECOMMENDED
this construct be used whenever possible
Forwarded VPIM messages SHOULD be sent as a multipart/voice-
with the entire original message enclosed in a message/rfc822
type and the annotation as a separate Audio/* or image/* body part
If the RFC822 header fields are not available for the
content, simulated header fields with available information SHOULD
constructed to indicate the original sending timestamp, and
original sender as indicated in the "From" line. However, note
at least one of "From", "Subject", or "Date" MUST be present.
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
concatenation of the original message and the forwarding annotation
such as must be done in a gateway between VPIM and the AMIS
messaging protocol, the entire audio content MAY be sent as a
Audio/* segment without including any forwarding semantics
4.6 Reply
Replies to VPIM messages (and Internet mail messages) are
to the address noted in the reply-to header (see 4.2.8) if it
present, else the From address (see 4.2.1) is used. The vCard
attribute, if present, SHOULD be the same as the reply-to address
may be the same as the From address. While the vCard is the
preferred address it SHOULD NOT be used to generate a reply. Also
the Return-path address should not be used for replies
Vaudreuil & Parsons Standards Track [Page 23]
RFC 2421 VPIM v2 September 1998
Support of multiple originator header fields is often not possible
voice messaging systems, so it may be necessary to choose only
when gatewaying a VPIM message to another voice message system
However, implementers should note that this may make it impossible
send error messages and replies to their proper destinations
In some cases, a reply message is not possible, such as with
message created by telephone answering (i.e. classic voice mail).
this case, the From field MUST contain the special address non-mail
user@domain (see 4.1.2). A null ESMTP MAIL FROM address SHOULD
be used in this case (see 5.1.2). A receiving VPIM system SHOULD
offer the user the option to reply to this kind of message
4.7 Notification
VPIM delivery status notification messages (4.4.4) MUST be sent
the originator of the message when any form of non-delivery of
subject message or its components occurs. These error messages
be sent to the return path (4.2.6) if present, otherwise, the
(4.2.1) address may be used
VPIM Receipt Notification messages (4.4.5) should be sent to
sender specified in the Disposition-Notification-To header
(4.2.16), only after the message has been presented to the
or if the message has somehow been disposed of without
presented to the recipient (e.g. if it were deleted before
it).
VPIM Notification messages may be positive or negative, and
indicate delivery at the server or receipt by the client. However
the notification MUST be contained in a multipart/report
(4.4.3) and SHOULD contain a spoken error message
If a VPIM system receives a message with contents that are
understood (see 4.3 & 4.4), its handling is a local matter.
delivery status notification SHOULD be generated if the message
not be delivered because of unknown contents (e.g., on
voice processing systems). In some cases, the message may
delivered (with a positive DSN sent) to a mailbox before
determination of rendering can be made
5. Message Transport
Messages are transported between voice mail machines using
Internet Extended Simple Mail Transfer Protocol (ESMTP).
information required for proper delivery of the message is
in the ESMTP dialog. This information, including the sender
recipient addresses, is commonly referred to as the
Vaudreuil & Parsons Standards Track [Page 24]
RFC 2421 VPIM v2 September 1998
"envelope". This information is equivalent to the message
block in many analog voice messaging protocols
ESMTP is a general-purpose messaging protocol, designed both to
mail and to allow terminal console messaging. Simple Mail
Protocol (SMTP) was originally created for the exchange of US-
7-bit text messages. Binary and 8-bit text messages
traditionally been transported by encoding the messages into a 7-
text-like form. [ESMTP] formalized an extension mechanism for SMTP
and subsequent RFCs have defined 8-bit text networking,
streaming, binary networking, and extensions to permit
declaration of message size for the efficient transmission of
messages such as multi-minute voice mail
The following sections list ESMTP commands, keywords, and
that are required and those that are optional for conformance to
profile
5.1 ESMTP
5.1.1
Base SMTP greeting and identification of sender. This command is
to be sent by compliant systems unless the more-capable EHLO
is not accepted. It is included for compatibility with general
implementations. Compliant servers MUST implement the HELO
for backward compatibility but clients SHOULD NOT send it unless
is not supported. From [SMTP
5.1.2 MAIL FROM (REQUIRED
Originating mailbox. This address contains the mailbox to
errors should be sent. VPIM implementations SHOULD use the
address in the MAIL FROM command as is used in the From header field
This address is not necessarily the same as the message Sender
in the message header fields if the message was received from
gateway or sent to an Internet-style mailing list. From [SMTP, ESMTP
The MAIL FROM address SHOULD be stored in the local message store
the purposes of generating a delivery status notification to
originator. The address indicated in the MAIL FROM command SHOULD
passed as a local system parameter or placed in a Return-Path:
inserted at the beginning of a VPIM message. From [HOSTREQ
Since delivery status notifications MUST be sent to the MAIL
address, the use of the null address ("<>") is often used to
looping of messages. This null address MAY be used to note that
particular message has no return path (e.g. a telephone
Vaudreuil & Parsons Standards Track [Page 25]
RFC 2421 VPIM v2 September 1998
message). From [SMTP
5.1.3 RCPT
Recipient's mailbox. The parameter to this command contains only
address to which the message should be delivered for
transaction. It is the set of addresses in one or more RCPT
commands that are used for mail routing. From [SMTP, ESMTP
Note: In the event that multiple transport connections to
destination machines are required for the same message, the set
addresses in a given transport connection may not match the list
recipients in the message header fields
5.1.4
Initiates the transfer of message data. Support for this command
required. Compliant implementations MUST implement the SMTP
command for backwards compatibility. From [SMTP
5.1.5
Requests a change-of-roles, that is, the client that opened
connection offers to assume the role of server for any mail
remote machine may wish to send. Because SMTP is not
authenticated protocol, the TURN command presents an opportunity
improperly fetch