Internet DRAFT - draft-burger-um-reqts
draft-burger-um-reqts
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
