success or failure and message disposition notifications to indicate
post-delivery events such as receipt notification. Compliant
implementations MUST use the Multipart/Report construct. Compliant
implementations MUST recognize and decode the Multipart/Report
content type and its components in order to present the report to the
user. From [REPORT]
Multipart/Report messages from VPIM implementations SHOULD include
the human-readable description of the error as a spoken audio/*
content (this speech SHOULD also be made available to the
notification recipient). As well, VPIM implementations MUST be able
to handle (and MAY generate) Multipart/Report messages that encode
the human-readable description of the error as text. Note that per
[DSN] the human-readable part MUST always be present.
4.4.4 Message/Delivery-status
This MIME body part is used for sending machine-parsable delivery
status notifications. Compliant implementations MUST use the
Message/delivery-status construct when returning messages or sending
warnings. Compliant implementations MUST recognize and decode the
Message/delivery-status content type and present the reason for
failure to the sender of the message. From [DSN]
4.4.5 Message/Disposition-notification
This MIME body part is used for sending machine-parsable receipt
notification message disposition notifications. Conforming
implementations SHOULD use the Message/Disposition-notification
construct when sending post-delivery message status notifications.
These MDNs, however, MUST only be sent in response to the presence of
the Disposition-notification-to header in 4.2.16. Conforming
implementations should recognize and decode the Message/Disposition-
notification content type and present the notification to the user.
From [MDN]
4.5 Forwarded Messages
VPIM version 2 explicitly supports the forwarding of voice and fax
content with voice or fax annotation. However, only the two
constructs described below are acceptable in a VPIM message. Since
only the first (i.e. message/rfc822) can be recognized as a forwarded
message (or even multiple forwarded messages), it is RECOMMENDED that
this construct be used whenever possible.
Forwarded VPIM messages SHOULD be sent as a multipart/voice-message
with the entire original message enclosed in a message/rfc822 content
type and the annotation as a separate Audio/* or image/* body part.
If the RFC822 header fields are not available for the forwarded
content, simulated header fields with available information SHOULD be
constructed to indicate the original sending timestamp, and the
original sender as indicated in the "From" line. However, note that
at least one of "From", "Subject", or "Date" MUST be present. As
well, the message/rfc822 content MUST include at least the "MIME-
Version", and "Content-Type" header fields. From [MIME2]
In the event that forwarding information is lost through
concatenation of the original message and the forwarding annotation,
such as must be done in a gateway between VPIM and the AMIS voice
messaging protocol, the entire audio content MAY be sent as a single
Audio/* segment without including any forwarding semantics.
4.6 Reply Messages
Replies to VPIM messages (and Internet mail messages) are addressed
to the address noted in the reply-to header (see 4.2.8) if it is
present, else the From address (see 4.2.1) is used. The vCard EMAIL
attribute, if present, SHOULD be the same as the reply-to address and
may be the same as the From address. While the vCard is the senders
preferred address it SHOULD NOT be used to generate a reply. Also,
the Return-path address should not be used for replies.
Support of multiple originator header fields is often not possible on
voice messaging systems, so it may be necessary to choose only one
when gatewaying a VPIM message to another voice message system.
However, implementers should note that this may make it impossible to
send error messages and replies to their proper destinations.
In some cases, a reply message is not possible, such as with a
message created by telephone answering (i.e. classic voice mail). In
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 also
be used in this case (see 5.1.2). A receiving VPIM system SHOULD NOT
offer the user the option to reply to this kind of message.
4.7 Notification Messages
VPIM delivery status notification messages (4.4.4) MUST be sent to
the originator of the message when any form of non-delivery of the
subject message or its components occurs. These error messages must
be sent to the return path (4.2.6) if present, otherwise, the From
(4.2.1) address may be used.
VPIM Receipt Notification messages (4.4.5) should be sent to the
sender specified in the Disposition-Notification-To header field
(4.2.16), only after the message has been presented to the recipient
or if the message has somehow been disposed of without being
presented to the recipient (e.g. if it were deleted before playing
it).
VPIM Notification messages may be positive or negative, and can
indicate delivery at the server or receipt by the client. However,
the notification MUST be contained in a multipart/report container
(4.4.3) and SHOULD contain a spoken error message.
If a VPIM system receives a message with contents that are not
understood (see 4.3 & 4.4), its handling is a local matter. A
delivery status notification SHOULD be generated if the message could
not be delivered because of unknown contents (e.g., on traditional
voice processing systems). In some cases, the message may be
delivered (with a positive DSN sent) to a mailbox before the
determination of rendering can be made.
5. Message Transport Protocol
Messages are transported between voice mail machines using the
Internet Extended Simple Mail Transfer Protocol (ESMTP). All
information required for proper delivery of the message is included
in the ESMTP dialog. This information, including the sender and
recipient addresses, is commonly referred to as the message
"envelope". This information is equivalent to the message control
block in many analog voice messaging protocols.
ESMTP is a general-purpose messaging protocol, designed both to send
mail and to allow terminal console messaging. Simple Mail Transport
Protocol (SMTP) was originally created for the exchange of US-ASCII
7-bit text messages. Binary and 8-bit text messages have
traditionally been transported by encoding the messages into a 7-bit
text-like form. [ESMTP] formalized an extension mechanism for SMTP,
and subsequent RFCs have defined 8-bit text networking, command
streaming, binary networking, and extensions to permit the
declaration of message size for the efficient transmission of large
messages such as multi-minute voice mail.
The following sections list ESMTP commands, keywords, and parameters
that are required and those that are optional for conformance to this
profile.
5.1 ESMTP Commands
5.1.1 HELO
Base SMTP greeting and identification of sender. This command is not
to be sent by compliant systems unless the more-capable EHLO command
is not accepted. It is included for compatibility with general SMTP
implementations. Compliant servers MUST implement the HELO command
for backward compatibility but clients SHOULD NOT send it unless EHLO
is not supported. From [SMTP]
5.1.2 MAIL FROM (REQUIRED)
Originating mailbox. This address contains the mailbox to which
errors should be sent. VPIM implementations SHOULD use the same
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 listed
in the message header fields if the message was received from a
gateway or sent to an Internet-style mailing list. From [SMTP, ESMTP]
The MAIL FROM address SHOULD be stored in the local message store for
the purposes of generating a delivery status notification to the
originator. The address indicated in the MAIL FROM command SHOULD be
passed as a local system parameter or placed in a Return-Path: line
inserted at the beginning of a VPIM message. From [HOSTREQ]
Since delivery status notifications MUST be sent to the MAIL FROM
address, the use of the null address ("<>") is often used to prevent
looping of messages. This null address MAY be used to note that a
particular message has no return path (e.g. a telephone answer
message). From [SMTP]
5.1.3 RCPT TO
Recipient's mailbox. The parameter to this command contains only the
address to which the message should be delivered for this
transaction. It is the set of addresses in one or more RCPT TO
commands that are used for mail routing. From [SMTP, ESMTP]
Note: In the event that multiple transport connections to multiple
destination machines are required for the same message, the set of
addresses in a given transport connection may not match the list of
recipients in the message header fields.
5.1.4 DATA
Initiates the transfer of message data. Support for this command is
required. Compliant implementations MUST implement the SMTP DATA
command for backwards compatibility. From [SMTP]
5.1.5 TURN
Requests a change-of-roles, that is, the client that opened the
connection offers to assume the role of server for any mail the
remote machine may wish to send. Because SMTP is not an
authenticated protocol, the TURN command presents an opportunity to
improperly fetch mail queued for another destination. Compliant
implementations SHOULD NOT implement the TURN command. From [SMTP]
5.1.6 QUIT
Requests that the connection be closed. If accepted, the remote
machine will reset and close the connection. Compliant
implementations MUST implement the QUIT command. From [SMTP]
5.1.7 RSET
Resets the connection to its initial state. Compliant
implementations MUST implement the RSET command. From [SMTP]
5.1.8 VRFY
Requests verification that this node can reach the listed recipient.
While this functionality is also included in the RCPT TO command,
VRFY allows the query without beginning a mail transfer transaction.
This command is useful for debugging and tracing problems. Compliant
implementations MAY implement the VRFY command. From [SMTP] (Note
that the implementation of VRFY may simplify the guessing of a
recipient's mailbox or automated sweeps for valid mailbox addresses,
resulting in a possible reduction in privacy. Various implementation
techniques may be used to reduce the threat, such as limiting the
number of queries per session.) From [SMTP]
5.1.9 EHLO
The enhanced mail greeting that enables a server to announce support
for extended messaging options. The extended messaging modes are
discussed in subsequent sections of this document. Compliant
implementations MUST implement the ESMTP command and return the
capabilities indicated later in this memo. From [ESMTP]
5.1.10 BDAT
The BDAT command provides a higher efficiency alternative to the
earlier DATA command, especially for voice. The BDAT command provides
for native binary transport of messages. Compliant implementations
SHOULD support binary transport using the BDAT command [BINARY].
5.2 ESMTP Keywords
The following ESMTP keywords indicate extended features useful for
voice messaging.
5.2.1 PIPELINING
The "PIPELINING" keyword indicates ability of the receiving server to
accept new commands before issuing a response to the previous
command. Pipelining commands dramatically improves performance by
reducing the number of round-trip packet exchanges and makes it
possible to validate all recipient addresses in one operation.
Compliant implementations SHOULD support the command pipelining
indicated by this keyword. From [PIPE]
5.2.2 SIZE
The "SIZE" keyword provides a mechanism by which the SMTP server can
indicate the maximum size message supported. Compliant servers MUST
provide size extension to indicate the maximum size message that can
be accepted. Clients SHOULD NOT send messages larger than the size
indicated by the server. Clients SHOULD advertise SIZE= when sending
messages to servers that indicate support for the SIZE extension.
From [SIZE]
5.2.3 CHUNKING
The "CHUNKING" keyword indicates that the receiver will support the
high-performance binary transport mode. Note that CHUNKING can be
used with any message format and does not imply support for binary
encoded messages. Compliant implementations MAY support binary
transport indicated by this capability. From [BINARY]
5.2.4 BINARYMIME
The "BINARYMIME" keyword indicates that the SMTP server can accept
binary encoded MIME messages. Compliant implementations MAY support
binary transport indicated by this capability. Note that support for
this feature requires support of CHUNKING. From [BINARY]
5.2.5 DSN
The "DSN" keyword indicates that the SMTP server will accept explicit
delivery status notification requests. Compliant implementations
MUST support the delivery notification extensions in [DRPT].
5.2.6 ENHANCEDSTATUSCODES
The "ENHANCEDSTATUSCODES" keyword indicates that an SMTP server
augments its responses with the enhanced mail system status codes
[CODES]. These codes can then be used to provide more informative
explanations of error conditions, especially in the context of the
delivery status notifications format defined in [DSN]. Compliant
implementations SHOULD support this capability. From [STATUS]
5.3 ESMTP Parameters - MAIL FROM
5.3.1 BINARYMIME
The current message is a binary encoded MIME messages. Compliant
implementations SHOULD support binary transport indicated by this
parameter. From [BINARY]
5.3.2 RET
The RET parameter indicates whether the content of the message should
be returned. Compliant systems SHOULD honor a request for returned
content. From [DRPT]
5.3.3 ENVID
The ENVID keyword of the SMTP MAIL command is used to specify an
"envelope identifier" to be transmitted along with the message and
included in any DSNs issued for any of the recipients named in this
SMTP transaction. The purpose of the envelope identifier is to allow
the sender of a message to identify the transaction for which the DSN
was issued. Compliant implementations MAY use this parameter. From
[DRPT]
5.4 ESMTP Parameters - RCPT TO
5.4.1 NOTIFY
The NOTIFY parameter indicates the conditions under which a delivery
report should be sent. Compliant implementations MUST honor this
request. From [DRPT]
5.4.2 ORCPT
The ORCPT keyword of the RCPT command is used to specify an
"original" recipient address that corresponds to the actual recipient
to which the message is to be delivered. If the ORCPT esmtp-keyword
is used, it MUST have an associated esmtp-value, which consists of
the original recipient address, encoded according to the rules below.
Compliant implementations MAY use this parameter. From [DRPT]
5.5 ESMTP - SMTP Downgrading
The ESMTP extensions suggested or required for conformance to VPIM
fall into two categories. The first category includes features which
increase the efficiency of the transport system such as SIZE,
BINARYMIME, and PIPELINING. In the event of a downgrade to a less
functional transport system, these features can be dropped with no
functional change to the sender or recipient.
The second category of features are transport extensions in support
of new functions. DSN and EnhancedStatusCodes provide essential
improvements in the handling of delivery status notifications to
bring email to the level of reliability expected of Voice Mail. To
ensure a consistent level of service across an intranet or the global
Internet, it is essential that VPIM compliant ESMTP support the ESMTP
DSN extension at all hops between a VPIM originating system and the
recipient system. In the situation where a `downgrade' is unavoidable
a relay hop may be forced (by the next hop) to forward a VPIM message
without the ESMTP request for positive delivery status notification.
It is RECOMMENDED that the downgrading system should continue to
attempt to deliver the message, but MUST send an appropriate delivery
notification to the originator, e.g. the message left an ESMTP host
and was sent (unreliably) via SMTP.
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.
7. IMAP
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
translation gateways.
In order to accommodate all environments, this document defines two
areas of conformance: transport and content.
Transport conformant systems will pass VPIM messages in a store and
forward manner with assured delivery notifications and without the
loss of information. It is expected that most store and forward
Internet mail based messaging systems will be VPIM transport
compliant.
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
delivery problems.
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
services.
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.
11. REFERENCES
[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", RFC2422,
September 1998.
[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", RFC1830, October 1995.
[CODES] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC1893,
January 1996.
[MIMEDIR] Howes, T., Smith, M., and F. Dawson, "A MIME Content-Type
for Directory Information", RFC2425, September 1998.
[DISP] Troost, R., and S. Dorner, "Communicating Presentation
Information in Internet Messages: The Content-Disposition
Header", RFC2183, August 1997.
[DNS1] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC1035, November 1987.
[DNS2] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC1034, November 1987.
[DRPT] Moore, K., "SMTP Service Extensions for Delivery Status
Notifications", RFC1891, January 1996.
[DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for
Delivery Status Notifications", RFC1894, January 1996.
[DUR] Vaudreuil, G., and G. Parsons, "Content Duration MIME Header
Definition", RFC2424, 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", RFC1869, 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, RFC1123, October 1989.
[LANG] Alvestrand, H., "Tags for the Identification of Languages",
RFC1766, March 1995.
[MDN] Fajman, R., "An Extensible Message Format for Message
Disposition Notifications", RFC2298, March 1998.
[MIB II] Rose, M., "Management Information Base for Network
Management of TCP/IP-based internets: MIB-II", RFC1158, May
1990.
[MIME1] Freed, N., and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC2045, November 1996.
[MIME2] Freed, N., and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC2046, November
1996.
[MIME3] Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part
Three: Message Header Extensions for Non-ASCII Text", RFC
2047, November 1996.
[MIME4] Freed, N., Klensin, J., and J. Postel, "Multipurpose
Internet Mail Extensions (MIME) Part Four: Registration
Procedures", RFC2048, November 1996.
[MIME5] Freed, N., and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and
Examples", RFC2049, November 1996.
[PIPE] Freed, N., and A. Cargille, "SMTP Service Extension for
Command Pipelining", RFC1854, October 1995.
[REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the
Reporting of Mail System Administrative Messages", RFC1892,
January 1996.
[REQ] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC822, August 1982.
[SIZE] Klensin, J., Freed, N., and K. Moore, "SMTP Service Extensions
for Message Size Declaration", RFC1870, November 1995.
[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC821,
August 1982.
[STATUS] Freed, N., "SMTP Service Extension for Returning Enhanced
Error Codes", RFC2034, October 1996.
[TIFF-F] Parsons, G., and J. Rafferty, "Tag Image File Format:
Application F", RFC2306, March 1998.
[TIFFREG] Parsons, G., Rafferty, J., and S. Zilles, "Tag Image File
Format: image/tiff - MIME sub-type registraion", RFC2302,
March 1998.
[V-MSG] Vaudreuil, G., and G. Parsons, "VPIM Voice Message: MIME
Sub-type Registration", RFC2423, September 1998.
[VCARD] Dawson, F., and T. Howes, "vCard MIME Directory Profile", RFC
2426, September 1998.
[VPIM1] Vaudreuil, G., "Voice Profile for Internet Mail", RFC1911,
February 1996.
[X.400] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO
10021 and RFC822", RFC1327, May 1992.
12. Acknowledgments
The authors would like to offer a special thanks to the Electronic
Messaging Association (EMA), especially the members of the Voice
Messaging Committee and the VPIM Work Group, for their support of the
VPIM specification and the efforts they have made to ensure its
success.
The EMA hosts the VPIM web page at http://www.ema.org/vpim.
13. Authors' Addresses
Glenn W. Parsons
Northern Telecom
P.O. Box 3511, Station C
Ottawa, ON K1Y 4H7
Canada
Phone: +1-613-763-7582
Fax: +1-613-763-4461
EMail: Glenn.Parsons@Nortel.ca
Gregory M. Vaudreuil
Lucent Technologies,
Octel Messaging Division
17080 Dallas Parkway
Dallas, TX 75248-1905
United States
Phone/Fax: +1-972-733-2722
EMail: GregV@Lucent.Com
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
need.
Must not - prohibited
Footnote - special comment about conformance for a particular
feature
VPIM version 2 Conformance
| | | | |S| |
| | | | | |H| |F
| | | | | |O|M|o
| | | |S| |U|U|o
| | | |H| |L|S|t
| |A|M|O| |D|T|n
| |R|U|U|M| | |o
| |E|S|L|A|N|N|t
| |A|T|D|Y|O|O|t
FEATURE |SECTION | | | | |T|T|e
-------------------------------------------|----------|-|-|-|-|-|-|-
| | | | | | | |
Message Addressing Formats: | | | | | | | |
Use DNS host names |4.1 |C|x| | | | |
Use only numbers in mailbox IDs |4.1.1 |C| |x| | | |
Use alpha-numeric mailbox IDs |4.1.1 |C| | |x| | |
Support of postmaster@domain |4.1.2 |C|x| | | | |
Support of non-mail-user@domain |4.1.2 |C| |x| | | |
Support of distribution lists |4.1.3 |C| |x| | | |
| | | | | | | |
Message Header Fields: | | | | | | | |
Encoding outbound messages | | | | | | | |
From |4.2.1 |C|x| | | | |
Addition of text name |4.2.1 |C| |x| | | |
To |4.2.2 |C|x| | | | |1
cc |4.2.3 |C| |x| | | |1
Date |4.2.4 |C|x| | | | |
Sender |4.2.5 |C| | |x| | |
Return-Path |4.2.6 |C| | |x| | |
Message-id |4.2.7 |C|x| | | | |
Reply-To |4.2.8 |C| | | |x| |
Received |4.2.9 |C|x| | | | |
MIME Version: 1.0 (Voice 2.0) |4.2.10 |C| |x| | | |
Content-Type |4.2.11 |C|x| | | | |
Content-Transfer-Encoding |4.2.12 |C|x| | | | |
Sensitivity |4.2.13 |C| | |x| | |
Importance |4.2.14 |C| | |x| | |
Subject |4.2.15 |C| |x| | | |
Disposition-notification-to |4.2.16 |C| | |x| | |
Disposition-notification-options |4.2.17 |C| | |x| | |
Other Headers |4.2 |C| | |x| | |
| | | | | | | |
| | | | |S| |
| | | | | |H| |F
| | | | | |O|M|o
| | | |S| |U|U|o
| | | |H| |L|S|t
| |A|M|O| |D|T|n
| |R|U|U|M| | |o
| |E|S|L|A|N|N|t
| |A|T|D|Y|O|O|t
FEATURE |SECTION | | | | |T|T|e
-------------------------------------------|----------|-|-|-|-|-|-|-
Detection & Decoding inbound messages | | | | | | | |
From |4.2.1 |C|x| | | | |
Present text personal name |4.2.1 |C| | |x| | |
To |4.2.2 |C|x| | | | |
cc |4.2.3 |C| | |x| | |
Date |4.2.4 |C|x| | | | |
Conversion of Date to local time |4.2.4 |C| |x| | | |
Sender |4.2.5 |C| | |x| | |
Return-Path |4.2.6 |C| | |x| | |
Message ID |4.2.7 |C|x| | | | |
Reply-To |4.2.8 |C| |x| | | |
Received |4.2.9 |C| | |x| | |
MIME Version: 1.0 (Voice 2.0) |4.2.10 |C| |x| | | |
Content Type |4.2.11 |C|x| | | | |
Content-Transfer-Encoding |4.2.12 |C|x| | | | |
Sensitivity |4.2.13 |C|x| | | | |2
Importance |4.2.14 |C| | |x| | |
Subject |4.2.15 |C| | |x| | |
Disposition-notification-to |4.2.16 |C| | |x| | |
Disposition-notification-options |4.2.17 |C| | |x| | |
Other Headers |4.2 |C|x| | | | |3
| | | | | | | |
Message Content Encoding: | | | | | | | |
Encoding outbound audio/fax contents | | | | | | | |
7BIT |4.3 |C| | | | |x|
8BIT |4.3 |C| | | | |x|
Quoted Printable |4.3 |C| | | | |x|
Base64 |4.3 |C|x| | | | |4
Binary |4.3 |C| |x| | | |5
Detection & decoding inbound messages | | | | | | | |
7BIT |4.3 |C|x| | | | |
8BIT |4.3 |C|x| | | | |
Quoted Printable |4.3 |C|x| | | | |
Base64 |4.3 |C|x| | | | |
Binary |4.3 |C|x| | | | |5
| | | | | | | |
| | | | |S| |
| | | | | |H| |F
| | | | | |O|M|o
| | | |S| |U|U|o
| | | |H| |L|S|t
| |A|M|O| |D|T|n
| |R|U|U|M| | |o
| |E|S|L|A|N|N|t
| |A|T|D|Y|O|O|t
FEATURE |SECTION | | | | |T|T|e
-------------------------------------------|----------|-|-|-|-|-|-|-
Message Content Types: | | | | | | | |
Inclusion in outbound messages | | | | | | | |
Multipart/Voice-Message |4.3.1 |C|x| | | | |
Message/RFC822 |4.3.2 |C| | |x| | |
Text/Directory |4.3.3 |C| |x| | | |
include TEL, EMAIL, VERSION |4.3.3 |C|x| | | | |
include ROLE, SOUND, N, REV |4.3.3 |C| |x| | | |
only one voice type per level |4.3.3 |C|x| | | | |
Audio/32KADPCM |4.3.4 |C|x| | | | |
Content-Description |4.3.4.1 |C| | |x| | |
Content-Disposition |4.3.4.2 |C|x| | | | |
Content-Duration |4.3.4.3 |C| | |x| | |
Content-Langauge |4.3.4.4 |C| | |x| | |
Image/tiff; application=faxbw |4.3.5 |C| | |x| | |
Audio/* or Image/* (other encodings) |4.3.6 |C| | |x| | |
Multipart/Mixed |4.4.1 |C| | |x| | |
Text/plain |4.4.2 |C| | | |x| |
Multipart/Report |4.4.3 |C|x| | | | |
human-readable part is voice |4.4.3 |C| |x| | | |
human-readable part is text |4.4.3 |C| | |x| | |
Message/delivery-status |4.4.4 |C|x| | | | |
Message/disposition-notification |4.4.5 |C| |x| | | |
Other contents |4.4 |C| | | |x| |6
| | | | | | | |
Detection & decoding in inbound messages | | | | | | | |
Multipart/Voice-Message |4.3.1 |C|x| | | | |
Message/RFC822 |4.3.2 |C|x| | | | |
Text/Directory |4.3.3 |C| |x| | | |
recognize TEL, EMAIL, VERSION |4.3.3 |C|x| | | | |
recognize ROLE, SOUND, N, REV |4.3.3 |C| |x| | | |
Audio/32KADPCM |4.3.4 |C|x| | | | |
Content-Description |4.3.4.1 |C| | |x| | |
Content-Disposition |4.3.4.2 |C| |x| | | |
Content-Duration |4.3.4.3 |C| | |x| | |
Content-Langauge |4.3.4.4 |C| | |x| | |
Image/tiff; application=faxbw |4.3.5 |C| |x| | | |
send NDN if unable to render |4.3.5 |C|x| | | | |7
Audio/* or Image/* (other encodings) |4.3.6 |C| | |x| | |
Multipart/Mixed |4.4.1 |C|x| | | | |
Text/plain |4.4.2 |C|x| | | | |
send NDN if unable to render |4.4.2 |C|x| | | | |
| | | | | |S| |
| | | | | |H| |F
| | | | | |O|M|o
| | | |S| |U|U|o
| | | |H| |L|S|t
| |A|M|O| |D|T|n
| |R|U|U|M| | |o
| |E|S|L|A|N|N|t
| |A|T|D|Y|O|O|t
FEATURE |SECTION | | | | |T|T|e
------------------------------------------|-----------|-|-|-|-|-|-|-
| | | | | | | |
Multipart/Report |4.4.3 |C|x| | | | |
human-readable part is voice |4.4.3 |C| |x| | | |
human-readable part is text |4.4.3 |C|x| | | | |
Message/delivery-status |4.4.4 |C|x| | | | |
Message/disposition-notification |4.4.5 |C| |x| | | |
Other contents |4.4 |C| | | |x| |6
send NDN if unable to render |4.4 |C| |x| | | |
| | | | | | | |
Forwarded Messages | | | | | | | |
use Message/RFC822 construct |4.5 |C| |x| | | |
simulate headers if none available |4.5 |C| |x| | | |
| | | | | | | |
Reply Messages | | | | | | | |
send to Reply-to, else From address |4.6 |C|x| | | | |
do not send to non-mail-user |4.6 |C|x| | | | |
| | | | | | | |
Notifications | | | | | | | |
use multipart/report format |4.7 |C|x| | | | |
always send error on non-delivery |4.7 |C| |x| | | |
| | | | | | | |
Message Transport Protocol: | | | | | | | |
ESMTP Commands | | | | | | | |
HELO |5.1.1 |T|x| | | | |
MAIL FROM |5.1.2 |T|x| | | | |
support null address |5.1.2 |T|x| | | | |
RCPT TO |5.1.3 |T|x| | | | |
DATA |5.1.4 |T|x| | | | |
TURN |5.1.5 |T| | | | |x|
QUIT |5.1.6 |T|x| | | | |
RSET |5.1.7 |T|x| | | | |
VRFY |5.1.8 |T| | |x| | |
EHLO |5.1.9 |T|x| | | | |
BDAT |5.1.10 |T| | |x| | |5
| | | | |S| |
| | | | | |H| |F
| | | | | |O|M|o
| | | |S| |U|U|o
| | | |H| |L|S|t
| |A|M|O| |D|T|n
| |R|U|U|M| | |o
| |E|S|L|A|N|N|t
| |A|T|D|Y|O|O|t
FEATURE |SECTION | | | | |T|T|e
-------------------------------------------|----------|-|-|-|-|-|-|-
| | | | | | | |
ESMTP Keywords & Parameters | | | | | | | |
PIPELINING |5.2.1 |T| |x| | | |
SIZE |5.2.2 |T|x| | | | |
CHUNKING |5.2.3 |T| | |x| | |
BINARYMIME |5.2.4,5.3.1|T| | |x| | |
DSN |5.2.5 |T|x| | | | |
ENHANCEDSTATUSCODES |5.2.6 |T| |x| | | |
RET |5.3.2 |T| |x| | | |
ENVID |5.3.3 |T| | |x| | |
NOTIFY |5.4.1 |T|x| | | | |
ORCPT |5.4.2 |T| | |x| | |
| | | | | | | |
ESMTP-SMTP Downgrading | | | | | | | |
send delivery report upon downgrade |
| | | | | | | |
Directory Address Resolution | | | | | | | |
provide facility to resolve addresses |6 |C| |x| | | |
use vCards to populate local directory |6 |C| |x| | | |8
use headers to populate local directory |6 |C| | | |x| |
| | | | | | | |
Management Protocols: | | | | | | | |
Network management |8.1 |T| ||x| | |
-------------------------------------------|----------|-|-|-|-|-|-|-
Footnotes:
1. MUST NOT include if all recipients are not known or resolvable.
2. If a sensitive message is received by a system that does not
support sensitivity, then it MUST be returned to the originator
with an appropriate error notification. Also, a received
sensitive message MUST NOT be forwarded to anyone.
3. If the addtional header fields are not understood they MAY be
ignored
4. When binary transport is not available
5. When binary transport is available
6. Other un-profiled contents must only be sent by bilateral
agreement.
7. If the content cannot be presented in some form, the entire
message MUST be returned with a negative delivery status
notification.
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.
To: +19725551212@vm1.mycompany.com
To: +16135551234@VM1.mycompany.com
From: "Parsons, Glenn" <12145551234@VM2.mycompany.com>
Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT)
MIME-Version: 1.0 (Voice 2.0)
Content-type: Multipart/Voice-Message; Version=2.0;
Boundary="MessageBoundary"
Content-Transfer-Encoding: 7bit
Message-ID: 123456789@VM2.mycompany.com
Sensitivity: Private
Importance: High
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Disposition: inline; voice=Originator-Spoken-Name
Content-Language: en-US
Content-ID: part1@VM2-4321
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd
(This is a sample of the base-64 Spoken Name data)
fgdhgddlkgpokpeowrit09==
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Description: Brand X Voice Message
Content-Disposition: inline; voice=Voice-Message; filename=msg1.726
Content-Duration: 25
iIiIiIjMzN3czdze3s7d7fwfHhcvESJVe/4yEhLz8/FOQjVFRERCESL/zqrq
(This is a sample of the base64 message data) zb8tFdLTQt1PXj
u7wjOyRhws+krdns7Rju0t4tLF7cE0K0MxOTOnRW/Pn30c8uHi9==
--MessageBoundary
Content-type: text/directory; charset=us-ascii; profile=vCard
Content-Transfer-Encoding: 7bit
BEGIN:VCARD
N:Parsons;Glenn;;Mr.;
EMAIL;TYPE=INTERNET:+12145551234@VM2.mycompany.com
TEL:+1-217-555-1234
SOUND;TYPE=32KADPCM;ENCODING=URI: CID:<part1@VM2-4321>
REV:19951031T222710Z
VERSION: 3.0
END:VCARD
--MessageBoundary_
The following message is a forwarded single segment voice. Both the
forwarded message and the forwarding message contain VCARDs with
spoken names.
To: +12145551212@vm1.mycompany.com
From: "Vaudreuil, Greg" <+19725552345@VM2.mycompany.com>
Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT)
MIME-Version: 1.0 (Voice 2.0)
Content-type: Multipart/Voice-Message; Version=2.0;
Boundary="MessageBoundary"
Content-Transfer-Encoding: 7bit
Message-ID: ABCD-123456789@VM2.mycompany.com
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Disposition: inline; voice=Originator-Spoken-Name
Content-Language: en-US
Content-ID: part3@VM2-4321
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd
(This is a sample of the base-64 Spoken Name data)
fgdhgd dlkgpokpeowrit09==
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Description: Forwarded Message Annotation
Content-Disposition: inline; voice=Voice-Message
Content-Transfer-Encoding: Base64
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd
(This is the voiced introductory remarks encoded in base64)
jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW
dlkgpokpeowrit09==
--MessageBoundary
Content-type: Message/RFC822
Content-Transfer-Encoding: 7bit
To: +19725552345@VM2.mycompany.com
From: "Parsons, Glenn, W." <+16135551234@VM1.mycompany.com>
Date: Mon, 26 Aug 93 8:23:10 -0500 (EST)
Content-type: Multipart/Voice-Message; Version=2.0;
Boundary="MessageBoundary2"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0 (Voice 2.0)
--MessageBoundary2
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Disposition: inline; voice=Originator-Spoken-Name
Content-Language: en-US
Content-ID: part6@VM2-4321
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd
(This is a sample of the base-64 Spoken Name data) fgdhgd
dlkgpokpeowrit09==
--MessageBoundary2
Content-type: Audio/32KADPCM
Content-Disposition: inline; voice=Voice-Message
Content-Transfer-Encoding: Base64
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd
(This is the original message audio data) fgwersdfmniwrjj
jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW
dlkgpokpeowrit09==
--MessageBoundary2
Content-type: text/directory; charset=us-ascii
Content-Transfer-Encoding: 7bit
BEGIN:VCARD
N:Parsons;Glenn;W;Mr.;
EMAIL;TYPE=INTERNET:+16135551234@VM2.mycompany.com
TEL:+1-613-555-1234
SOUND;TYPE=32KADPCM;ENCODING=URI: CID:<part6@VM2-4321>
REV:19951031T222710Z
END:VCARD
--MessageBoundary2--
--MessageBoundary
Content-type: text/directory; charset=us-ascii
Content-Transfer-Encoding: 7bit
BEGIN:VCARD
N:Vaudreuil;Greg;;Mr.;
SOUND;TYPE=32KADPCM;ENCODING=URI: CID:<part3@VM2-4321>
EMAIL;TYPE=INTERNET,VPIM:+19725552345@VM2.mycompany.com
TEL:+1-972-555-2345
REV:19951031T222710Z
VERSION: 3.0
END:VCARD
--MessageBoundary--
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>
Message-Id: <199407072116.RAA14128@vm1.company.com>
Subject: Returned voice message
To: 2175552345@VM2.mycompany.com
MIME-Version: 1.0 (Voice 2.0)
Content-Type: multipart/report; report-type=delivery-status;
boundary="RAA14128.773615765/VM1.COMPANY.COM"
--RAA14128.773615765/VM1.COMPANY.COM
Content-type: Audio/32KADPCM