tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 3801

 
 
 

Voice Profile for Internet Mail - version 2 (VPIMv2)

Part 2 of 2, p. 27 to 55
Prev RFC Part

 


prevText      Top      Up      ToC       Page 27 
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

Top      Up      ToC       Page 28 
   traditionally been transported by encoding the messages into a 7-bit
   text-like form.  [ESMTP] formalized an extension mechanism for SMTP,
   and subsequent RFCs have defined 8-bit text networking, command
   streaming, binary networking, and extensions to permit the
   declaration of message size for the efficient transmission of large
   messages such as multi-minute voice mail.

   The following sections list ESMTP commands, keywords, and parameters
   that are required and those that are optional for conformance to this
   profile.

5.1.  Base SMTP Protocol

   A conforming system MUST implement all mandatory SMTP and ESMTP
   commands.  Any defined optional command or parameter MAY be
   supported.

5.2.  SMTP Service Extensions

   VPIM utilizes a number of SMTP Service Extensions to provide full-
   featured voice messaging service.  The following extensions are
   profiled for use with VPIM:

5.2.1.  DSN Extension

   The DSN extension defines a mechanism which allows an SMTP client to
   specify (a) DSN's should be generated under certain conditions, (b)
   whether such DSN's should return the contents of the message, and (c)
   additional information, to be returned with a DSN, that allows the
   sender to identify both the recipient(s) for which the DSN was
   issued, and the transaction in which the original message was sent.

   The DSN extension MUST be supported by VPIM conforming
   implementations.

   In addition, beyond the requirements of [DRPT], conforming
   implementations MUST support NOTIFY parameter on the RCPT command to
   allow indication of when the originator requests a notification.  The
   RET parameter SHOULD be supported to return the original message with
   the notification.  Parameters ORCPT and ENVID MAY also be supported.
   From: [DRPT]

5.2.2.  SIZE Extension

   The SIZE extension defines a mechanism whereby an SMTP client and
   server may interact to give the server an opportunity to decline to
   accept a message (perhaps temporarily) based on the client's estimate
   of the message size.  From: [SIZE]

Top      Up      ToC       Page 29 
   The SIZE extension MUST be supported by VPIM-compliant
   implementations.

5.2.3.  ENHANCEDSTATUSCODES Extension

   The ENHANCEDSTATUSCODES extension defines a mechanism whereby an SMTP
   server augments its responses with the enhanced mail system status
   codes defined in [CODES].  These codes can then be used to provide
   more informative explanations of error conditions.  From: [STATUS]

   The ENHANCEDSTATUSCODES extension SHOULD be supported by VPIM-
   compliant implementations.

5.2.4.  PIPELINING Extension

   The PIPELINING extension defines a mechanism whereby an SMTP server
   can indicate the extent of its ability to accept multiple commands in
   a single TCP send operation.  Using a single TCP send operation for
   multiple commands can improve SMTP performance significantly.  From
   [PIPE]

   The PIPELINING extension SHOULD be supported by VPIM-compliant
   implementations.

5.2.5.  CHUNKING Extension

   The CHUNKING extension defines a mechanism that enables an SMTP
   client and server to negotiate the use of the message data transfer
   command "BDAT" (in alternative to the DATA command) for efficiently
   sending large MIME messages.  From: [BINARY]

   The CHUNKING extension MAY be supported by VPIM-compliant
   implementations.

5.2.6.  BINARYMIME Extension

   The BINARYMIME extension defines a mechanism that enables an SMTP
   client and server to negotiate the transfer of unencoded binary
   message data utilizing the BDAT command.  From: [BINARY]

   The BINARYMIME extension MAY be supported by VPIM-compliant
   implementations.  Note that [BINARY] specifies that if BINARYMIME is
   to be supported, then CHUNKING has to be supported by definition.

Top      Up      ToC       Page 30 
5.3.  ESMTP - SMTP Downgrading

   The SMTP extensions suggested or required for conformance to VPIM
   fall into two categories.  The first category includes features that
   increase the efficiency of the transport system such as SIZE,
   BINARYMIME, and PIPELINING.  In the event of a downgrade to a less-
   functional transport system, these features can be dropped with no
   functional change to the sender or recipient.

   The second category of features is transport extensions in support of
   new functions.  DSN and ENHANCEDSTATUSCODES provide essential
   improvements in the handling of delivery status notifications to
   bring email to the level of reliability expected of Voice Mail.  To
   ensure a consistent level of service across an intranet or the global
   Internet, it is essential that VPIM-conforming ESMTP support the DSN
   extension at all hops between a VPIM originating system and the
   recipient system.  In the situation where a "downgrade" is
   unavoidable a relay hop may be forced (by the next hop) to forward a
   VPIM message without the ESMTP request for delivery status
   notification.  It is RECOMMENDED that the downgrading system should
   continue to attempt to deliver the message, but MUST send an
   appropriate delivery status notification to the originator, e.g., the
   message left an ESMTP host and was sent relayed to a non-DSN-aware
   destination, and this may be the last DSN received.

6.  Directory Address Resolution

   It is the responsibility of a VPIM system to provide the fully-
   qualified domain name (FQDN) of the recipient based on the address
   entered by the user (if the entered address is not already a FQDN).
   This would typically be an issue on systems that offer only a
   telephone user interface.  The mapping of the dialed target number to
   a routable FQDN address, allowing delivery to the destination system,
   can be accomplished through implementation-specific means.

   To facilitate a local cache, an implementation may wish to populate
   local directories with the first and last names, as well as the
   senders' spoken name information extracted from received messages.
   Addresses or names parsed from the header fields of VPIM messages MAY
   be used to populate directories.

7.  Management Protocols

   The Internet protocols provide a mechanism for the management of
   messaging systems, from the management of the physical network
   through the management of the message queues.  SNMP SHOULD be
   supported on a VPIM-conforming machine.

Top      Up      ToC       Page 31 
7.1.  Network Management

   The digital interface to the VM and the TCP/IP protocols MAY be
   managed. MIB II MAY be implemented to provide basic statistics and
   reporting of TCP and IP protocol performance [MIB II].

8.  Conformance Requirements

   VPIM is a messaging application that will be supported in several
   environments and be supported on differing devices.  These
   environments include traditional voice processing systems, desktop
   voice messaging systems, store-and-forward relays, and protocol
   translation gateways.

   In order to accommodate all environments, this document defines two
   areas of conformance: transport and content.

   Transport-conformant systems will pass VPIM messages in a store-and-
   forward manner with assured delivery notifications and without the
   loss of information.  It is expected that most store-and-forward
   Internet mail-based messaging systems will be VPIM transport-
   conformant.

   Content-conformant systems will generate and interpret VPIM messages.
   Conformance in the generation of VPIM messages indicates that the
   restrictions of this profile are honored.  Only contents specified in
   this profile or extensions agreed to by bilateral agreement may be
   sent. Conformance in the interpretation of VPIM messages indicates
   that all VPIM content types and constructs can be received;  that all
   mandatory VPIM content types can be decoded and presented to the
   recipient in an appropriate manner; and that any unrenderable
   contents result in the appropriate notification.

   A summary of the conformance requirements is contained in Appendix A.

   VPIM end systems are expected to be both transport- and content-
   conformant.  Voice messaging systems and protocol conversion gateways
   are considered end systems.

   Relay systems are expected to be transport-conformant in order to
   receive and send conforming messages.  However, they must also create
   VPIM-conforming delivery status notifications in the event of
   delivery problems.

   Desktop Email clients that support VPIM are expected to be content-
   conformant.  Desktop email clients use various protocols and API's
   for exchanging messages with the local message store and message
   transport system.  While these clients may benefit from VPIM

Top      Up      ToC       Page 32 
   transport capabilities, specific client-server requirements are out-
   of-scope for this document.

9.  Security Considerations

9.1.  General Directive

   This document is a profile of existing Internet mail protocols.  To
   maintain interoperability with Internet mail, any security to be
   provided should be part of the Internet security infrastructure,
   rather than a new mechanism or some other mechanism outside of the
   Internet infrastructure.

9.2.  Threats and Problems

   Both Internet mail and voice messaging have their own set of threats
   and countermeasures.  As such, this specification does not create any
   security issues not already existing in the profiled Internet mail
   and voice mail protocols themselves.  This section attends only to
   the set of additional threats that ensue from integrating the two
   services.

9.2.1.  Spoofed sender

   The actual sender of the voice message might not be the same as that
   specified in the "Sender:" or "From:" message header fields or the
   MAIL FROM address from the SMTP envelope.  In a tightly constrained
   environment, sufficient physical and software controls may be able to
   ensure prevention of this problem.  In addition, the recognition of
   the sender's voice may provide confidence of the sender's identity
   irrespective of that specified in "Sender:" or "From:".  It should be
   recognized that SMTP implementations do not provide inherent
   authentication of the senders of messages, nor are sites under
   obligation to provide such authentication.

9.2.2.  Unsolicited voice mail

   Assigning an Internet mail address to a voice mailbox opens the
   possibility of receiving unsolicited messages (either text or voice
   mail).  Traditionally, voice mail systems operated in closed
   environments and were not susceptible to unknown senders.  Voice mail
   users have a higher expectation of mailbox privacy and may consider
   such messages as a security breach.  Many Internet mail systems are
   choosing to block all messages from unknown sources in an attempt to
   curb this problem.

Top      Up      ToC       Page 33 
9.2.3.  Message disclosure

   Users of voice messaging systems have an expectation of a level of
   message privacy that is higher than the level provided by Internet
   mail without security enhancements.  This expectation of privacy by
   users SHOULD be preserved as much as possible.

9.3.  Security Techniques

   Sufficient physical and software control may be acceptable in
   constrained environments.  Further, the profile specified in this
   document does not in any way preclude the use of any Internet object
   or channel security protocol to encrypt, authenticate, or non-
   repudiate the messages.

10.  Normative References

   [8BIT]    Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
             Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
             RFC 1652, July 1994.

   [ADPCM]   Vaudreuil, G. and G. Parsons, "Toll Quality Voice - 32
             kbit/s Adaptive Differential Pulse Code Modulation (ADPCM)
             MIME Sub-type Registration", RFC 3802, June 2004.

   [AMIS-A]  Audio Messaging Interchange Specifications (AMIS) - Analog
             Protocol Version 1, Issue 2, February 1992.

   [AMIS-D]  Audio Messaging Interchange Specifications (AMIS) - Digital
             Protocol Version 1, Issue 3, August 1993.

   [BINARY]  Vaudreuil, G., "SMTP Service Extensions for Transmission of
             Large and Binary MIME Messages", RFC 3030, December 2000.

   [CODES]   Vaudreuil, G. "Enhanced Mail System Status Codes", RFC
             1893, January 1996.

   [MIMEDIR] Dawson, F., Howes, T. and M. Smith, "A MIME Content-Type
             for Directory Information", RFC 2425, September 1998.

   [DISP]    Troost, R. and S. Dorner, "Communicating Presentation
             Information in Internet Messages:  The Content-Disposition
             Header", RFC 2183, August 1997.

   [DNS1]    Mockapetris, P., "Domain names - implementation and
             specification", RFC 1035, November 1987.

Top      Up      ToC       Page 34 
   [DNS2]    Mockapetris, P., "Domain names - concepts and facilities",
             RFC 1034, November 1987.

   [DRPT]    Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
             Extension for Delivery Status Notifications (DSNs)", RFC
             3461, January 2003.

   [DSN]     Moore, K. and G. Vaudreuil, "An Extensible Message Format
             for Delivery Status Notifications", RFC 3464, January 2003.

   [DUR]     Parsons, G. and G. Vaudreuil, "Content Duration MIME Header
             Definition", RFC 3803, June 2004.

   [E164]    CCITT Recommendation E.164 (1991), Telephone Network and
             ISDN Operation, Numbering, Routing and  Mobile Service -
             Numbering Plan for the ISDN Era.

   [ESMTP]   Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
             April 2001.

   [G726]    CCITT Recommendation G.726 (1990), General Aspects of
             Digital Transmission Systems, Terminal Equipment - 40, 32,
             24,16 kbit/s Adaptive Differential Pulse Code Modulation
             (ADPCM).

   [HOSTREQ] Braden, R., "Requirements for Internet Hosts -- Application
             and Support", STD 3, RFC 1123, October 1989.

   [LANG]    Alvestrand, H., "Tags for the Identification of Languages",
             BCP 47, RFC 3066, January 2001.

   [MDN]     Hansen, T., Ed. and G. Vaudreuil, Ed., "Message Disposition
             Notification", RFC 3798, May 2004.

   [MIB II]  Rose, M., "Management Information Base for Network
             Management of TCP/IP-based internets:  MIB-II", RFC 1213,
             March 1991.

   [MIME1]   Freed, N. and N. Borenstein,  "Multipurpose Internet Mail
             Extensions (MIME) Part One: Format of Internet Message
             Bodies", RFC 2045, November 1996.

   [MIME2]   Freed, N.  and N. Borenstein,  "Multipurpose Internet Mail
             Extensions (MIME) Part Two: Media Types ", RFC 2046,
             November 1996.

Top      Up      ToC       Page 35 
   [MIME3]   Moore, K., "Multipurpose Internet Mail Extensions (MIME)
             Part Three: Message Header Extensions for Non-ASCII Text ",
             RFC 2047, November 1996.

   [MIME4]   Freed, N., Klensin, J. and J. Postel,  "Multipurpose
             Internet Mail Extensions (MIME) Part Four: Registration
             Procedures", RFC 2048, November 1996.

   [MIME5]   Freed, N. and N. Borenstein,  "Multipurpose Internet Mail
             Extensions (MIME) Part Five: Conformance Criteria and
             Examples ", RFC 2049, November 1996.

   [PIPE]    Freed, N.and A. Cargille, "SMTP Service Extension for
             Command Pipelining" STD 60, RFC 2920, September 2000.

   [REPORT]  Vaudreuil, G., "The Multipart/Report Content Type for the
             Reporting of Mail System Administrative Messages", RFC
             3462, January 2003.

   [REQ]     Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC822]  Crocker, D., "Standard for the Format of ARPA Internet Text
             Messages", STD 11, RFC 822, August 1982.

   [SIZE]    Klensin, J., Freed, N. and K. Moore, "SMTP Service
             Extensions for Message Size Declaration" STD 10, RFC 1870,
             November 1995.

   [STATUS]  Freed, N., "SMTP Service Extension for Returning Enhanced
             Error Codes", RFC 2034, October 1996.

   [TIFF-F]  Parsons, G. and J. Rafferty, "Tag Image File Format:
             Application F", RFC 2306, March 1998.

   [TIFFREG] Parsons, G.,  Rafferty, J. and S. Zilles, "Tag Image File
             Format: image/tiff - MIME sub-type registration", RFC 2302,
             March 1998.

   [V-MSG]   Vaudreuil, G. and G. Parsons, "VPIM Voice Message MIME
             Sub-type Registration", RFC 2423, September 1998.

   [VCARD]   Dawson, F. and T. Howes, "vCard MIME Directory Profile" RFC
             2426, September 1998.

   [VPIM1]   Vaudreuil, G., "Voice Profile for Internet Mail", RFC 1911,
             February 1996.

Top      Up      ToC       Page 36 
   [VPIM2]   Vaudreuil, G. and G. Parsons, "Voice Profile for Internet
             Mail, Version 2", RFC 2421, September 1998.

   [X.400]   CCITT/ISO, "CCITT Recommendations X.400/ ISO/IEC 10021-1,
             Message Handling: System and Service Overview", December
             1988.

11.  Acknowledgments

   The authors would like to offer a special thanks to the Electronic
   Messaging Association (EMA), especially the members of the Voice
   Messaging Committee, and the IETF VPIM Work Group, for their support
   of the VPIM specification and the efforts they have made to ensure
   its success.

Top      Up      ToC       Page 37 
12.  Appendix A - VPIM Requirements Summary

   The following table summarizes the profile of VPIM version 2 detailed
   in this document.  Since in many cases it is not possible to simplify
   the qualifications for supporting each feature this appendix is
   informative. The reader is recommended to read the complete
   explanation of each feature in the referenced section.  The text in
   the previous sections shall be deemed authoritative if any item in
   this table is ambiguous.

   The conformance table is separated into various columns:

      Feature - name of protocol feature (note that the indenting
                indicates a hierarchy of conformance, i.e., the
                conformance of a lower feature is only relevant if there
                is conformance to the higher feature)

      Section - reference section in main text of this document

      Area - conformance area to which each feature applies:
           C - content
           T - transport


   Status - whether the feature is mandatory, optional, or prohibited.
   The key words used in this table are to be interpreted as described
   in [REQ], though the following list gives a quick overview of the
   different degrees of feature conformance:

        Must         - mandatory
        Should       - required in the absence of a compelling
                       need to omit.
        May          - optional
        Should not   - prohibited in the absence of a compelling
                       need.
        Must not     - prohibited

   Footnote - special comment about conformance for a particular feature

Top      Up      ToC       Page 38 
                           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| | | |
     Numbers in mailbox IDs follow E.164      |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:                     |          | | | | | | |
     Sending outbound messages                |          | | | | | | |
       From                                   |4.2.1     |C|x| | | | |
         Addition of text name                |4.2.1     |C| |x| | | |
         Same value as MAIL FROM              |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.7       |C| |x| | | |
       Other Headers                          |4.2       |C| | |x| | |
                                              |          | | | | | | |

Top      Up      ToC       Page 39 
                                              |          | | | | |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
   -------------------------------------------|----------|-|-|-|-|-|-|-
     Receiving 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| | |
         MDN requested                        |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.7       |C| |x| | | |
       Other Headers                          |4.2       |C|x| | | | |3
                                              |          | | | | | | |
   Message Content Encoding:                  |          | | | | | | |
     Sending outbound audio/fax contents      |          | | | | | | |
       7BIT                                   |4.2.12    |C| | | | |x|
       8BIT                                   |4.2.12    |C| | | | |x|
       Quoted Printable                       |4.2.12    |C| | | | |x|
       Base64                                 |4.2.12    |C|x| | | | |4
       Binary                                 |4.2.12    |C| |x| | | |5
     Receiving inbound message contents       |          | | | | | | |
       7BIT                                   |4.2.12    |C|x| | | | |
       8BIT                                   |4.2.12    |C|x| | | | |
       Quoted Printable                       |4.2.12    |C|x| | | | |
       Base64                                 |4.2.12    |C|x| | | | |
       Binary                                 |4.2.12    |C|x| | | | |5
                                              |          | | | | | | |

Top      Up      ToC       Page 40 
                                                         | | | | |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:                     |          | | | | | | |
     Sending outbound messages                |          | | | | | | |
       Multipart/Voice-Message                |4.4.1     |C|x| | | | |
         Message/RFC822                       |4.4.2     |C| |x| | | |
         Audio/32KADPCM                       |4.4.3     |C|x| | | | |
           Content-Description                |4.3.1     |C| | |x| | |
           Content-Disposition                |4.3.2     |C|x| | | | |
           Content-Duration                   |4.3.3     |C| | |x| | |
           Content-Language                   |4.3.4     |C| | |x| | |
         Image/TIFF; application=faxbw        |4.4.4     |C|x| | | | |7
         Text/Directory                       |4.5.2     |C| | | |x| |9
         Text/plain                           |4.5.4     |C| | | |x| |
         Audio/* or Image/* (other encodings) |4.5.3     |C| | | |x| |
         Other contents                       |4.5       |C| | | | |x|
       Multipart/Mixed                        |4.5.1     |C| | |x| | |
       Text/plain                             |4.5.4     |C| | |x| | |
       Multipart/Report                       |4.6, 4.7  |C|x| | | | |
          human-readable part is voice        |4.6, 4.7  |C| |x| | | |
          human-readable part is text         |4.6, 4.7  |C| | |x| | |
          Message/Delivery-Status             |4.6       |C|x| | | | |
          Message/Disposition-Notification    |4.7       |C| |x| | | |
       Other contents                         |4.5       |C| | | |x| |6

     Receiving in inbound messages            |          | | | | | | |
       Multipart/Voice-Message                |4.4.1     |C|x| | | | |
         Message/RFC822                       |4.4.2     |C|x| | | | |
         Audio/32KADPCM                       |4.4.3     |C|x| | | | |
           Content-Description                |4.3.1     |C| | |x| | |
           Content-Disposition                |4.3.2     |C| |x| | | |
           Content-Duration                   |4.3.3     |C| | |x| | |
           Content-Language                   |4.3.4     |C| | |x| | |
         Image/TIFF; application=faxbw        |4.4.4     |C| |x| | | |8
         Text/Directory                       |4.5.2     |C|x| | | | |9
         Text/plain                           |4.5.4     |C| | |x| | |
         Audio/* or Image/* (other encodings) |4.5.3     |C| | |x| | |
         Other contents                       |4.5       |C| | |x| | |
       Multipart/Mixed                        |4.5.1     |C| | |x| | |

Top      Up      ToC       Page 41 
                                             |           | | | | |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
   ------------------------------------------|-----------|-|-|-|-|-|-|-
                                             |           | | | | | | |
      Text/plain                             |4.5.4      |C|x| | | | |
      Multipart/Report                       |4.6, 4.7   |C|x| | | | |
        human-readable part is voice         |4.6, 4.7   |C|x| | | | |
        human-readable part is text          |4.6, 4.7   |C|x| | | | |
        Message/Delivery-Status              |4.6        |C|x| | | | |
        Message/Disposition-Notification     |4.7        |C| |x| | | |
      Other contents                         |4.5        |C| | |x| | |6
                                             |           | | | | | | |
     Forwarded Messages                      |           | | | | | | |
       use Message/RFC822 construct          |4.8        |C| |x| | | |
       simulate headers if none available    |4.8        |C| |x| | | |
                                             |           | | | | | | |
     Reply Messages                          |4.9        |C|x| | | | |
       send to Reply-To, else From address   |4.2.8      |C| | |x| | |
       send to non-mail-user                 |4.9        |C| | | |x| |
                                             |           | | | | | | |
     Notifications                           |           | | | | | | |
       use Multipart/Report format           |4.6, 4.7   |C|x| | | | |
       always send error on non-delivery     |4.6        |C|x| | | | |
       send error messages to return-path    |4.2.6      |C|x| | | | |
                                             |           | | | | | | |
   Message Transport Protocol:               |           | | | | | | |
     Base ESMTP Commands                     |           | | | | | | |
       HELO                                  |5.1        |T|x| | | | |
       MAIL FROM                             |5.1        |T|x| | | | |
       RCPT TO                               |5.1        |T|x| | | | |
       DATA                                  |5.1        |T|x| | | | |
       TURN                                  |5.1        |T| | | | |x|
       QUIT                                  |5.1        |T|x| | | | |
       RSET                                  |5.1        |T|x| | | | |
       VRFY                                  |5.1        |T| | |x| | |
       EHLO                                  |5.1        |T|x| | | | |
       BDAT                                  |5.1        |T| | |x| | |5

Top      Up      ToC       Page 42 
                                                         | | | | |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              |          | | | | | | |
       DSN                                    |5.2.1     |T|x| | | | |
         NOTIFY                               |5.2.1     |T|x| | | | |
         RET                                  |5.2.1     |T| |x| | | |
         ENVID                                |5.2.1     |T| | |x| | |
         ORCPT                                |5.2.1     |T| | |x| | |
       SIZE                                   |5.2.2     |T|x| | | | |
       ENHANCEDSTATUSCODES                    |5.2.3     |T| |x| | | |
       PIPELINING                             |5.2.4     |T| |x| | | |
       CHUNKING                               |5.2.5     |T| | |x| | |
       BINARYMIME                             |5.2.6     |T| | |x| | |
                                              |          | | | | | | |
     ESMTP-SMTP Downgrading                   |          | | | | | | |
       send delivery report upon downgrade    |5.3       |T|x| | | | |
                                              |          | | | | | | |
   Directory Address Resolution               |          | | | | | | |
     provide facility to resolve addresses    |6         |C| |x| | | |
     use headers to populate local directory  |6         |C| | |x| | |
                                              |          | | | | | | |
   Management Protocols:                      |          | | | | | | |
     Network management                       |7.1       |T| | |x| | |
   -------------------------------------------|----------|-|-|-|-|-|-|-

   Footnotes:

   1.  SHOULD leave blank 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 additional header fields are not understood they MAY
       be ignored.
   4.  When binary transport is not available.
   5.  When binary transport is available.

Top      Up      ToC       Page 43 
   6.  Other un-profiled contents MUST only be sent by bilateral
       agreement.
   7.  If fax is supported.
   8.  If the fax content cannot be presented it MAY be dropped.
   9.  Handling of a vCard in text/directory is no longer defined.

13.  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, spoken
   subject 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

Top      Up      ToC       Page 44 
--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-Disposition: inline; voice=Spoken-Subject
Content-Language: en-US
Content-ID: part2@VM2-4321

glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd
(This is a sample of the base-64 Spoken Subject 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- -                         -                         -

The following message is a forwarded single segment voice.  Both the
forwarded message and the forwarding message contain the senders 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

Top      Up      ToC       Page 45 
      --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==

Top      Up      ToC       Page 46 
      --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--

      --MessageBoundary--

Top      Up      ToC       Page 47 
   The following example is for a DSN sent to the sender of a message 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
      Content-Type: multipart/report; report-type=delivery-status;
        boundary="RAA14128.773615765/VM1.COMPANY.COM"

      --RAA14128.773615765/VM1.COMPANY.COM
      Content-type: Audio/32KADPCM
      Content-Description: Spoken Delivery Status Notification
      Content-Disposition: inline; voice= Voice-Message-Notification
      Content-Transfer-Encoding: Base64

      glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadadffsssddasdasd
      (This is a voiced description of the error in base64)
      jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gdffkjpokfgW
      dlkgpokpeowrit09==

      --RAA14128.773615765/VM1.COMPANY.COM
      Content-type: Message/Delivery-Status

      Reporting-MTA: dns; vm1.company.com

      Original-Recipient: rfc822; 2145551234@VM1.mycompany.com
      Final-Recipient: rfc822; 2145551234@VM1.mycompany.com
      Action: failed
      Status: 5.1.1 (User does not exist)
      Diagnostic-Code: smtp; 550 Mailbox not found
      Last-Attempt-Date: Thu, 7 Jul 1994 17:15:49 -0400

Top      Up      ToC       Page 48 
      --RAA14128.773615765/VM1.COMPANY.COM
      content-type: Message/RFC822

      [original VPIM message goes here]

      --RAA14128.773615765/VM1.COMPANY.COM--

   The following example is for an MDN sent to the original sender for a
   message that has been played.  This delivered VPIM message was
   received by a corporate gateway and relayed to a unified mailbox.

Date: Thu, 7 Jul 1994 17:16:05 -0400
From: "Greg Vaudreuil" <22722@vm.company.com>
Message-ID: <199407072116.RAA14128@exchange.company.com>
Subject: Voice message played
To: 2175552345@VM2.mycompany.com
MIME-Version: 1.0
Content-Type: multipart/report;
        Report-type=disposition-notification;
        Boundary="RAA14128.773615765/EXCHANGE.COMPANY.COM"

--RAA14128.773615765/EXCHANGE.COMPANY.COM
Content-type: Audio/32KADPCM
Content-Description: Spoken Disposition Notification
Content-Disposition: inline; voice= Voice-Message-Notification
Content-Transfer-Encoding: Base64

glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadadffsssddasdasd
(Voiced description of the disposition action in base64)
jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gdffkjpokfgW
dlkgpokpeowrit09==

--RAA14128.773615765/EXCHANGE.COMPANY.COM
Content-type: Message/Disposition-Notification

Reporting-UA: gregs-laptop.dallas.company.com (Unified FooMail 3.0)

Original-Recipient: rfc822;22722@vm.company.com
Final-Recipient: rfc822;Greg.Vaudreuil@foomail.company.com
Original-Message-ID: <199509192301.12345@vm2.mycompany.com>
Disposition: manual-action/MDN-sent-automatically; displayed

--RAA14128.773615765/EXCHANGE.COMPANY.COM
Content-type: Message/RFC822

[original VPIM message goes here]

--RAA14128.773615765/EXCHANGE.COMPANY.COM--

Top      Up      ToC       Page 49 
14.  Appendix C - Example Error Voice Processing Error Codes

   The following common voice processing errors and their corresponding
   status codes are given as examples.  The text after the error codes
   is intended only for reference to describe the error code.
   Implementations should provide implementation-specific informative
   comments after the error code rather than the text below.

      Error condition                 RFC 1893 Error codes
      -----------------------------   --------------------------------

      Analog delivery failed          4.4.1 Persistent connection error
      because remote system is busy         - busy

      Analog delivery failed          4.4.1 Persistent protocol error
      because remote system is              - no answer from host
      ring-no-answer

      Remote system did not answer    5.5.5 Permanent protocol error
      AMIS-Analog handshake ("D" in         - wrong version
      response to "C" at connect
      time)

      Mailbox does not exist          5.1.1 Permanent mailbox error
                                            - does not exist

      Mailbox full or over quota      4.2.2 Persistent mailbox error
                                            - full

      Disk full                       4.3.1 Persistent system error
                                            - full

      Command out of sequence         5.5.1 Permanent protocol error
                                            - invalid command

      Frame Error                     5.5.2 Permanent protocol error
                                                       - syntax error

      Mailbox does not support FAX    5.6.1 Permanent media error
                                            - not supported

      Mailbox does not support TEXT   5.6.1 Permanent media error
                                            - not supported

      Sender is not authorized        5.7.1 Permanent security error
                                            - sender not authorized

Top      Up      ToC       Page 50 
      Message marked private, but     5.3.3 Permanent system error
      system is not private capable         - not feature capable

15.  Appendix D - Example Voice Processing Disposition Types

   The following common voice processing disposition conditions and
   their corresponding MDN Disposition (which contains the disposition
   mode, type and modifier, if applicable) are given as examples.
   Implementers should refer to [MDN] for a full description of the
   format of message disposition notifications.

Notification event               MDN Disposition mode, type & modifier
------------------------------   ------------------------------------

Message played by recipient,    manual-action/MDN-sent-automatically;
receipt automatically returned  displayed

Message deleted from mailbox    manual-action/MDN-sent-automatically;
by user without listening       deleted

Message cleared when mailbox    manual-action/MDN-sent-automatically;
deleted by admin                deleted/mailbox-terminated

Message automatically deleted   automatic-action/
when older than administrator   MDN-sent-automatically; deleted/
set threshold                   expired

Message processed, however      manual-action/MDN-sent-automatically;
audio encoding unknown -        processed/error
unable to play to user          Error: unknown audio encoding

16.  Appendix E - IANA Registrations

   There are no changes to the registration per [DISP] of the voice
   content disposition parameter defined in the earlier VPIM V2
   document, RFC 2421.  There are no changes to the registration per
   [MIME4] of the Multipart/voice-message content type defines in the
   earlier VPIM v2 document, RFC 2423.

   Both are presented here for information.

Top      Up      ToC       Page 51 
16.1.  Voice Content-Disposition Parameter Definition

   To: IANA@IANA.ORG

   Subject: Registration of new Content-Disposition parameter

   Content-Disposition parameter name: voice

   Allowable values for this parameter:

         Voice-Message - the primary voice message,
         Voice-Message-Notification - a spoken delivery notification
           or spoken disposition notification,
         Originator-Spoken-Name - the spoken name of the originator,
         Recipient-Spoken-Name - the spoken name of the recipient if
           available to the originator and present if there is ONLY one
           recipient,
         Spoken-Subject- the spoken subject of the message, typically
           spoken by the originator

   Description:

   In order to distinguish between the various types of audio contents
   in a VPIM voice message a new disposition parameter "voice" is
   defined with the preceding values to be used as appropriate.  Note
   that there SHOULD only be one instance of each of these types of
   audio contents per message level.  Additional instances of a given
   type (i.e., parameter value) may occur within an attached forwarded
   voice message.

16.2.  Multipart/Voice-Message MIME Media Type Definition

   To: ietf-types@iana.org
   Subject: Registration of MIME media type
            Multipart/voice-message

   MIME media type name: multipart

   MIME subtype name: voice-message

   Required parameters: boundary, version

      The use of boundary is defined in [MIME2]

Top      Up      ToC       Page 52 
      The version parameter that contains the value "2.0" if
      enclosed content conforms to [VPIM2R2].  The absence of this
      parameter indicates conformance to the previous version
      defined in RFC 1911 [VPIM1].

   Optional parameters: none

   Encoding considerations: 7bit, 8bit or Binary

   Security considerations:

      This definition identifies the content as being a voice
      message.  In some environments (though likely not the
      majority), the loss of the anonymity of the content may be a
      security issue.

   Interoperability considerations:

      Systems developed to conform with [VPIM1] may not conform to
      this registration.  Specifically, the required version will
      likely be absent, in this case the recipient system should
      still be able to accept the message and will be able to
      handle the content.  The VPIM v1 positional identification,
      however, would likely be lost.

   Published specification:
      This document

      Applications that use this media type:

      Primarily voice messaging

      Additional information:

      Magic number(s): none
      File extension(s): .VPM
      Macintosh File Type Code(s): VPIM

   Person & email address to contact for further information:

      Glenn W. Parsons
      gparsons@nortelnetworks.com

      Gregory M. Vaudreuil
      gregv@ieee.org

   Intended usage: COMMON

Top      Up      ToC       Page 53 
   Author/Change controller:

      Glenn W. Parsons & Gregory M. Vaudreuil

17.  Appendix F - Change History: RFC 2421 (VPIM V2) to this Document

   The updated profile in this document is based on the implementation
   and operational deployment experience of several vendors.  The
   changes are categorized as general, content, transport and
   conformance.  They are summarized below:

   1. General

      - Various and substantial editorial updates to improve
        readability.

      - Separated send rules from receive rules to aid clarity.

      - Clarified the behavior upon reception of unrecognized content
        types expected with the interworking between voice and unified
        messaging systems.  (E.g., Unsupported non-audio contents should
        be discarded to deliver the audio message.)

      - Reworked the sensitivity requirements to align them with X.400.
        Eliminated dependencies upon the MIXER documents.

      - Reorganized the content-type descriptions for clarity

   2. Content

      - Changed handling of received lines by a gateway to SHOULD NOT
        delete in a gateway.  In gateways to systems such as AMIS, it is
        not possible to preserve this information.  It is intended that
        such systems be able to claim conformance.

      - Eliminated the vCard as a supported VPIM V2 content type.

      - Merged in text from RFC 2423 (Multipart/voice-message)

   3. Transport

      - None

   4. Conformance

      - Aligned the table of Appendix A to the requirements in the text.

Top      Up      ToC       Page 54 
18.  Authors' Addresses

   Gregory M. Vaudreuil
   Lucent Technologies
   7291 Williamson Rd
   Dallas, TX  75214
   United States

   EMail: gregv@ieee.org


   Glenn W. Parsons
   Nortel Networks
   P.O. Box 3511, Station C
   Ottawa, ON  K1Y 4H7
   Canada

   Phone: +1-613-763-7582
   Fax: +1-613-763-2697
   EMail: GParsons@NortelNetworks.com

Top      Up      ToC       Page 55 
19.  Full Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.