Internet Draft Glenn Parsons Expires in six months Nortel Networks June 24, 1999 Voice Profile for Internet Mail - Version 3 A Simple Approach Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract This document proposes an alternative simple approach to VPIM v3. 2. Introduction This Internet Draft summarizes a proposed simple approach at VPIM v3. Given that VPIM v2 [RFC 2421] is well defined (or will be when it is revised for clarity and maturity elevation) and describes the interaction of voice-only systems using Internet Mail, and that Internet Mail is being used as-is for multimedia messaging, there is minimal need for a detailed revision.of VPIM to support Unified Messaging. All that is needed is an agreement to use Internet Mail as-is and profile a minimal set of features that a VPIM v3 compliant system MUST support. As everything becomes connected with email, VPIM v3 compliance will ensure the ability to communicate between all systems. Voice messaging transport over Internet Mail is defined by VPIM v2 (RFC 2421)[1]. For more information see http://www.ema.org/vpim/. Parsons Expires 12/23/99 [Page 1] Internet Draft IMAP Voice June 23, 1999 3. Conventions Used in this Document The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [2]. 4. Message Format All messages MUST conform with the Internet Mail format as described in [DRUMS]. Any content type is allowed to be in a message. The top level content type on origination of a new, forwarded or reply message MUST be either multipart/mixed or multipart/voice-message. The top level content type on origination of a delivery notification message MUST be either multipart/report. An implementation MAY use the multipart/voice-message content type as described in [RFC 2423] to package content together as a voice message. 5. Transport All transport MUST support Internet Mail transport (SMTP/ESMTP) as described in [DRUMS] 6. Addressing Any valid Internet Mail address MAY be used. However, the addressing structure of [VPIM-ADDRESS] MUST be supported for recipient addresses in inbound messages and SHOULD be supported for the originator address if required. 7. Notifications DSN MUST be supported. All non-delivery of messages MUST result in a NDN. MDN MUST be supported. Partial MDNs (to indicate that one or more contents could not be rendered) SHOULD be supported. 8. Voice Codecs Voice messages may be contained at any location within a message. The parameters described in [VPIM2] MUST be used to identify them as voice messages or spoken names. MUST play: G.726 - audio/32kadpcm or audio/wav; codec=64 G.711 - audio/basic or audio/wav; codec=7 MS-GSM - audio/msgsm or audio/wav; codec=31 SHOULD encode: G.726 - audio/32kadpcm or audio/wav; codec=64 G.711 - audio/basic or audio/wav; codec=7 MS-GSM - audio/msgsm or audio/wav; codec=31 An implementation MUST be able to play either of the three codecs (either natively or via transcoding) and MUST be able to record and encode messages in at least one of them. 9. IMAP Implementations SHOULD support access to the voice message store using IMAP. The extensions described in [IMAP-VOICE] SHOULD be supported. 10. Backwards compatibility with VPIM v2 Because of the wide deployed base of VPIM v2, implementations are encouraged to send messages in a format compatible with VPIM v2 systems as described in [RFC 2421]. Simply, record and encode audio/32kadpcm under a top level multipart/voice-message. A VPIM v2 system SHOULD reject a message it cannot render with a DSN indicating the media is unsupported. A VPIM v3 compliant system SHOULD record this information for future sending, and SHOULD resend the original message in a VPIM v2 format. 11. References [1] Vaudreuil, G., Parsons, G., "Voice Profile for Internet Mail - version 2", RFC 2421, September 1998. [2] Bradner, S., "Key Words for use in RFCs To Indicate Requirement Levels", RFC 2119, March 1997. [3] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 2060, December 1996. [4] Freed, N., Borenstein, N., "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [8] Parsons, G., Cohen, M., Vaudreuil, G., "VPIM Unified Message MIME Sub-Type Registration", , Work In Progress. Parsons Expires 12/23/99 [Page 5] Internet Draft IMAP Voice June 23, 1999 12. Security Considerations TBD 13. Author's Address Glenn W. Parsons Nortel Networks P.O. Box 3511, Station C Ottawa, ON K1Y 4H7 Phone: +1-613-763-7582 Fax: +1-613-763-4461 Email: gparsons@nortelnetworks.com 14. Full Copyright Statement "Copyright (C) The Internet Society (1999). 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." Parsons Expires 12/23/99 [Page 6]