Network Working Group                                         E. Burger 
Internet Draft                                 SnowShore Networks, Inc. 
Document: draft-burger-um-reqts-00.txt                    February 2002 
Category: Informational                                                 
Expires: August 2002                                                    
 
 
                Internet Unified Messaging Requirements 
 
 
Status of this Memo 
 
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC2026 [1].  
    
   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. 
    
    
    
1. Abstract 
    
   Internet Unified Messaging brings together the body of work done in 
   VPIM, FPIM, IMAPEXT, and other IETF work groups.  The goal is to 
   provide a single infrastructure, mailbox, and set of interfaces for 
   a user to get, respond to, and manipulate all of their messages, no 
   matter what the media or source.  This document describes the 
   requirements for providing such a service. 
 
   Discussion of this and related drafts are on the UM list.  To 
   subscribe, send the message "subscribe um" to 
   majordomo@snowshore.com.  The public archive is at 
   http://flyingfox.snowshore.com/um_archive/maillist.html. 
    
    
2. Conventions used in this document 
    
   This document refers generically to the sender of a message in the 
   masculine (he/him/his) and the recipient of the message in the 
   feminine (she/her/hers).  This convention is purely for convenience 
   and makes no assumption about the gender of a message sender or 

  
Burger           Informational - Expires August 2002                1 

                           UM Requirements              February 2002 
 
 
   recipient. 
    
   FORMATTING NOTE: Notes, such at this one, provide additional 
   nonessential information that the reader may skip without missing 
   anything essential.  The primary purpose of these non-essential 
   notes is to convey information about the rationale of this document, 
   or to place this document in the proper historical or evolutionary 
   context.  Readers whose sole purpose is to construct a conformant 
   implementation may skip such information.  However, it may be of use 
   to those who wish to understand why we made certain design choices. 
    
   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 [2]. 
    
    
3. Introduction 
    
   Humans have had to contend with having multiple messaging systems 
   for different messaging modes.  For example, I have a voice mail 
   account for voice messages, a fax store-and-forward service for fax 
   messages, and an e-mail account for Internet messages. 
    
   The IETF has successfully completed a considerable body of work 
   extending the highly successful non-real-time text messaging 
   service, SMTP.  Extending the mail system for multimedia payloads 
   with MIME enabled the transport of voice and fax.  The VPIM and IFAX 
   work groups, respectively, have produced a number of RFCs that focus 
   on voice mail and fax messaging and transport.  This draft examines 
   the requirements for unified messaging systems. 
    
   There has been an evolution of using Internet Mail standards [3] for 
   the carriage of media-rich messages.  MIME [4] introduces the basic 
   capability for transporting media-rich messages using Internet Mail.  
   Then there were a number of successful efforts to use Internet Mail 
   for supporting the transport of various media-specific message types 
   within closed environments.  Leveraging this success, people started 
   to see how to integrate the closed environments into the Internet 
   Mail structure.  The ultimate goal is Unified Messaging: a single 
   infrastructure, mailbox, and set of interfaces for a user to get all 
   of their messages. 
    
   The Voice Profile for Internet Mail defines a method for 
   transporting voice messages between voice messaging systems using 
   Internet Mail [5].  Likewise, the Extended Mode Fax [6] defines a 
   method for transporting fax messages between fax messaging terminals 
   using Internet Mail. 
    
   Simple Mode Fax [7] describes how one can deliver facsimile 
   documents using the Internet Mail infrastructure, including standard 
   Internet Mail clients.  Said differently, the document brought 
   facsimile into the Internet Mail domain. 
    
  
Burger           Informational - Expires August 2002                2 

                           UM Requirements              February 2002 
 
 
   Likewise, Internet Voice Mail [8] describes how one can generate and 
   deliver voice messages using the Internet Mail infrastructure, 
   including standard Internet Mail clients. 
    
   With this set of developments, we are now in a position to gather 
   these standards and develop new protocols where needed to deliver 
   true unified messaging. 
    
    
4. General Requirements 
    
4.1. Reuse Existing Protocols 
    
   To the extent feasible, the unified messaging framework SHOULD use 
   existing protocols whenever possible.   
     
4.2. Maintain Existing Protocol Integrity 
    
   In meeting requirement 4.1, the unified messaging framework MUST NOT 
   redefine the semantics of an existing protocol. 
    
   Said differently, we will not break existing protocols. 
4.3. Reception Context 
    
   When the user receives a message, that message SHOULD receive the 
   treatment expected by the sender.  For example, if the sender 
   believes he is sending a voice message, voice message semantics 
   should prevail. 
    
4.4. Sending Context 
    
   When the user sends a message, she SHOULD be able to specify the 
   message context.  That is, whether the network should treat the 
   message as an Internet Mail message, voice message, video message, 
   etc. 
 
    
5. Infrastructure Preservation 
    
   A major goal for the unified messaging framework is to not change 
   any existing Internet infrastructure.  For example, the behavior of 
   mail transfer agents (MTAs) should not change.  Likewise, the 
   behavior of existing mail clients should not change. 
    
   Messages created in a unified messaging context MUST NOT require 
   changes to existing mail clients.  However, there may be a loss in 
   service in certain circumstances. 
    
   The unified messaging framework MUST be able to handle messages 
   created in a non-unified messaging context, for example, a simple, 
   RFC 822 [9] text message. 
    
    
  
Burger           Informational - Expires August 2002                3 

                           UM Requirements              February 2002 
 
 
6. Voice Requirements 
    
   The expectation of voice mail users are described in [8] and [10].  
   To summarize, voice mail users have heightened expectations of 
   privacy, delivery confirmation, and addressing than Internet Mail 
   users. 
    
   On the retrieval side, there are significant real-time requirements 
   for retrieving a message for voice playback.  More than any other 
   media type, including video, voice is extremely sensitive to 
   variations in playback latency.  The unified messaging framework 
   MUST address the real-time needs of voice. 
    
    
7. Fax Requirements 
    
   Fax users have a particular expectation that is a challenge for 
   unified messaging.  When a person sends a fax, their expectation is 
   the user has received the message upon successful transmission.  
   This clearly is not the case for Internet Mail. 
    
   OPEN ISSUE: How will we address this? 
    
    
8. Video Requirements 
    
   Video mail has one outstanding feature: Video messages are large!  
   The unified messaging framework MUST scale for very large messages. 
    
    
9. Security Considerations 
 
   Security will be a very important part of unified messaging.  In 
   addition to the security issues present in Internet Mail, people 
   have higher expectations for Voice and Fax messaging.  The goal, 
   wherever possible, is to preserve the semantics of existing 
   messaging systems and meet the expectations of users with respect to 
   security and reliability. 
    
    
10. References 
    
 
   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
      9, RFC 2026, October 1996. 
    
   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
      Levels", BCP 14, RFC 2119, March 1997 
    
   3  Vaudreuil, G. and Parsons, G., "Voice Profile for Internet Mail - 
      version 2", RFC 2421, September 1998 
    
 
  
Burger           Informational - Expires August 2002                4 

                           UM Requirements              February 2002 
 
 
 
   4  Freed, N. and Borenstein, N., "Multipurpose Internet Mail 
      Extensions (MIME) Part One: Format of Internet Message Bodies", 
      RFC 2045, November 1996 
    
   5  Resnick, P. (Editor), "Internet Message Format", RFC 2822, April 
      2001 
    
   6  Masinter, L. and Wing, D., "Extended Facsimile Using Internet 
      Mail", RFC 2532, March 1999 
    
   7  Toyoda, K., Ohno, H., Murai, J., and Wing, D., "A Simple Mode of 
      Facsimile Using Internet Mail", RFC 2305, March 1998 
    
   8  McRae, S., "Internet Voice Messaging", 
      draft-ietf-vpim-ivm-03.txt, work in progress 
    
   9  Crocker, D., "Standard for the format of ARPA Internet text 
      messages", RFC 822 (obsolete), August 1982 
    
   10 Burger, E., Candell, E., Eliot, C., and Klyne, G., "Message 
      Context for Internet Mail", draft-ietf-vpim-hint-07.txt, June 
      2001 
    
    
    
    
11. Acknowledgments 
    
   I would like to thank Greg Vaudreuil and Glen Parsons for convincing 
   me this is a worthwhile effort. 
    
    
12. Author's Addresses 
    
   Eric Burger 
   SnowShore Networks, Inc. 
   Chelmsford, MA 
   USA 
    
   Phone: +1 978/367-8403 
   Email: eburger@snowshore.com  
    










  
Burger           Informational - Expires August 2002                5 

                           UM Requirements              February 2002 
 
 
    
Full Copyright Statement 
 
   Copyright (C) The Internet Society (2002).  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 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. 
    
Acknowledgement 
    
   The Internet Society currently provides funding for the RFC Editor 
   function. 
    
    



















  
Burger           Informational - Expires August 2002                6