idnits 2.17.1 draft-burger-um-reqts-00.txt: ** The Abstract section seems to be numbered 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 document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 5 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 2002) is 8099 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 14 looks like a reference -- Missing reference section? '2' on line 68 looks like a reference -- Missing reference section? '3' on line 84 looks like a reference -- Missing reference section? '4' on line 85 looks like a reference -- Missing reference section? '5' on line 97 looks like a reference -- Missing reference section? '6' on line 97 looks like a reference -- Missing reference section? '7' on line 101 looks like a reference -- Missing reference section? '8' on line 164 looks like a reference -- Missing reference section? '9' on line 157 looks like a reference -- Missing reference section? '10' on line 164 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Burger 3 Internet Draft SnowShore Networks, Inc. 4 Document: draft-burger-um-reqts-00.txt February 2002 5 Category: Informational 6 Expires: August 2002 8 Internet Unified Messaging Requirements 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 [1]. 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 21 as reference material or to cite them other than as "work in 22 progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 1. Abstract 32 Internet Unified Messaging brings together the body of work done in 33 VPIM, FPIM, IMAPEXT, and other IETF work groups. The goal is to 34 provide a single infrastructure, mailbox, and set of interfaces for 35 a user to get, respond to, and manipulate all of their messages, no 36 matter what the media or source. This document describes the 37 requirements for providing such a service. 39 Discussion of this and related drafts are on the UM list. To 40 subscribe, send the message "subscribe um" to 41 majordomo@snowshore.com. The public archive is at 42 http://flyingfox.snowshore.com/um_archive/maillist.html. 44 2. Conventions used in this document 46 This document refers generically to the sender of a message in the 47 masculine (he/him/his) and the recipient of the message in the 48 feminine (she/her/hers). This convention is purely for convenience 49 and makes no assumption about the gender of a message sender or 51 Burger Informational - Expires August 2002 1 52 UM Requirements February 2002 54 recipient. 56 FORMATTING NOTE: Notes, such at this one, provide additional 57 nonessential information that the reader may skip without missing 58 anything essential. The primary purpose of these non-essential 59 notes is to convey information about the rationale of this document, 60 or to place this document in the proper historical or evolutionary 61 context. Readers whose sole purpose is to construct a conformant 62 implementation may skip such information. However, it may be of use 63 to those who wish to understand why we made certain design choices. 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 67 this document are to be interpreted as described in RFC-2119 [2]. 69 3. Introduction 71 Humans have had to contend with having multiple messaging systems 72 for different messaging modes. For example, I have a voice mail 73 account for voice messages, a fax store-and-forward service for fax 74 messages, and an e-mail account for Internet messages. 76 The IETF has successfully completed a considerable body of work 77 extending the highly successful non-real-time text messaging 78 service, SMTP. Extending the mail system for multimedia payloads 79 with MIME enabled the transport of voice and fax. The VPIM and IFAX 80 work groups, respectively, have produced a number of RFCs that focus 81 on voice mail and fax messaging and transport. This draft examines 82 the requirements for unified messaging systems. 84 There has been an evolution of using Internet Mail standards [3] for 85 the carriage of media-rich messages. MIME [4] introduces the basic 86 capability for transporting media-rich messages using Internet Mail. 87 Then there were a number of successful efforts to use Internet Mail 88 for supporting the transport of various media-specific message types 89 within closed environments. Leveraging this success, people started 90 to see how to integrate the closed environments into the Internet 91 Mail structure. The ultimate goal is Unified Messaging: a single 92 infrastructure, mailbox, and set of interfaces for a user to get all 93 of their messages. 95 The Voice Profile for Internet Mail defines a method for 96 transporting voice messages between voice messaging systems using 97 Internet Mail [5]. Likewise, the Extended Mode Fax [6] defines a 98 method for transporting fax messages between fax messaging terminals 99 using Internet Mail. 101 Simple Mode Fax [7] describes how one can deliver facsimile 102 documents using the Internet Mail infrastructure, including standard 103 Internet Mail clients. Said differently, the document brought 104 facsimile into the Internet Mail domain. 106 Burger Informational - Expires August 2002 2 107 UM Requirements February 2002 109 Likewise, Internet Voice Mail [8] describes how one can generate and 110 deliver voice messages using the Internet Mail infrastructure, 111 including standard Internet Mail clients. 113 With this set of developments, we are now in a position to gather 114 these standards and develop new protocols where needed to deliver 115 true unified messaging. 117 4. General Requirements 119 4.1. Reuse Existing Protocols 121 To the extent feasible, the unified messaging framework SHOULD use 122 existing protocols whenever possible. 124 4.2. Maintain Existing Protocol Integrity 126 In meeting requirement 4.1, the unified messaging framework MUST NOT 127 redefine the semantics of an existing protocol. 129 Said differently, we will not break existing protocols. 130 4.3. Reception Context 132 When the user receives a message, that message SHOULD receive the 133 treatment expected by the sender. For example, if the sender 134 believes he is sending a voice message, voice message semantics 135 should prevail. 137 4.4. Sending Context 139 When the user sends a message, she SHOULD be able to specify the 140 message context. That is, whether the network should treat the 141 message as an Internet Mail message, voice message, video message, 142 etc. 144 5. Infrastructure Preservation 146 A major goal for the unified messaging framework is to not change 147 any existing Internet infrastructure. For example, the behavior of 148 mail transfer agents (MTAs) should not change. Likewise, the 149 behavior of existing mail clients should not change. 151 Messages created in a unified messaging context MUST NOT require 152 changes to existing mail clients. However, there may be a loss in 153 service in certain circumstances. 155 The unified messaging framework MUST be able to handle messages 156 created in a non-unified messaging context, for example, a simple, 157 RFC 822 [9] text message. 159 Burger Informational - Expires August 2002 3 160 UM Requirements February 2002 162 6. Voice Requirements 164 The expectation of voice mail users are described in [8] and [10]. 165 To summarize, voice mail users have heightened expectations of 166 privacy, delivery confirmation, and addressing than Internet Mail 167 users. 169 On the retrieval side, there are significant real-time requirements 170 for retrieving a message for voice playback. More than any other 171 media type, including video, voice is extremely sensitive to 172 variations in playback latency. The unified messaging framework 173 MUST address the real-time needs of voice. 175 7. Fax Requirements 177 Fax users have a particular expectation that is a challenge for 178 unified messaging. When a person sends a fax, their expectation is 179 the user has received the message upon successful transmission. 180 This clearly is not the case for Internet Mail. 182 OPEN ISSUE: How will we address this? 184 8. Video Requirements 186 Video mail has one outstanding feature: Video messages are large! 187 The unified messaging framework MUST scale for very large messages. 189 9. Security Considerations 191 Security will be a very important part of unified messaging. In 192 addition to the security issues present in Internet Mail, people 193 have higher expectations for Voice and Fax messaging. The goal, 194 wherever possible, is to preserve the semantics of existing 195 messaging systems and meet the expectations of users with respect to 196 security and reliability. 198 10. References 200 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 201 9, RFC 2026, October 1996. 203 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 204 Levels", BCP 14, RFC 2119, March 1997 206 3 Vaudreuil, G. and Parsons, G., "Voice Profile for Internet Mail - 207 version 2", RFC 2421, September 1998 209 Burger Informational - Expires August 2002 4 210 UM Requirements February 2002 212 4 Freed, N. and Borenstein, N., "Multipurpose Internet Mail 213 Extensions (MIME) Part One: Format of Internet Message Bodies", 214 RFC 2045, November 1996 216 5 Resnick, P. (Editor), "Internet Message Format", RFC 2822, April 217 2001 219 6 Masinter, L. and Wing, D., "Extended Facsimile Using Internet 220 Mail", RFC 2532, March 1999 222 7 Toyoda, K., Ohno, H., Murai, J., and Wing, D., "A Simple Mode of 223 Facsimile Using Internet Mail", RFC 2305, March 1998 225 8 McRae, S., "Internet Voice Messaging", 226 draft-ietf-vpim-ivm-03.txt, work in progress 228 9 Crocker, D., "Standard for the format of ARPA Internet text 229 messages", RFC 822 (obsolete), August 1982 231 10 Burger, E., Candell, E., Eliot, C., and Klyne, G., "Message 232 Context for Internet Mail", draft-ietf-vpim-hint-07.txt, June 233 2001 235 11. Acknowledgments 237 I would like to thank Greg Vaudreuil and Glen Parsons for convincing 238 me this is a worthwhile effort. 240 12. Author's Addresses 242 Eric Burger 243 SnowShore Networks, Inc. 244 Chelmsford, MA 245 USA 247 Phone: +1 978/367-8403 248 Email: eburger@snowshore.com 250 Burger Informational - Expires August 2002 5 251 UM Requirements February 2002 253 Full Copyright Statement 255 Copyright (C) The Internet Society (2002). All Rights Reserved. 257 This document and translations of it may be copied and furnished to 258 others, and derivative works that comment on or otherwise explain it 259 or assist in its implementation may be prepared, copied, published 260 and distributed, in whole or in part, without restriction of any 261 kind, provided that the above copyright notice and this paragraph are 262 included on all such copies and derivative works. However, this 263 document itself may not be modified in any way, such as by removing 264 the copyright notice or references to the Internet Society or other 265 Internet organizations, except as needed for the purpose of 266 developing Internet standards in which case the procedures for 267 copyrights defined in the Internet Standards process must be 268 followed, or as required to translate it into languages other than 269 English. 271 The limited permissions granted above are perpetual and will not be 272 revoked by the Internet Society or its successors or assigns. This 273 document and the information contained herein is provided on an "AS 274 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 275 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 276 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 277 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 278 OR FITNESS FOR A PARTICULAR PURPOSE. 280 Acknowledgement 282 The Internet Society currently provides funding for the RFC Editor 283 function. 285 Burger Informational - Expires August 2002 6