Network Working Group E. Candell
Internet Draft Comverse
Document: draft-ietf-vpim-ivm-goals-06 March 19, 2004
Category: Informational
High-Level Requirements for Internet Voice Mail
<draft-ietf-vpim-ivm-goals-06>
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
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.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document describes the high-level requirements 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 the Voice Profile for Internet
Mail (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].
1. Conventions used in this document
The following terms have specific meaning in this document:
Candell Informational - Expires: September 19, 2004 [Page 1]
High-Level Requirements for Internet Voice Mail March 2004
"service" An operational service offered by a service provider
"application" A use of systems to perform a particular function
"terminal" The endpoint of a communication application
"goal" An objective of the standardization process
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
[RFC2119].
2. 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 SMTP [DRUMSMTP] 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 profile that
supports the needs of desktop applications and unified messaging
systems (including Internet Facsimile [EXFAX]). This profile 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.
3. Goals for Internet Voice Mail
3.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
Candell Informational - Expires: September 19, 2004 [Page 2]
High-Level Requirements for Internet Voice Mail March 2004
applications. Such interoperability MUST support systems which
combine multiple media types in a single message, as well as 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 interoperability with VPIM version 2 Voice Mail
Systems.
IVM MUST include new functionality to facilitate access to voice
mail messages from desktop applications.
Overall interoperability requires interoperability for all message
elements: body parts deemed essential for message validity 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.
3.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, at least one mandatory codec MUST be
defined. The mandatory codec(s) SHOULD be widely available on
desktops. For interoperability with VPIM version 2 systems, IVM
applications MAY also support the VPIM v2 mandatory codec, 32KADPCM
[ADPCM and G726-32].
Any codecs included in the IVM specification SHOULD meet the
following criteria:
- Availability on desktops: Codecs SHOULD be available on most
platforms
Candell Informational - Expires: September 19, 2004 [Page 3]
High-Level Requirements for Internet Voice Mail March 2004
- Source code availability: Source code SHOULD be readily
accessible
- Decoding complexity: All codecs MUST be low complexity to
decode
- Encoding complexity: Some of the codecs MUST be low
complexity to encode.
- Bit rate: IVM SHOULD 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.
Voice Content MUST always be contained in an audio/basic content-
type unless the originator is aware that the recipient can handle
other content. 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 the IVM specification to support
environments in which the sender is aware of the optimal encoding
and format for the recipient.
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 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.
To support devices that 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.
Desktop implementation of IVM MUST support attachments of any media
type.
3.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, and also provision
for additional functionality that may be supported by more complex
systems. IVM MUST define a mechanism for identifying essential
Candell Informational - Expires: September 19, 2004 [Page 4]
High-Level Requirements for Internet Voice Mail March 2004
content 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 MAY be
able to receive the VPIM version 2 32KADPCM codec [ADPCM and G726-
32], and MUST gracefully handle the case where a legacy receiving
system does not support the IVM codecs.
3.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 and MAY define media specific status
codes and strings to handle non-delivery of these body parts.
3.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.
3.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 2822 [DRUMSIMF] except those that
prevent the profile from meeting other IVM goals.
Candell Informational - Expires: September 19, 2004 [Page 5]
High-Level Requirements for Internet Voice Mail March 2004
- 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.
3.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
systems.
3.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.
3.5 Security Considerations
To facilitate security, IVM MUST support authenticated and/or
encrypted voice messages. In addition, IVM MUST adhere to the
security issues identified in VPIM v2 [VPIM2] and in the other RFCs
referenced by this document, especially SMTP [DRUMSMTP], Internet
Message Format [DRUMSIMF] and MIME [MIME1].
4. Normative 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 3463,
January, 2003.
[DRUMSMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821 ,
April 2001.
Candell Informational - Expires: September 19, 2004 [Page 6]
High-Level Requirements for Internet Voice Mail March 2004
[DRUMSIMF] Resnick, P., "Internet Message Format", RFC 2822, April
2001.
[EXFAX] Masinter, L., Wing, D., "Extended Facsimile Using Internet
Mail", RFC 2532, Xerox Corporation, Cisco Systems, March 1999.
[G726-32] 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).
[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.
[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.
5. Acknowledgments
This document is the final result of an evolving requirements
document that started with VPIM v3 and evolved into an alternative
specification for a different (i.e., end-to-end instead of server-
to-server) application. The basis for this document is <draft-ema-
vpimv3-goals-02.txt> written by Laile Di Silvestro and Rod Miles.
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.
6. Author's Address
Emily Candell
Comverse
200 Quannapowitt Parkway
Wakefield, MA 01803
Phone: +1-781-213-2324
Email: emily.candell@comverse.com
Candell Informational - Expires: September 19, 2004 [Page 7]
High-Level Requirements for Internet Voice Mail March 2004
Full Copyright Statement
Copyright (C) The Internet Society (2004). 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, 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.
Candell Informational - Expires: September 19, 2004 [Page 8]
