Document: draft-ietf-vpim-ivm-goals-06 Reviewer: Spencer Dawkins Date: March 29, 2004 * This draft is on the right track but has open issues, described in the review. The biggest "open issue" is that this requirements document has some really vague "MUSTs" that need to be spelled out in more detail. For example, "and MUST gracefully handle the case where a legacy receiving system does not support the IVM codecs" - if the working group is going to use this document as a filter for proposals that don't meet the MUSTs, how would anyone know whether a proposal meets this MUST? In general, the requirements that include the words "specifically, this includes" are fine. It's the ones that don't include these words that have problems! My impression is that most of the people who have provided comments on the draft probably understand the context, which is fine for the working group but not-so-fine for reviewers outside the working group. ---------------------------Notes------------------------ 1. Conventions used in this document The following terms have specific meaning in this document: Spencer: the definition for "terminal" is helpful, but the others seem vague or circular (service = service). I wouldn't mind seeing a definition for "unified messaging". "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 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 Spencer: is this saying that VPIM2 was originally intended, or that VPIM1 was originally intended? I'm reading it as VPIM2, but the rule for English is to bind "that" to the closest noun (VPIM1). Suggest "and was originally" if it's VPIM2. 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 Spencer: if you have a citation for this statement, it would be nice to share it. 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 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. Spencer: "interoperability" doesn't seem to have a definition of what "operations" are included or excluded. It's defined by what it's between, not by what it includes. This could be a lot clearer. 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. Spencer: I'm not a genius of VPIM, but am wondering why this is only a SHOULD - if you could add a sentence, that would be helpful to me. 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 Spencer: this SHOULD NOT is surprisingly vague, given current desktop processing capabilities. 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 - 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 Spencer: This minimum set really should be spelled out here. Is it really not known at this time, or is it too controversial to agree on, or ??? 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 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 Spencer: "gracefully" should be spelled out a lot more clearly, for a MUST requirement. Is discarding the message without crashing "graceful"? system does not support the IVM codecs. 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 Spencer: the following list is wonderful, and is exactly what this document needs more of - everybody "knows" what the other lists should contain, but it isn't spelled out, even for MUST requirements. We're begging for candidate proposals that don't solve the same problems. common user practices for mail messages: storing them in databases, retransmission, forwarding, creation of mail digests, and replying to messages using non-audio equipment. 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 written by Laile Di Silvestro and Rod Miles.