Internet Draft Internet Draft Glenn Parsons Nortel Networks March 10, 2000 Voice Profile for Internet Mail Version 3 A Simple Approach <draft-ema-vpim-simplev3-01.txt> Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. For more information on the VPIM industry activity see http://www.ema.org/vpim/. 2. Conventions used in this document 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 RFC-2119 [2]. 3. Introduction Voice messaging transport over Internet Mail is defined by VPIM v2 (RFC 2421)[3]. Parsons Expires: 09/10/00 1 Internet Draft VPIM v3 March 10, 2000 The original detailed proposal for VPIM v3 is contained in [4]. 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 [3] 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. 4. Message Format All messages MUST conform with the Internet Mail format as described in DRUMS [6][7]. 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 multipart/mixed. Although it may also be any other multipart/* such as multipart/voice-message or multipart/related. The top level content type on origination of a delivery notification message MUST be either multipart/report. An implementation SHOULD use the multipart/voice-message content type as described in [8] to package audio content together as a voice message. 4.1 Voice Message Format A message containing a multipart/voice-message content-type at the top level or as the first on the second level (e.g., under multipart/mixed) is implicitly primarily a voice message. The recipient system may use this to decide to present the message as a voice message. Additionally, an originator may choose to indicate that one of the body parts (e.g., the spoken message part) is critical for the delivery of the message. This would ensure that this part is delivered if others are dropped for delivery to less capable clients. Note that there is no current proposal for this feature. Parsons Expires 9/10/00 2 Internet Draft VPIM v3 March 10, 2000 5. Transport All transport MUST support Internet Mail transport (SMTP/ESMTP) as described in DRUMS [6]. 6. Addressing Any valid Internet Mail address MAY be used. However, VPIM onramp and offramp implementations MAY require a stricter addressing structure [9]. As a result, the VPIM addressing structure of [9] 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 mailbox (and spoken name if applicable) by only knowing the E.164 phone number of the recipient SHOULD be supported [10]. 7. Notifications DSN MUST be supported [11]. 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 [12]. MDN MUST be supported [13]. Partial MDNs (to indicate that one or more contents could not be rendered at the client) SHOULD be supported. Note that partial MDN is a new concept with no current proposal. 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 [3] MUST be used to identify them as voice messages or spoken names. The originator's spoken name SHOULD be included with a message. Spoken names (for originators and recipients) SHOULD 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 compliant with this document: Parsons Expires 9/10/00 3 Internet Draft VPIM v3 March 10, 2000 MUST play & record: MS-GSM - audio/wav; codec=31 [14] SHOULD play & record: G.726 - audio/32kadpcm [15] Note for an implementation to interoperate with VPIM v2 it MUST, at a minimum, support play & record of G.726. Compliant implementations recording with a WAVE RIFF header MUST add the codec parameter on origination. However, non-compliant systems may send messages without this parameter. 9. IMAP Implementations SHOULD support access to the voice message store using IMAP [16]. The voice extensions described in [17] 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 [3]. 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. 11. Security Considerations It is anticipated that there are no additional security issues beyond those identified in VPIM v2. 12. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 Parsons Expires 9/10/00 4 Internet Draft VPIM v3 March 10, 2000 3 Vaudreuil, G., Parsons, G., "Voice Profile for Internet Mail - version 2", RFC 2421, September 1998. 4 Vaudreuil, G., Parsons, G., "Voice Profile for Internet Mail - version 3",, Work in Progress. 5 Di Silvestro, Laile, "Goals for VPIM v3", , Work in Progress. 6 Klensin, J,. "Simple Mail Transfer Protocol", , Work in Progress. 7 Resnick, P., "Internet Message Format Standard", , Work in Progress. 8 G. Vaudreuil and G. Parsons, "VPIM Voice Message: MIME Sub- type Registration", RFC 2423, September 1998. 9 G. Parsons, G., "VPIM Addressing", , Work in Progress. 10 Brown, A., Vaudreuil, G., _Telephone Number Based Directory Service_, , Work in Progress. 11 Moore, K., Vaudreuil, G., "An Extensible Message Format for Delivery Status Notifications", RFC 1894, 1/15/1996. 12 Burger, Eric, _Partial Non-Delivery Notification_, , Work in Progress. 13 Fajman, Roger, "An Extensible Message Format for Message Disposition Notifications" RFC 2298, March 1998. 14 Baribault, G. et al, _ Waveform Audio File Format _ MIME subtype registration_, , Work in Progress. Baribault, G. et al, _ Microsoft GSM _ MIME subtype registration_, , Work in Progress. 15 G. Vaudreuil and G. Parsons, "Toll Quality Voice - 32 kbit/s ADPCM: MIME Sub-type Registration", RFC 2422, September 1998. 16 Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 2060, December 1996. 17 Parsons, G., "IMAP Voice Extensions", , Work in Progress. Parsons Expires 9/10/00 5 Internet Draft VPIM v3 March 10, 2000 13. Acknowledgements This draft is a derivative of the original VPIM v2 work, hopefully taking into account the views of both the voice mail and email communities that have come together to work on VPIM v3 in the IETF VPIM BOF/WG. 14. 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 15. Full Copyright Statement Copyright (C) The Internet Society (2000). 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 9/10/00 6