idnits 2.17.1 draft-vaudreuil-um-issues-00.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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) ** There are 217 instances of too long lines in the document, the longest one being 38 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 443 has weird spacing: '...r, this docum...' == Line 446 has weird spacing: '...for the purpo...' -- 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 (February 21, 2002) is 8098 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'VPIM2' on line 382 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Greg Vaudreuil 2 Internet Draft Lucent Technologies 3 Expires in six months February 21, 2002 5 Messaging profile for telephone-based Messaging clients 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 This document is an Internet Draft. Internet Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its Areas, and 16 its Working Groups. Note that other groups may also distribute working 17 documents as Internet Drafts. 19 Internet Drafts are valid for a maximum of six months and may be 20 updated, replaced, or obsoleted by other documents at any time. It is 21 inappropriate to use Internet Drafts as reference material or to cite 22 them other than as a "work in progress". 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Abstract 32 This document discussed issues and requirements for a profile of the 33 IMAP 4, message submission, and notification protocols for use by 34 telephone user interfaces delivering the traditional voice mail user 35 experience. Experience with IMAP 4 and voice mail systems has shown 36 quite a few limitations that may be addressed by protocol extensions and 37 standardized conventions between clients and servers. 39 Copyright Notice 41 Copyright (C) The Internet Society (2002). All Rights Reserved. 43 Table of Contents 45 1. OVERVIEW..........................................................3 46 2. IMAP ISSUES.......................................................4 47 2.1 Performance Issues ..............................................4 48 2.2 Functional Limitations ..........................................5 49 3. MESSAGE SUBMISSION AND MESSAGE DELIVERY ISSUES....................8 50 3.1 Server-assisted user message forwarding .........................8 51 3.2 Quota-by-context ................................................9 52 3.3 Future Delivery .................................................9 53 4. NOTIFICATION......................................................9 54 4.1 Notification Support ............................................9 55 5. ACKNOWLEDGMENTS..................................................12 56 6. AUTHORS' ADDRESSES...............................................12 57 7. FULL COPYRIGHT NOTICE............................................12 58 1. Overview 60 In the open standards arena, IMAP 4 is the protocol most commonly 61 identified for use by a TUI for access to messages in a voice mailbox. 62 IMAP4 was developed primarily as an access mechanism to text-based email 63 and has evolved in many ways to support multi-media content. The 64 protocol is extensible and a large number of extensions have been made 65 or are needed to full support the TUI experience of voice messaging. 67 SMTP used for the transmission of voice messages from a telephone 68 answering application needs to be optimized through use of various 69 extensions and new conventions to perform at a level required for a 70 large distributed system. Greeting and spoken name play needs to be 71 provided, either through LDAP, LDAP extensions, or pointers to alternate 72 streaming play mechanisms. 74 IMAP4 limitations fall into two broad categories, performance and 75 functionality. Most of these can be addressed by specific 76 implementation choices, standards extensions, and standardized 77 conventions shared between the message store and the client. 79 Many limitations of commercial message store solutions are not IMAP 80 protocol issues, but rather underlying logic necessary to support the 81 voice mail user experience. Lucent's proprietary message server 82 supports these functions today and will continue to support these 83 mechanisms when delivered over standard protocols. 85 2. IMAP Issues 87 2.1 Performance Issues 89 2.1.1 Real-time playback 91 The IMAP protocol itself does not provide streaming in the strict 92 definition of the term. It does provide for the incremental download of 93 content in blocks. Most IMAP clients do not support this behavior and 94 instead download the entire contents into a temporary file to be passed 95 to the application. 97 There are several approaches to achieve real-time playback. The first 98 approach is to implement an IMAP client that can pass data incrementally 99 to the application as it is received from the network. The application 100 can then read bytes from the network as needed to maintain a play buffer 101 and not require the full download of contents. This approach may 102 require server-side development to efficiently support partial download. 103 (Avoid re-opening file and seeking to requested pointer) 105 Alternately, the proposed IMAP channel extension can be used by the 106 client to request that the servers make the selected content available 107 via an alternate transport mechanism. In this way a client can ask the 108 server to make the voice data available to the client via a streaming 109 media protocol such as RTSP. This requires support on the client and 110 server of a common streaming protocol. 112 Third, given sufficient bandwidth between client and back-end data 113 store, an implementation may download the entire contents before playing 114 without noticeable latency. Combined with client-side caching to avoid 115 re-fetches, this strategy may work with existing message servers. 117 It is clear that a choice be made common to the server and the client to 118 provide this functionality. 120 2.1.2 Data Size Inflation due to Text Based Transport 122 Standard IMAP4 uses a text-based data representation scheme where all 123 data is represented in a form that looks like text, that is, voice data 124 must be encoded using "base 64" into a transport encoding that adds 30% 125 to the size of a message. When downloading or appending messages to the 126 server, substantial additional bandwidth is utilized. 128 Proposed Solutions 129 Where IMAP channel is appropriate, the external channel may be binary 130 capable; that is; the external access may not require re-encoding. Such 131 mechanisms as HTTP, FTP, or RTSP are available for this download. 133 The IMAP binary extension standards proposal extends the IMAP fetch 134 command to retrieve data in the binary form. This is especially useful 135 for large attachments and other binary components. Binary in 136 conjunction with a streaming client implementation may be an attractive 137 alternative to the Channel extension. 139 2.2 Functional Limitations 141 In addition to performance challenges, there are a number of functional 142 deficiencies in the IMAP protocol. 144 2.2.1 Mailbox Summary (Per-context counters in mailbox status command) 146 The common TUI prompt "you have two new voice messages, six unheard 147 messages, and one new fax message" requires more information than is 148 made available by IMAP. The IMAP status command provides a count of new 149 and total messages with standardized attributes extracted from the 150 message headers. This pre-determined information does not include 151 information about the message type. Without defined conventions to the 152 status command, a client would have to download the header for each 153 message to determine its type. (Are flags made available through the 154 list command? Or do they need to be queried independently?) 156 In standards-land, there is an effort do define an extensible mechanism 157 for sending arbitrary message summary data in the LIST command. With 158 proper MTA support for the necessary message-context attribute and 159 support for reading the flags, a single command can extract enough data 160 to count the messages in various categories. For adequate performance, 161 the MTA must pre-parse the messages to extract the necessary information 162 into an index for this request as messages are deposited. 164 Without the standards, it is possible to use multiple virtual folders to 165 achieve similar functionality. The "inbox" can be sub-divided into 166 virtual unheard, new, unheard fax, and new fax message sub-folders. A 167 folder status command issued against each sub-folder would yield the 168 appropriate count. An MTA may implement these as truly separate folders 169 or may present these as virtual folders to the client while storing the 170 messages in a single inbox. 172 2.2.2 Sort by message context 174 Voice mailboxes commonly present new voice messages first and then new 175 fax messages within a single logical queue. This requires the ability 176 to sort the messages by message context. 178 In standards-land, there is an effort do define an extensible sort 179 mechanism for sorting on arbitrary header contents. 181 An alternative is for the client to download the headers of all messages 182 and perform a local sort. This works where mailboxes have fewer than a 183 couple-dozen messages. 185 A further alternative uses separate virtual folders to hold messages of 186 different types and status, using the client to construct the expected 187 user experience. 189 2.2.3 QUOTA by message context 191 Voice mail systems' mailboxes commonly contain voice and fax messages. 192 Sometimes, such systems also support E-mail messages (text, text with 193 attachments) in addition to voice messages. Similarly to the requirement 194 for sort by message context - - quota management is also required per 195 message context. 197 One possible use case is to prevent multiple (large) messages of one 198 type (e.g. E-mail messages) to consume all available quota so that 199 messages of other type (e.g. voice or fax messages) cannot be further 200 deposited to the mailbox. 202 In standards-land, there is an effort to define an extension to the 203 QUOTA IMAP command to support multiple message contexts. (In addition, 204 there is a parallel effort to enhance the SMTP SIZE extension for the 205 same purpose). 207 2.2.4 Status of multiple mailboxes 209 Extension mailbox support requires the ability to efficiently status a 210 mailbox other than the one currently logged into. This facility is 211 required to support submailboxes, where a common feature is to check 212 whether other submailboxes in the same family group have new messages. 214 Current mechanisms are limited to logging into each of set of mailboxes, 215 checking status, logging out, and repeating until all submailboxes are 216 statused. 218 2.2.5 Outbox, Sent Items, Delete Items, Expired items, Drafts 220 IMAP provides only a single standardized folder inbox. Applications 221 that provide features such as check receipt, deleted message recovery, 222 resave, and others require the ability to access messages in pre- 223 determined mailboxes with specific behaviors. This functionality does 224 not require new protocol per-se, but standardized usage and naming 225 conventions necessary for interoperability. It required that the server 226 provide the underlying logic to support these special folders including 227 automatic insertion, scheduled copying, and periodic deletion. 229 2.2.6 CLID Restriction / Disclosure authorization 231 Many calling features are dependent upon collected caller-ID 232 information. Trusted clients such as the TUI, WUI, and WAP may have 233 access to restricted caller-ID information for such purposes as 234 callback. Untrusted clients must not receive this information. A 235 mechanism for communicating "trust" between the client and the server is 236 required to deliver this information to the end-user when appropriate. 238 Some IMAP 4 servers can be configured to recognize certain clients by IP 239 address and apply necessary CLID restriction treatment such as hiding 240 addresses where CLI restriction has been indicated in the message. 242 For systems operating in a closed network, the system may rely upon 243 serving only trusted clients that protect the identity of the sender 244 based on per-message markings. This usage requires custom proxies to 245 use for Internet-facing services such as downloads by PC thick-clients. 247 2.2.7 Greeting Access and Play 249 Voice messaging systems store multiple audio greetings files per user to 250 play upon answering the phone. This information is logically directory 251 information, but the size, access patterns, and streaming requirements 252 exceed the capabilities of more directory access protocols and 253 underlying servers. 255 Rather than create a new specialized store, it is common to store 256 greetings as messages in a hidden or special folder. As such, it is 257 natural to use the IMAP protocol for access and update of these 258 greetings. This provides the ability to update the greeting easily 259 using the IMAP command. 261 Access to the greetings requires a form of super-user access to log into 262 the called party mailbox and extract the greeting. Through 263 conventions, a given server or set of servers identified by IP address 264 or login password may be granted privileged access to the mailbox 265 contents. 267 2.2.8 Atomic Commit of Telephone Answering Messages into Inbox 269 Voice messaging service has provided a high degree of reliability and 270 performance for telephone answering messages. The expectation is that 271 once the caller has hung-up, the messages is in the mailbox and 272 available for review. Traditional Internet mail architecture suggests 273 these messages should be sent to the mailbox via SMTP. This approach 274 has two limitations. The first and most manageable is that the message 275 forwarding may take more time than is tolerable by the subscriber. The 276 second is that the message may fail to be delivered to the mailbox, and 277 because there is no way to return notice to the caller, the message is 278 "lost". 280 The standards community is working on an alliterative to SMTP called 281 Local Message Transport Protocol. This protocol addresses a number of 282 limitations in SMTP when used to provide atomic delivery to a mailbox. 283 The failure modes in this proposal are carefully controlled, as are 284 issues of per-message quota enforcement and message storage quota- 285 override for designated administrative messages. 287 An alternative approach is to mis-use the IMAP protocol slightly and use 288 an IMAP append command to deposit a message directly into the 289 subscriber's inbox. This append must be done by a special super-user 290 with write permissions into the subscribers mailbox. Further, the 291 message store must be able to trigger notification events upon insertion 292 of a message into the mailbox via the Append command. The historic 293 limitation on using IMAP4 for message sending involves the inability of 294 IMAP to communicate a full SMTP envelope. For telephone answering, 295 these limitations are not significant. 297 2.2.9 Multiple Access to Mailbox 299 If the telephone answering application client uses IMAP4 for greeting 300 access and message deposit, it is essential that the server provide 301 support for simultaneous login. It is common in VoiceMail for an 302 incoming call to be serviced by the telephone answering application 303 client at the same time the subscribers is logged into their mailbox. 304 Further, new applications such as WEB and WAP access to voicemail may 305 entail simultaneous login sessions, one from the TUI client and one from 306 the visual client. 308 The standard does not preclude multiple accesses to a mailbox, but it 309 does not explicitly support this practice. The lack of explicit support 310 requires the server and client to adhere to a common set of practices 311 and behaviors to avoid undesirable and unpredictable behaviors. RFC 312 2180 describes a candidate set of conventions necessary to support this 313 multiple-access technique. It is not a standard. 315 3. Message Submission and Message Delivery Issues 317 3.1 Server-assisted user message forwarding 319 It is common to forward messages, or to reply to messages with a copy of 320 the attached content. Today such forwarding requires the sender to 321 download a complete copy of the original message, attach it to the reply 322 or forward message, and resubmit the result. For large messages, this 323 represents a substantial amount of bandwidth and processing. For 324 clients connected via long-thin pipes, alternatives are required. 326 One approach is to define an extension to message submission to request 327 the submission server to resolve embedded URL's within a message before 328 relaying the message to the final destination. 330 3.2 Quota-by-context 332 It is common in a unified messaging system to offer separate quota's for 333 each of several message contexts to avoid the condition where a flood of 334 email fills the mailbox and prevents the subscriber from receiving voice 335 messages via the telephone. It is necessary to extend the protocols to 336 support the reporting of the "mailbox full" status based on the context 337 of the submitted message. 339 Clear security issues are involved to prevent the mis-identification of 340 a message context for the purpose of intentionally filling a subscribers 341 mailbox. It is envisioned that the message submission protocol will 342 support authentication of trusted submission agents authorized to submit 343 distinguished messages. 345 3.3 Future Delivery 347 Traditionally messages sent with "future delivery" are held in the 348 recipients client "outbox" or equivalent until the appointed submission 349 time. Think clients used for WEB or TUI do not have such persistent 350 storage and must rely upon server-based outbox queues. 352 Such support requires extensions to message submission protocols to 353 identify a message as requiring queuing for future delivery. Extensions 354 to IMAP4 or conventions are required to view and manipulate the outbound 355 queue, for such purposes as cancelling a future message. Server support 356 for managing such a queue is required such that message are sent when 357 they are intended. 359 4. Notification 361 4.1 Notification Support 363 Voicemail systems traditionally notify subscribers on certain events 364 happening in their mailbox. For example, it is common to send an SMS, or 365 a pager notification for new message arrival, when messages have been 366 read (and are not considered "new" anymore), mailbox full etc. 368 When implemented over IMAP-based message stores, voice mail system need 369 to be notified about these events. Furthermore, when other applications 370 are accessing/manipulating the mailbox, it is desirable that a 371 notification component (which is sometimes part of the voicemail 372 application) gets notifications from the message store about these 373 events, so that it can produce the desired user notification. 375 The standards community is working on a standard for "Simple 376 Notification and Alarm Protocol (SNAP)" that defines the expected 377 behavior of the message store for various events, much of them triggered 378 by IMAP commands. 380 4.1.1 References 382 [VPIM2] Vaudreuil, Greg, Parsons, Glenn, "Voice Profile for Internet Mail, 383 Version 2", RFC 2421, September 1998. 385 "IMAP4 Binary Content Extension", 01/18/2002, 388 "IMAP4 Channel Transport Mechanism", 11/27/2001, 391 "LMTP Service Extension for Ignoring Recipient Quotas", 08/30/2001, 392 394 "Message Context for Internet Mail", 06/05/2001, 397 "Simple Notification and Alarm Protocol (SNAP)", 12/20/2001 400 RFC 2476, Message Submission. R. Gellens, J. Klensin. December 1998. 401 (Status: PROPOSED STANDARD) 403 RFC 2033, Local Mail Transfer Protocol. J. Myers. October 1996. 404 (Status: INFORMATIONAL) 406 RFC 2086, IMAP4 ACL extension. J. Myers. January 1997. (Status: 407 PROPOSED STANDARD) 409 RFC 2087 IMAP4 QUOTA extension. J. Myers. January 1997. (Status: 410 PROPOSED STANDARD) 412 RFC 2180, IMAP4 Multi-Accessed Mailbox Practice. M. Gahrns. July 1997. 413 (Status: INFORMATIONAL) 415 RFC 2221, IMAP4 Login Referrals. M. Gahrns. October 1997. (Status: 416 PROPOSED STANDARD) 418 5. Acknowledgments 420 Ari Erev and Naom Shapira have contributed substantial requirements to 421 this document. 423 6. Authors' Addresses 425 Gregory M. Vaudreuil 426 Lucent Technologies 427 7291 Williamson Rd 428 Dallas, TX 75214 429 United States 431 Phone/Fax: +1-972-733-2722 432 Email: GregV@ieee.org 434 7. Full Copyright Notice 436 "Copyright (C) The Internet Society (2002). All Rights Reserved. 438 This document and translations of it may be copied and furnished to 439 others, and derivative works that comment on or otherwise explain it or 440 assist in its implementation may be prepared, copied, published and 441 distributed, in whole or in part, without restriction of any kind, 442 provided that the above copyright notice and this paragraph are included 443 on all such copies and derivative works. However, this document itself 444 may not be modified in any way, such as by removing the copyright notice 445 or references to the Internet Society or other Internet organizations, 446 except as needed for the purpose of developing Internet standards in 447 which case the procedures for copyrights defined in the Internet 448 Standards process must be followed, or as required to translate it into 449 languages other than English. 451 The limited permissions granted above are perpetual and will not be 452 revoked by the Internet Society or its successors or assigns. 454 This document and the information contained herein is provided on an "AS 455 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 456 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 457 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 458 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 459 FITNESS FOR A PARTICULAR PURPOSE."