tech-invite   World Map     

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

RFC 2421

 
 
 

Voice Profile for Internet Mail - version 2

Part 2 of 2, p. 30 to 56
Prev RFC Part

 


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

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

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

Top      Up      ToC       Page 33 
   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", RFC 2422,
           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", RFC 1830, October 1995.

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

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

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

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

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

   [DRPT] Moore, K., "SMTP Service Extensions for Delivery Status
          Notifications", RFC 1891, January 1996.

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

   [DUR] Vaudreuil, G., and G. Parsons, "Content Duration MIME Header
         Definition", RFC 2424, September 1998.

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

   [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
           Crocker, "SMTP Service Extensions", RFC 1869, November 1995.

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

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

   [LANG] Alvestrand, H., "Tags for the Identification of Languages",
          RFC 1766, March 1995.

   [MDN] Fajman, R., "An Extensible Message Format for Message
         Disposition Notifications", RFC 2298, March 1998.

   [MIB II] Rose, M., "Management Information Base for Network
            Management of TCP/IP-based internets: MIB-II", RFC 1158, May
            1990.

   [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.

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

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

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

   [PIPE] Freed, N., and A. Cargille, "SMTP Service Extension for
          Command Pipelining", RFC 1854, October 1995.

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

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

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

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

   [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
          August 1982.

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

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

   [TIFFREG] Parsons, G., Rafferty, J., and S. Zilles, "Tag Image File
             Format: image/tiff - MIME sub-type registraion", RFC 2302,
             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.

   [X.400] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO
           10021 and RFC 822", RFC 1327, May 1992.

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

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

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| | | |
    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| | |
                                             |          | | | | | | |

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

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:                     |          | | | | | | |
    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

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

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
  ------------------------------------------|-----------|-|-|-|-|-|-|-
                                            |           | | | | | | |
     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

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

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

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

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

Top      Up      ToC       Page 47 
    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.;

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

    --RAA14128.773615765/VM1.COMPANY.COM
    content-type: message/rfc822

    [original VPIM message goes here]

Top      Up      ToC       Page 49 
    --RAA14128.773615765/VM1.COMPANY.COM--

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

    Date: Thu, 7 Jul 1994 17:16:05 -0400
    From: "Greg Vaudreuil" <22722@vm.company.com>
    Message-Id: <199407072116.RAA14128@exchange.company.com>
    Subject: Voice message played
    To: 2175552345@VM2.mycompany.com
    MIME-Version: 1.0 (Voice 2.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 50 
16. Appendix C - Example Error Voice Processing Error Codes

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


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

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

   Analog delivery failed          4.4.1 Persistent protocol error
   because remote system is              - no answer from host
   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 51 
   Message marked private, but     5.3.3 Permanent system error
   system is not private capable         - not feature capable

17. Appendix D - Example Voice Processing Disposition Types

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

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

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

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

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

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

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

Top      Up      ToC       Page 52 
18. Appendix E - IANA Registrations

18.1 vCard EMAIL Type Definition for VPIM

   To: ietf-mime-directory@imc.org

   Subject: Registration of new parameter for text/directory MIME type
   EMAIL

   Type name: EMAIL

   Type purpose: To specify the electronic mail address for
   communication with the object the vCard represents (defined in
   [VCARD]).

   Type encoding: 8bit

   Type value: A single text value.

   Type special notes: The type may include the type parameter "TYPE" to
   specify the format or preference of the electronic mail address. The
   TYPE parameter values previously defined include: "internet" to
   indicate an Internet addressing type, "x400" to indicate a X.400
   addressing type and "pref" to indicate a preferred-use email address
   when more than one is specified. The value of "vpim" is defined to
   indicate that the address specified supports VPIM messages.  Other
   IANA registered address type may also be specified. The default email
   type is "internet". A non-standard value may also be specified.

   Type example:
                 EMAIL;TYPE=internet,vpim:jqpublic@xyz.dom1.com

18.2 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,

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

Top      Up      ToC       Page 54 
19. Appendix F - Change History: RFC 1911 to this Document

   The updated profile in this document is based on the experience of a
   proof of concept demonstration of VPIM at EMA'96 in April 1996 and a
   subsequent demonstration of products at EMA'97 in April 1997.  This
   version of the profile is significantly different from the previous
   described in [VPIM1].  The changes are categorized as general,
   content, transport and compliance.  They are detailed below:

   1. General

     - All definitions are now contained in separate documents that are
     referenced by this profile.  The new documents include:

        - a refined multipart/voice-message definition

        - a refined (i.e., added nibble order) audio/32KADPCM definition

        - the definitions of TIFF-F and image/tiff for fax images

        - the Content-Duration definition

     - Changed the Voice version to 2.0

     - Added Table of Contents and more examples

     - Various editorial updates to improve readability

     - Added more security considerations

   2. Content

     - Modified multipart/voice-message content type by dropping the
     positional dependence of contents while restricting its contents to
     voice message specific content types

     - Explicitly indicated other contents that may be present ina
     multipart/mixed content type

     - Explicitly defined the forwarding model using message/RFC822

     - Explained the use of reply-to and from header fields for
     addressing message replies

     - Deprecated the special "loopback" address because of security
     concerns and its use only for testing

Top      Up      ToC       Page 55 
     - Defined the non-mail-user reserved address to support the case in
     which replies to the originator are not possible

     - Eliminated the text name in the "To" and "CC" header fields.
     Deprecated ordering of text names in the "From" header.

     - Added support for facsimile using TIFF-F in an image/tiff;
     application=faxbw content type

     - Profiled vCard in the text/directory body part for transport of
     directory information about the originator

     - Loosened text restriction

     - Added additional details on delivery and receipt notifications

     - Added support for message disposition notifications, also known
     as receipt notifications.

     - Added suggested addressing formats

     - Described handling of private messages

     - Described the handling of non-profiled contents in VPIM messages

     - Described the use of Content-Disposition to semantically identify
     audio contents

   3. Transport

     - Moved binary support to optional

     - Added optional ESMTP keywords for return of content, enhanced
     status codes, original recipient, and envelope ID

     - Described use of null MAIL FROM address

   4. Compliance

     - Added an explicit section on conformance specifying conformance
     to content or transport

     - Improved conformance table in Appendix A

Top      Up      ToC       Page 56 
20.  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.