[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 3773

Network Working Group                                        E. Candell
Internet Draft                                 Comverse Network Systems
Document: draft-ietf-vpim-ivm-goals-00                November 15, 2000
Obsoletes: draft-ema-vpimv3-goals-02.txt
Category: Informational

                     Goals for Internet Voice Mail

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [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
   The list of Internet-Draft Shadow Directories can be accessed at

   This draft is a part of the charter of the IETF VPIM WG. To
   subscribe to the mailing list, send a message to
   <majordomo@lists.neystadt.org> with the text "subscribe vpim" in the
   body of the message. For more information on the VPIM activity see

1. Abstract

   This document describes the goals for Internet Voice Mail (IVM) and
   establishes a baseline of desired functionality against which
   proposed MIME profiles for Internet Voice Messaging can be judged.
   IVM is an extension of VPIM version 2 [VPIM2] designed to support
   interoperability with desktop clients. Other goals for this version
   of VPIM include expanded interoperability with unified messaging
   systems, conformance to Internet standards, and backward
   compatibility with voice messaging systems currently running in a
   VPIM enabled environment. This document does not include goals that
   were met fully by VPIM version 2 [VPIM2].

2. Conventions used in this document

   The following terms have specific meaning in this document:
   "service"      An operational service offered by a service provider
   "application"  A use of systems to perform a particular function

Candell         Informational - Expires: May 15, 2001        [Page 1]

                    Goals for Internet Voice Mail       November 2000

   "terminal"     The endpoint of a communication application
   "goal"         An objective of the standardization process

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   this document are to be interpreted as described in RFC-2119

3. Introduction

   Until recently, voice mail and call answering services were
   implemented as stand-alone proprietary systems. Today, standards
   such as the Voice Profile for Internet Mail (VPIM) enable
   interoperability between such systems over the Internet. VPIM
   version 1 [VPIM1] was experimental and was a first attempt at a
   Voice Profile for Internet Mail, but is now classified as
   Historical. VPIM Version 2 [VPIM2] is an improvement on VPIM version
   1 that was originally intended to provide interoperability between
   voice messaging systems only. It describes a messaging profile that
   standardizes the exchange of voice mail over an IP messaging network
   using ESMTP [ESMTP] and MIME [MIME1].

   Because the number of desktop boxes is growing rapidly and will soon
   approach the number of desktop telephones, it is essential to
   consider the requirements of desktop email client applications
   (including, but not limited to, MIME-compliant email clients).  With
   the trend toward integration of voice mail and email through unified
   messaging (UM), it is now necessary to define a new version of VPIM
   that supports the needs of desktop applications and unified
   messaging systems (including Internet Facsimile [EXFAX]). This
   version of VPIM is being referred to as Internet Voice Mail (IVM).

   This document defines the goals for Internet Voice Mail. This
   standard will support the interchange of voice messages between
   voice mail systems, unified messaging systems, email servers, and
   desktop client applications. The desktop client application is of
   particular and important interest to IVM. This document will also
   expand the offerings of service providers by facilitating access to
   voice mail from a web client.

4. Goals for Internet Voice Mail

4.1 Interoperability

   Enhanced interoperability is the primary goal of IVM. The profile
   MUST facilitate interoperability between voice mail systems, unified
   messaging systems, Internet email servers, and desktop client
   applications. Such interoperability MUST support systems which
   combine multiple media types into a single message, as well as

Candell         Informational - Expires: May 15, 2001        [Page 2]

                    Goals for Internet Voice Mail       November 2000

   support for legacy voice mail and email systems. It MUST allow the
   ability to accommodate varying capabilities of the voice mail,
   unified messaging and email systems. Furthermore, IVM MUST be
   compatible with Internet Fax (extended mode) proposed standards and
   VPIM messages that contain fax body parts.

   To have "interoperability" means that an IVM compliant sender
   attempting to send to a recipient will not fail because of
   incompatibility. IVM MUST support interoperability amongst the
   systems listed below:
        - Desktop Email client applications
        - IVM-capable Voice Mail systems
        - IVM-capable unified messaging systems
        - Traditional email servers
   And SHOULD support interoperabilty with VPIM version 2 voice Mail

   IVM MUST include new functionality to facilitate access to voice
   mail messages from desktop applications.

   Overall interoperability requires interoperability for all of the
   message elements: critical body parts [CRIT] MUST be preserved,
   essential information MUST be provided in a form that is accessible
   by the users, status codes [CODES] MUST be understood, and
   operations that are standard for each system SHOULD be supported.

4.1.1   Interoperability with Desktop Email Client Applications

   Desktop email applications are typically text based. The ability to
   listen to, reply to, forward, and generate voice mail messages from
   a traditional desktop environment is a relatively new development.
   To accommodate current use and future developments in this area, IVM
   MUST provide features to support access to voice mail messages from
   the desktop and other email-reading devices. Also, web access to
   voicemail SHOULD be supported from the desktop.

   IVM SHOULD NOT require desktop email applications to possess a large
   amount of processing power, and a base level implementation MUST
   interoperate, even if it does not offer complex processing. In order
   to support interoperability, a mandatory codec MUST be defined.  The
   mandatory codec SHOULD be widely available on desktops.  For
   interoperability with VPIM version 2 systems, IVM applications
   SHOULD also support the VPIM v2 mandatory codec [ADPCM and G726].

   Any codecs included in the IVM specification SHOULD meet the
   following criteria:
        - Availability on desktops: Codecs SHOULD be available on most
        - Source code availability: Source code SHOULD be readily
        - Decoding complexity: All codecs MUST be low complexity to

Candell         Informational - Expires: May 15, 2001        [Page 3]

                    Goals for Internet Voice Mail       November 2000

        - Encoding complexity: Some of the codecs MUST be low
        complexity to encode.
        - Bit rate: IVM MUST specify a codec with low bit rate for
        devices (i.e., wireless) that do not have much space/bandwidth.
        - Voice Over IP support: IVM SHOULD specify a codec that
        supports Voice over IP implementations.

   Most desktop email applications and web clients are not capable of
   playing raw audio. To support "out-of-the-box" playing of voice mail
   content, IVM MUST support wav encapsulation of audio. To enable
   future support of other formats, IVM SHOULD provide identification
   of the codec used without requiring interpretation of an audio
   format. IVM MAY allow audio encodings and formats that are not
   identified in IVM specification to support environments in which the
   sender is aware of the optimal encoding and format for the

   To address performance and bandwidth issues, IVM MAY support
   streaming of IVM audio to the desktop.  IVM MAY explicitly support
   formats other than raw audio and wav to facilitate streaming.

   Because most email readers are text/html based and because many
   devices are not capable of recording audio content, IVM MUST allow
   inclusion of text body parts in a voice message. IVM SHOULD NOT
   explicitly prohibit other media types, as long as critical content
   is identified and minimal discard rules are specified [CRIT].  An
   IVM application MAY support partial non-delivery notifications
   [PNDN] to relay information to the sender regarding discarded body

   To support devices which have applications dedicated to specific
   media types or that are not capable of handling specific content,
   IVM SHOULD define a way to describe the content of the message,
   indicating how the content can be accessed [HINT].

   Desktop implementation of IVM MUST support attachments of any media

4.1.2   Interoperability with IVM-capable Voice Messaging Systems

   Voice messaging systems are generally implemented as special-purpose
   machines that interface to a telephone switch and provide call
   answering and voice messaging services. VPIM version 2 was designed
   to support interoperability between such systems and remains the
   best messaging profile for this purpose.

   To support interoperability between IVM voice messaging systems and
   other compliant systems, IVM SHOULD have a minimum set of required
   features that will guarantee interoperability, as well as provision
   for additional functionality that may be supported by more complex
   systems. IVM MUST define a mechanism for identifying essential

Candell         Informational - Expires: May 15, 2001        [Page 4]

                    Goals for Internet Voice Mail       November 2000

   content [CRIT] and status codes [CODES] indicating that a message
   could not be delivered due to capability differences.

   NOTE: IVM SHOULD provide some level of interoperability with VPIM
   version 2 voice messaging systems. In order to support mimimal
   interoperability between IVM and VPIM version 2, IVM systems MUST be
   able to receive the VPIM version 2 32KADPCM codec [ADPCM and G726],
   and MUST gracefully handle the case where a legacy receiving system
   does not support the IVM codecs.

4.1.3   Interoperability with IVM-capable Unified Messaging Systems

   Unified messaging solutions typically leverage common store,
   directory, and transport layers to provide greater interoperability
   and accessibility to a variety of media content. They support
   creation of and access to voicemail, email, and fax messages from a
   single user interface.

   To accommodate the common functionality of unified messaging
   systems, IVM MUST support the inclusion of body parts containing
   different media types. It MUST also handle messages that contain
   VPIM messages as attachments to messages of another type (such as
   multipart/mixed), and VPIM messages that contain attachments of
   another type.

   To provide interoperability with systems that cannot handle a
   particular content type, IVM MUST provide a mechanism for
   identifying critical content [CRIT] and MAY define media specific
   status codes and strings to handle non-delivery of these body parts.

4.1.4   Interoperability with Traditional Email Servers

   Traditional email servers are those that support only textual media
   as inline content. IVM MUST interoperate consistently with the
   current Internet mail environment. If an IVM message arrives in
   users' mailboxes, IVM MUST provide a mechanism to interoperate with
   common user practices for mail messages: storing them in databases,
   retransmission, forwarding, creation of mail digests, and replying
   to messages using non-audio equipment.

4.2  Conformance to Existing Standards

   It is the goal of IVM to conform as closely as possible to existing
   standards while meeting the other goals defined in this document.

   - Restrictions: The profile SHOULD impose as few restrictions as
   possible to existing Internet mail standards. In particular, it MUST
   support all elements of RFC 822 [RFC822] except those that prevent
   the profile from meeting other IVM goals.

Candell         Informational - Expires: May 15, 2001        [Page 5]

                    Goals for Internet Voice Mail       November 2000

   - Additions: The profile SHOULD make as few additions as
   possible to existing internet mail standards. It SHOULD adhere to
   existing desktop conventions in desktop-related areas such as file
   extensions. If it is necessary to define new MIME types or sub-
   types, the IVM work group SHOULD propose terms that are already
   standard or in common use in the desktop environment.

4.3 Backward Compatibility

   This profile SHOULD provide backward compatibility with VPIM version
   2 to an extent where the functionality required to meet the goals of
   this profile is not compromised.  Where backward compatibility is
   not possible, IVM SHOULD provide and define a minimal set of rules
   and status codes for handling non-delivery of IVM messages resulting
   from interoperability with VPIM version 2 systems and other legacy

4.4  Robustness

   IVM MUST be usable in an environment in which there exist legacy
   gateways that do not understand MIME. Core features and critical
   data MUST not be lost when messages pass through AMIS gateways
   [AMIS-A and AMIS-D]. IVM SHOULD allow interoperability with
   recipient devices and gateways that have limited buffering
   capabilities and cannot buffer all header information.

5. References
   [ADPCM] G. Vaudreuil 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.

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

   [CRIT] Burger, E. and Candell, E., "Critical Content of Internet
      Mail", draft-ietf-vpim-cc-01.txt, Work in Progress, May 26, 2000.

   [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
      Crocker, "SMTP Service Extensions" RFC 1869, United Nations
      University, Innosoft International, Inc., Dover Beach Consulting
      Inc., Network Management Associates, Inc., The Branch Office,
      November 1995.

   [EXFAX] Masinter, L., Wing, D., "Extended Facsimile Using Internet
      Mail", RFC 2532, Xerox Corporation, Cisco Systems, March  1999.

Candell         Informational - Expires: May 15, 2001        [Page 6]

                    Goals for Internet Voice Mail       November 2000

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

   [HINT] Burger, E., et al., "Message Context for Internet Mail",
      draft-ietf-vpim-hint-01.txt, Work in Progress, November 13, 2000.

   [MIME1] N. Freed and N. Borenstein,  "Multipurpose Internet Mail
      Extensions (MIME) Part One: Format of Internet Message Bodies",
      RFC 2045, Innosoft, First Virtual, Nov 1996.

   [PNDN] Burger, E., "Partial Non-Delivery Notification", draft-ietf-
      vpim-pndn-00.txt, Work in Progress, July 14, 2000.

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

   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
      3", BCP 9, RFC 2026, October 1996.

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

   [VPIM1] Vaudreuil, Greg, "Voice Profile for Internet Mail", RFC
         1911, Feb 1996.

   [VPIM2] Vaudreuil, Greg, Parsons, Glen, "Voice Profile for Internet
         Mail, Version 2", RFC 2421, September 1998.

6.   Acknowledgments

   The basis for this draft is <draft-ema-vpimv3-goals-02.txt>.

   The author gratefully acknowledges the authors of <draft-ema-vpimv3-
   goals-02.txt> and the input and feedback provided by the members of
   the EMA and IETF VPIM work groups.

7. Author's Address

   Emily Candell
   Comverse Network Systems
   200 Quannapowitt Parkway
   Wakefield, MA 01880
   Phone: +1-781-213-2324
   Email: emily@comversens.com

Candell         Informational - Expires: May 15, 2001        [Page 7]

                    Goals for Internet Voice Mail       November 2000

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

Candell         Informational - Expires: May 15, 2001        [Page 8]

Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/