Network Working Group G. Vaudreuil Request for Comments: 2421 Lucent Technologies Obsoletes: 1911 G. Parsons Category: Standards Track Northern Telecom September 1998 Voice Profile for Internet Mail - version 2 Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Overview This document profiles Internet mail for voice messaging. It obsoletes RFC 1911 which describes version 1 of the profile. A list of changes from that document are noted in Appendix F. As well, Appendix A summarizes the protocol profiles of this version of VPIM. Please send comments on this document to the EMA VPIM Work Group mailing list: Working Group Summary This profile is not the product of an IETF working group, though several have reviewed the document. It is instead the product of the VPIM Work Group of the Electronic Messaging Association (EMA). This work group, which has representatives from most major voice mail vendors and several email vendors, has held several interoperability demonstrations between voice messaging vendors and is currently promoting VPIM trials and deployment. Vaudreuil & Parsons Standards Track [Page 1] RFC 2421 VPIM v2 September 1998 Table of Contents 1. ABSTRACT .........................................................3 2. SCOPE ............................................................3 2.1 Voice Messaging System Limitations ............................3 2.2 Design Goals ..................................................4 3. PROTOCOL RESTRICTIONS ............................................5 4. VOICE MESSAGE INTERCHANGE FORMAT .................................6 4.1 Message Addressing Formats ....................................6 4.2 Message Header Fields .........................................9 4.3 Voice Message Content Types ..................................15 4.4 Other Message Content Types ..................................21 4.5 Forwarded Messages ...........................................23 4.6 Reply Messages ...............................................23 4.7 Notification Messages ........................................24 5. MESSAGE TRANSPORT PROTOCOL ......................................24 5.1 ESMTP Commands ...............................................25 5.2 ESMTP Keywords ...............................................27 5.3 ESMTP Parameters - MAIL FROM .................................28 5.4 ESMTP Parameters - RCPT TO ...................................29 5.5 ESMTP - SMTP Downgrading .....................................29 6. DIRECTORY ADDRESS RESOLUTION ....................................30 7. IMAP ............................................................30 8. MANAGEMENT PROTOCOLS ............................................30 8.1 Network Management ...........................................31 9. CONFORMANCE REQUIREMENTS ........................................31 10. SECURITY CONSIDERATIONS ........................................32 10.1 General Directive ...........................................32 10.2 Threats and Problems ........................................32 10.3 Security Techniques .........................................33 11. REFERENCES .....................................................33 12. ACKNOWLEDGMENTS ................................................36 13. AUTHORS' ADDRESSES .............................................36 14. APPENDIX A - VPIM REQUIREMENTS SUMMARY .........................37 15. APPENDIX B - EXAMPLE VOICE MESSAGES ............................45 16. APPENDIX C - EXAMPLE ERROR VOICE PROCESSING ERROR CODES ........50 17. APPENDIX D - EXAMPLE VOICE PROCESSING DISPOSITION TYPES ........51 18. APPENDIX E - IANA REGISTRATIONS ................................52 18.1 vCard EMAIL Type Definition for VPIM ........................52 18.2 Voice Content-Disposition Parameter Definition ..............52 19. APPENDIX F - CHANGE HISTORY: RFC 1911 TO THIS DOCUMENT .........54 20. FULL COPYRIGHT NOTICE ..........................................56 Vaudreuil & Parsons Standards Track [Page 2] RFC 2421 VPIM v2 September 1998 1. Abstract A class of special-purpose computers has evolved to provide voice messaging services. These machines generally interface to a telephone switch and provide call answering and voice messaging services. Traditionally, messages sent to a non-local machine are transported using analog networking protocols based on DTMF signaling and analog voice playback. As the demand for networking increases, there is a need for a standard high-quality digital protocol to connect these machines. The following document is a profile of the Internet standard MIME and ESMTP protocols for use as a digital voice messaging networking protocol. The profile is referred to as VPIM (Voice Profile for Internet Mail) in this document. This profile is based on earlier work in the Audio Message Interchange Specification (AMIS) group that defined a voice messaging protocol based on X.400 technology. This profile is intended to satisfy the user requirements statement from that earlier work with the industry standard ESMTP/MIME mail protocol infrastructures already used within corporate intranets. This second version of VPIM is based on implementation experience and obsoletes RFC 1911 which describes version 1 of the profile. 2. Scope MIME is the Internet multipurpose, multimedia messaging standard. This document explicitly recognizes its capabilities and provides a mechanism for the exchange of various messaging technologies, primarily voice and facsimile. This document specifies a restricted profile of the Internet multimedia messaging protocols for use between voice processing server platforms. These platforms have historically been special- purpose computers and often do not have the same facilities normally associated with a traditional Internet Email-capable computer. As a result, VPIM also specifies additional functionality as it is needed. This profile is intended to specify the minimum common set of features to allow interworking between compliant systems. 2.1 Voice Messaging System Limitations The following are typical limitations of voice messaging platform which were considered in creating this baseline profile. 1) Text messages are not normally received and often cannot be easily displayed or viewed. They can often be processed only via text-to-speech or text-to-fax features not currently present in many of these machines. Vaudreuil & Parsons Standards Track [Page 3] RFC 2421 VPIM v2 September 1998 2) Voice mail machines usually act as an integrated Message Transfer Agent, Message Store and User Agent. There is no relaying of messages, and RFC 822 header fields may have limited use in the context of the limited messaging features currently deployed. 3) Voice mail message stores are generally not capable of preserving the full semantics of an Internet message. As such, use of a voice mail machine for gatewaying is not supported. In particular, storage of recipient lists, "Received" lines, and "Message-ID" may be limited. 4) Internet-style distribution/exploder mailing lists are not typically supported. Voice mail machines often implement only local alias lists, with error-to-sender and reply-to-sender behavior. Reply-all capabilities using a CC list are not generally available. 5) Error reports must be machine-parsable so that helpful responses can be voiced to users whose only access mechanism is a telephone. 6) The voice mail systems generally limit address entry to 16 or fewer numeric characters, and normally do not support alphanumeric mailbox names. Alpha characters are not generally used for mailbox identification as they cannot be easily entered from a telephone terminal. 2.2 Design Goals It is a goal of this profile to make as few restrictions and additions to the existing Internet mail protocols as possible while satisfying the requirements for interoperability with current generation voice messaging systems. This goal is motivated by the desire to increase the accessibility to digital messaging by enabling the use of proven existing networking software for rapid development. This specification is intended for use on a TCP/IP network; however, it is possible to use the SMTP protocol suite over other transport protocols. The necessary protocol parameters for such use is outside the scope of this document. This profile is intended to be robust enough to be used in an environment, such as the global Internet with installed-base gateways which do not understand MIME, though typical use is expected to be within corporate intranets. Full functionality, such as reliable error messages and binary transport, will require careful selection of gateways (e.g., via MX records) to be used as VPIM forwarding agents. Nothing in this document precludes use of general purpose MIME email packages to read and compose VPIM messages. While no Vaudreuil & Parsons Standards Track [Page 4] RFC 2421 VPIM v2 September 1998 special configuration is required to receive VPIM compliant messages, some may be required to originate compliant structures. It is expected that a VPIM messaging system will be managed by a system administrator who can perform TCP/IP network configuration. When using facsimile or multiple voice encodings, it is suggested that the system administrator maintain a list of the capabilities of the networked mail machines to reduce the sending of undeliverable messages due to lack of feature support. Configuration, implementation and management of these directory listing capabilities are local matters. 3. Protocol Restrictions This protocol does not limit the number of recipients per message. Where possible, server implementations should not restrict the number of recipients in a single message. It is recognized that no implementation supports unlimited recipients, and that the number of supported recipients may be quite low. This protocol does not limit the maximum message length. Implementers should understand that some machines will be unable to accept excessively long messages. A mechanism is defined in the RFC 1425 SMTP service extensions to declare the maximum message size supported. The message size indicated in the ESMTP SIZE parameter is in bytes, not minutes or seconds. The number of bytes varies by voice encoding format and includes the MIME wrapper overhead. If the length must be known before sending, an approximate translation into minutes or seconds can be performed if the voice encoding is known. The following sections describe the restrictions and additions to Internet mail protocols that are required to be compliant with this VPIM v2 profile. Though various SMTP, ESMTP and MIME features are described here, the implementer is referred to the relevant RFCs for complete details. It is also advisable to check for IETF drafts of various Internet Mail specifications that are later than the most recent RFCs since, for example, MIME has yet to be published as a full IETF Standard. The table in Appendix A summarizes the protocol details of this profile. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [REQ]. Vaudreuil & Parsons Standards Track [Page 5] RFC 2421 VPIM v2 September 1998 4. Voice Message Interchange Format The voice message interchange format is a profile of the Internet Mail Protocol Suite. Any Internet Mail message containing the format defined in this section is referred to as a VPIM Message in this document. As a result, this document assumes an understanding of the Internet Mail specifications. Specifically, VPIM references components from the message format standard for Internet messages [RFC822], the Multipurpose Internet Message Extensions [MIME], the X.400 gateway specification [X.400], delivery status and message disposition notifications [REPORT][DSN][DRPT][STATUS][MDN], and the electronic business card [MIMEDIR][VCARD]. 4.1 Message Addressing Formats RFC 822 addresses are based on the domain name system. This naming system has two components: the local part, used for username or mailbox identification; and the host part, used for global machine identification. 4.1.1 VPIM Addresses The local part of the address shall be a US-ASCII string uniquely identifying a mailbox on a destination system. For voice messaging, the local part is a printable string containing the mailbox ID of the originator or recipient. While alpha characters and long mailbox identifiers are permitted, most voice mail networks rely on numeric mailbox identifiers to retain compatibility with the limited 10 digit telephone keypad. As a result, some voice messaging systems may only be able to handle a numeric local part. The reception of alphanumeric local parts on these systems may result in the address being mapped to some locally unique (but confusing to the recipient) number or, in the worst case the address could be deleted making the message un-replyable. Additionally, it may be difficult to create messages on these systems with an alphanumeric local part without complex key sequences or some form of directory lookup (see 6). The use of the domain naming system should be transparent to the user. It is the responsibility of the voice mail machine to lookup the fully-qualified domain name (FQDN) based on the address entered by the user (see 6). In the absence of a global directory, specification of the local part is expected to conform to international or private telephone numbering plans. It is likely that private numbering plans will prevail and these are left for local definition. However, it is RECOMMENDED that public telephone numbers be noted according to the international numbering plan described in [E.164]. The indication Vaudreuil & Parsons Standards Track [Page 6] RFC 2421 VPIM v2 September 1998 that the local part is a public telephone number is given by a preceding `+' (the `+' would not be entered from a telephone keypad, it is added by the system as a flag). Since the primary information in the numeric scheme is contained by the digits, other character separators (e.g. `-') may be ignored (i.e. to allow parsing of the numeric local mailbox) or may be used to recognize distinct portions of the telephone number (e.g. country code). The specification of the local part of a VPIM address can be split into the four groups described below: 1) mailbox number - for use as a