idnits 2.17.1 draft-ietf-vpim-ivm-goals-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([VPIM2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 19, 2004) is 7341 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'ADPCM' is defined on line 290, but no explicit reference was found in the text == Unused Reference: 'AMIS-A' is defined on line 293, but no explicit reference was found in the text == Unused Reference: 'AMIS-D' is defined on line 296, but no explicit reference was found in the text == Unused Reference: 'G726-32' is defined on line 311, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2422 (ref. 'ADPCM') (Obsoleted by RFC 3802) ** Obsolete normative reference: RFC 2821 (ref. 'DRUMSMTP') (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (ref. 'DRUMSIMF') (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 1911 (ref. 'VPIM1') (Obsoleted by RFC 2421, RFC 2422, RFC 2423) ** Obsolete normative reference: RFC 2421 (ref. 'VPIM2') (Obsoleted by RFC 3801) Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Candell 3 Internet Draft Comverse 4 Document: draft-ietf-vpim-ivm-goals-06 March 19, 2004 5 Category: Informational 7 High-Level Requirements for Internet Voice Mail 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 [RFC2026]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. Internet-Drafts are draft documents valid for a maximum of 19 six months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 This memo provides information for the Internet community. This memo 28 does not specify an Internet standard of any kind. Distribution of 29 this memo is unlimited. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 This document describes the high-level requirements for Internet 38 Voice Mail (IVM) and establishes a baseline of desired functionality 39 against which proposed MIME profiles for Internet Voice Messaging 40 can be judged. IVM is an extension of the Voice Profile for Internet 41 Mail (VPIM) version 2 [VPIM2] designed to support interoperability 42 with desktop clients. Other goals for this version of VPIM include 43 expanded interoperability with unified messaging systems, 44 conformance to Internet standards, and backward compatibility with 45 voice messaging systems currently running in a VPIM enabled 46 environment. This document does not include goals that were met 47 fully by VPIM version 2 [VPIM2]. 49 1. Conventions used in this document 51 The following terms have specific meaning in this document: 53 "service" An operational service offered by a service provider 54 "application" A use of systems to perform a particular function 55 "terminal" The endpoint of a communication application 56 "goal" An objective of the standardization process 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 60 this document are to be interpreted as described in RFC-2119 61 [RFC2119]. 63 2. Introduction 65 Until recently, voice mail and call answering services were 66 implemented as stand-alone proprietary systems. Today, standards 67 such as the Voice Profile for Internet Mail (VPIM) enable 68 interoperability between such systems over the Internet. VPIM 69 version 1 [VPIM1] was experimental and was a first attempt at a 70 Voice Profile for Internet Mail, but is now classified as 71 Historical. VPIM Version 2 [VPIM2] is an improvement on VPIM version 72 1 that was originally intended to provide interoperability between 73 voice messaging systems only. It describes a messaging profile that 74 standardizes the exchange of voice mail over an IP messaging network 75 using SMTP [DRUMSMTP] and MIME [MIME1]. 77 Because the number of desktop boxes is growing rapidly and will soon 78 approach the number of desktop telephones, it is essential to 79 consider the requirements of desktop email client applications 80 (including, but not limited to, MIME-compliant email clients). With 81 the trend toward integration of voice mail and email through unified 82 messaging (UM), it is now necessary to define a profile that 83 supports the needs of desktop applications and unified messaging 84 systems (including Internet Facsimile [EXFAX]). This profile is 85 being referred to as Internet Voice Mail (IVM). 87 This document defines the goals for Internet Voice Mail. This 88 standard will support the interchange of voice messages between 89 voice mail systems, unified messaging systems, email servers, and 90 desktop client applications. The desktop client application is of 91 particular and important interest to IVM. This document will also 92 expand the offerings of service providers by facilitating access to 93 voice mail from a web client. 95 3. Goals for Internet Voice Mail 97 3.1 Interoperability 99 Enhanced interoperability is the primary goal of IVM. The profile 100 MUST facilitate interoperability between voice mail systems, unified 101 messaging systems, Internet email servers, and desktop client 102 applications. Such interoperability MUST support systems which 103 combine multiple media types in a single message, as well as legacy 104 voice mail and email systems. It MUST allow the ability to 105 accommodate varying capabilities of the voice mail, unified 106 messaging and email systems. Furthermore, IVM MUST be compatible 107 with Internet Fax (extended mode) proposed standards and VPIM 108 messages that contain fax body parts. 110 To have "interoperability" means that an IVM compliant sender 111 attempting to send to a recipient will not fail because of 112 incompatibility. IVM MUST support interoperability amongst the 113 systems listed below: 114 - Desktop Email client applications 115 - IVM-capable Voice Mail systems 116 - IVM-capable unified messaging systems 117 - Traditional email servers 118 And SHOULD support interoperability with VPIM version 2 Voice Mail 119 Systems. 121 IVM MUST include new functionality to facilitate access to voice 122 mail messages from desktop applications. 124 Overall interoperability requires interoperability for all message 125 elements: body parts deemed essential for message validity MUST be 126 preserved, essential information MUST be provided in a form that is 127 accessible by the users, status codes [CODES] MUST be understood, 128 and operations that are standard for each system SHOULD be 129 supported. 131 3.1.1 Interoperability with Desktop Email Client Applications 133 Desktop email applications are typically text based. The ability to 134 listen to, reply to, forward, and generate voice mail messages from 135 a traditional desktop environment is a relatively new development. 136 To accommodate current use and future developments in this area, IVM 137 MUST provide features to support access to voice mail messages from 138 the desktop and other email-reading devices. Also, web access to 139 voicemail SHOULD be supported from the desktop. 141 IVM SHOULD NOT require desktop email applications to possess a large 142 amount of processing power, and a base level implementation MUST 143 interoperate, even if it does not offer complex processing. In order 144 to support interoperability, at least one mandatory codec MUST be 145 defined. The mandatory codec(s) SHOULD be widely available on 146 desktops. For interoperability with VPIM version 2 systems, IVM 147 applications MAY also support the VPIM v2 mandatory codec, 32KADPCM 148 [ADPCM and G726-32]. 150 Any codecs included in the IVM specification SHOULD meet the 151 following criteria: 152 - Availability on desktops: Codecs SHOULD be available on most 153 platforms 154 - Source code availability: Source code SHOULD be readily 155 accessible 156 - Decoding complexity: All codecs MUST be low complexity to 157 decode 158 - Encoding complexity: Some of the codecs MUST be low 159 complexity to encode. 160 - Bit rate: IVM SHOULD specify a codec with low bit rate for 161 devices (i.e., wireless) that do not have much space/bandwidth. 162 - Voice Over IP support: IVM SHOULD specify a codec that 163 supports Voice over IP implementations. 165 Voice Content MUST always be contained in an audio/basic content- 166 type unless the originator is aware that the recipient can handle 167 other content. To enable future support of other formats, IVM SHOULD 168 provide identification of the codec used without requiring 169 interpretation of an audio format. IVM MAY allow audio encodings and 170 formats that are not identified in the IVM specification to support 171 environments in which the sender is aware of the optimal encoding 172 and format for the recipient. 174 To address performance and bandwidth issues, IVM MAY support 175 streaming of IVM audio to the desktop. IVM MAY explicitly support 176 formats other than raw audio to facilitate streaming. 178 Because most email readers are text/html based and because many 179 devices are not capable of recording audio content, IVM MUST allow 180 inclusion of text body parts in a voice message. IVM SHOULD NOT 181 explicitly prohibit other media types as long as critical content is 182 identified and minimal discard rules are specified. 184 To support devices that have applications dedicated to specific 185 media types or that are not capable of handling specific content, 186 IVM SHOULD define a way to describe the content of the message, 187 indicating how the content can be accessed. 189 Desktop implementation of IVM MUST support attachments of any media 190 type. 192 3.1.2 Interoperability with IVM-capable Voice Messaging Systems 194 Voice messaging systems are generally implemented as special-purpose 195 machines that interface to a telephone switch and provide call 196 answering and voice messaging services. VPIM version 2 was designed 197 to support interoperability between such systems and remains the 198 best messaging profile for this purpose. 200 To support interoperability between IVM voice messaging systems and 201 other compliant systems, IVM SHOULD have a minimum set of required 202 features that will guarantee interoperability, and also provision 203 for additional functionality that may be supported by more complex 204 systems. IVM MUST define a mechanism for identifying essential 205 content and status codes [CODES] indicating that a message could not 206 be delivered due to capability differences. 208 NOTE: IVM SHOULD provide some level of interoperability with VPIM 209 version 2 voice messaging systems. In order to support mimimal 210 interoperability between IVM and VPIM version 2, IVM systems MAY be 211 able to receive the VPIM version 2 32KADPCM codec [ADPCM and G726- 212 32], and MUST gracefully handle the case where a legacy receiving 213 system does not support the IVM codecs. 215 3.1.3 Interoperability with IVM-capable Unified Messaging Systems 217 Unified messaging solutions typically leverage common store, 218 directory, and transport layers to provide greater interoperability 219 and accessibility to a variety of media content. They support 220 creation of and access to voicemail, email, and fax messages from a 221 single user interface. 223 To accommodate the common functionality of unified messaging 224 systems, IVM MUST support the inclusion of body parts containing 225 different media types. It MUST also handle messages that contain 226 VPIM messages as attachments to messages of another type (such as 227 multipart/mixed), and VPIM messages that contain attachments of 228 another type. 230 To provide interoperability with systems that cannot handle a 231 particular content type, IVM MUST provide a mechanism for 232 identifying critical content and MAY define media specific status 233 codes and strings to handle non-delivery of these body parts. 235 3.1.4 Interoperability with Traditional Email Servers 237 Traditional email servers are those that support only textual media 238 as inline content. IVM MUST interoperate consistently with the 239 current Internet mail environment. If an IVM message arrives in 240 users' mailboxes, IVM MUST provide a mechanism to interoperate with 241 common user practices for mail messages: storing them in databases, 242 retransmission, forwarding, creation of mail digests, and replying 243 to messages using non-audio equipment. 245 3.2 Conformance to Existing Standards 247 It is the goal of IVM to conform as closely as possible to existing 248 standards while meeting the other goals defined in this document. 250 - Restrictions: The profile SHOULD impose as few restrictions as 251 possible to existing Internet mail standards. In particular, it MUST 252 support all elements of RFC 2822 [DRUMSIMF] except those that 253 prevent the profile from meeting other IVM goals. 255 - Additions: The profile SHOULD make as few additions as 256 possible to existing internet mail standards. It SHOULD adhere to 257 existing desktop conventions in desktop-related areas such as file 258 extensions. If it is necessary to define new MIME types or sub- 259 types, the IVM work group SHOULD propose terms that are already 260 standard or in common use in the desktop environment. 262 3.3 Backward Compatibility 264 This profile SHOULD provide backward compatibility with VPIM version 265 2 to an extent where the functionality required to meet the goals of 266 this profile is not compromised. Where backward compatibility is 267 not possible, IVM SHOULD provide and define a minimal set of rules 268 and status codes for handling non-delivery of IVM messages resulting 269 from interoperability with VPIM version 2 systems and other legacy 270 systems. 272 3.4 Robustness 274 IVM MUST be usable in an environment in which there exist legacy 275 gateways that do not understand MIME. Core features and critical 276 data MUST not be lost when messages pass through AMIS gateways 277 [AMIS-A and AMIS-D]. IVM SHOULD allow interoperability with 278 recipient devices and gateways that have limited buffering 279 capabilities and cannot buffer all header information. 281 3.5 Security Considerations 283 To facilitate security, IVM MUST support authenticated and/or 284 encrypted voice messages. In addition, IVM MUST adhere to the 285 security issues identified in VPIM v2 [VPIM2] and in the other RFCs 286 referenced by this document, especially SMTP [DRUMSMTP], Internet 287 Message Format [DRUMSIMF] and MIME [MIME1]. 289 4. Normative References 290 [ADPCM] G. Vaudreuil and G. Parsons, "Toll Quality Voice - 32 kbit/s 291 ADPCM: MIME Sub-type Registration", RFC 2422, September 1998 293 [AMIS-A] Audio Messaging Interchange Specifications (AMIS) - Analog 294 Protocol Version 1, Issue 2, February 1992. 296 [AMIS-D] Audio Messaging Interchange Specifications (AMIS) - Digital 297 Protocol Version 1, Issue 3 August 1993. 299 [CODES] Vaudreuil, G. "Enhanced Mail System Status Codes", RFC 3463, 300 January, 2003. 302 [DRUMSMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821 , 303 April 2001. 305 [DRUMSIMF] Resnick, P., "Internet Message Format", RFC 2822, April 306 2001. 308 [EXFAX] Masinter, L., Wing, D., "Extended Facsimile Using Internet 309 Mail", RFC 2532, Xerox Corporation, Cisco Systems, March 1999. 311 [G726-32] CCITT Recommendation G.726 (1990), General Aspects of 312 Digital Transmission Systems, Terminal Equipment - 40, 32,24,16 313 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM). 315 [MIME1] N. Freed and N. Borenstein, "Multipurpose Internet Mail 316 Extensions (MIME) Part One: Format of Internet Message Bodies", 317 RFC 2045, Innosoft, First Virtual, Nov 1996. 319 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 320 3", BCP 9, RFC 2026, October 1996. 322 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 323 Requirement Levels", BCP 14, RFC 2119, March 1997 325 [VPIM1] Vaudreuil, Greg, "Voice Profile for Internet Mail", RFC 326 1911, Feb 1996. 328 [VPIM2] Vaudreuil, Greg, Parsons, Glen, "Voice Profile for Internet 329 Mail, Version 2", RFC 2421, September 1998. 331 5. Acknowledgments 333 This document is the final result of an evolving requirements 334 document that started with VPIM v3 and evolved into an alternative 335 specification for a different (i.e., end-to-end instead of server- 336 to-server) application. The basis for this document is written by Laile Di Silvestro and Rod Miles. 339 The author gratefully acknowledges the authors of and the input and feedback provided by the members of 341 the EMA and IETF VPIM work groups. 343 6. Author's Address 345 Emily Candell 346 Comverse 347 200 Quannapowitt Parkway 348 Wakefield, MA 01803 349 Phone: +1-781-213-2324 350 Email: emily.candell@comverse.com 351 Full Copyright Statement 353 Copyright (C) The Internet Society (2004). All Rights Reserved. 355 This document and translations of it may be copied and furnished to 356 others, and derivative works that comment on or otherwise explain it 357 or assist in its implementation may be prepared, copied, published 358 and distributed, in whole or in part, without restriction of any 359 kind, provided that the above copyright notice and this paragraph 360 are included on all such copies and derivative works. However, this 361 document itself may not be modified in any way, such as by removing 362 the copyright notice or references to the Internet Society or other 363 Internet organizations, except as needed for the purpose of 364 developing Internet standards in which case the procedures for 365 copyrights defined in the Internet Standards process must be 366 followed, or as required to translate it into, or as required to 367 translate it into languages other than English. 369 The limited permissions granted above are perpetual and will not be 370 revoked by the Internet Society or its successors or assigns. 372 This document and the information contained herein is provided on an 373 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 374 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 375 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 376 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 377 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.