draft-ema-vpim-simplev3-00.txt Internet Draft Glenn Parsons Expires in six months Nortel Networks June 25, 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 Voice messaging transport over Internet Mail is defined by VPIM v2 (RFC 2421)[1]. The original detailed proposal for VPIM v3 is contained in [10]. This Internet Draft details a proposed simpler approach at VPIM v3. It is intended to follow the baseline goals described in [5]. Given that VPIM v2 [1] is a well defined (or will be when it is revised for clarity and maturity elevation) description of networking 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. It is proposed, that all that is needed is an agreement to use Internet Mail without modification and profile a minimal set of Internet Mail standard features that a VPIM v3 compliant system MUST support. As all devices become connected with email, VPIM v3 compliance will ensure the ability to communicate voice messages between these devices. Parsons Expires 12/25/99 [Page 1] Internet Draft IMAP Voice June 25, 1999 For more information see http://www.ema.org/vpim/. 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 [12]. Any content type is allowed to be in a message. The top level content type on origination of a new, forwarded or reply message SHOULD typically 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 [6] to package audio content together as a voice message. 5. Transport All transport MUST support Internet Mail transport (SMTP/ESMTP) as described in DRUMS [11]. 6. Addressing Any valid Internet Mail address MAY be used. However, VPIM onramp and offramp implementations MAY require a stricter addressing structure [7]. As a result, the VPIM addressing structure of [7] MUST be supported for recipient addresses in inbound messages and SHOULD be supported for the originator address if required. Discovery of an Internet Mail address for a recipientØs voice mail box (if applicable) SHOULD be supported by only knowing the E.164 phone number of the recipient. (Details of the DNS/LDAP mechanism TBD) 7. Notifications DSN MUST be supported. All non-delivery of messages MUST result in a NDN. Partial DSNs (to indicate that one or more contents could not be stored/relayed by the receiving MTA) SHOULD be supported. MDN MUST be supported. Partial MDNs (to indicate that one or more contents could not be rendered) SHOULD be supported. Parsons Expires 12/25/99 [Page 2] Internet Draft IMAP Voice June 25, 1999 8. Voice Contents Voice messages may be contained at any location within a message and MUST be contained in an audio/* content-type. The parameters described in [1] MUST be used to identify them as voice messages or spoken names. The originators spoken name SHOULD be included with a message. Spoken names (for originators and recipients) MAY be included as separate audio contents. These MAY be referenced from the message header or a vCard. Spoken names MAY also be included inline with a vCard. External references SHOULD NOT be used. Any voice codec may be used. An implementation SHOULD determine the recipient capabilities before the sending of a message if possible and choose a codec accordingly (a CONNEG and RESCAP profile is needed). In the absence of recipient knowledge, implementations: 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. Note that the codecs may appear natively or with a WAVE RIFF header (the codec parameter SHOULD be used on origination so cannot be guaranteed for the recipient). 9. IMAP Implementations SHOULD support access to the voice message store using IMAP [3]. The voice extensions described in [9] 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 [1]. Simply, record and encode audio/32kadpcm under a top level multipart/voice-message. If a VPIM v3 system has knowledge that the recipient system is VPIM v2 (via CONNEG, RESCAP, LDAP, etc.) it MUST send a VPIM v2 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. Parsons Expires 12/25/99 [Page 3] Internet Draft IMAP Voice June 25, 1999 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. [5] Di Silvestro, Laile, "Goals for VPIM v3", , Work in Progress. [6] G. Vaudreuil and G. Parsons, "VPIM Voice Message: MIME Sub-type Registration", RFC 2423, September 1998. [7] G. Parsons, G., "VPIM Addressing", , Work in Progress. [8] Parsons, G., Cohen, M., Vaudreuil, G., "VPIM Unified Message MIME Sub-Type Registration", , Work In Progress. [9] Parsons, G., "IMAP Voice Extensions", , Work in Progress. [10] Vaudreuil, G., Parsons, G., "Voice Profile for Internet Mail - version 3", , Work in Progress. [11] Klensin, J,. "Simple Mail Transfer Protocol", , Work in Progress. [12] Resnick, P., "Internet Message Format Standard", , Work in Progress. 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 Parsons Expires 12/25/99 [Page 4] Internet Draft IMAP Voice June 25, 1999 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/25/99 [Page 5]