Network Working Group E. Burger Internet Draft SnowShore Networks, Inc. Document: draft-burger-imap-chanuse-00.txt February 2002 Category: Informational Expires: August 2002 IMAP CHANNEL Use Cases 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 This document describes different use cases for using the IMAP CHANNEL facility. Discussion of this and related drafts are on the IMAP Voice list. To subscribe, send the message "subscribe" to ietf-imap-voice-request@imc.org . 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 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, Burger Informational - Expires August 2002 1 CHANNEL Use Cases February 2002 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. 2.1. Definitions 2.1.1. Keywords The keywords "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]. 2.1.2. Jitter Jitter is the variation of inter-arrival times for a packet stream. Say a source generates a stream at a constant rate, such as one packet every 20ms. Then the jitter is the variation away from 20ms per packet from the packet inter-arrival time at the destination. 2.1.3. Latency Latency is the amount of time a packet takes to transit an operation. An operation can be transport, such as the terrestrial transmission delay and router queue delays. An operation can also be transformation, such as transcoding a stream from one format to another or mixing a set of streams to create a new stream. 2.1.4. Real-Time Stream A real-time stream is a packet flow characterized by having hard requirements for latency, jitter, or both. For example, a unidirectional voice flow requires almost no jitter. A bi- directional voice flow requires almost no jitter and an end-to-end latency of ideally less than 150ms and absolutely less than 200ms. 2.1.5. IMAP Store 2.1.6. Client Device 2.1.7. Media Server 3. Introduction This document describes different use cases for using the IMAP CHANNEL [3] facility. 4. Use Cases Here is a set of useful use cases. 4.1. Conventional Message Store in Real-Time Network Burger Informational - Expires August 2002 2 CHANNEL Use Cases February 2002 Conventional message stores typically run on general-purpose computing hardware. Such platforms are very good at general storage management and the data base management needed for keeping track of user's profiles and messages. In addition, most general-purpose computing platforms are rather efficient at retrieving large disk blocks and transmitting and receiving relatively large network packets (e.g. 8KB blocks). For a variety of architectural reasons, general-purpose platforms are rather inefficient for streaming low-latency, low-jitter streams. Not only is the jitter unpredictable, the number of simultaneous streams such a platform can support may be unacceptably small. The IMAP CHANNEL facility allows the network a mechanism for serving IMAP messages with real-time delivery constraints. Here is an exemplary configuration. imap.sp.net +---------+ IMAP | IMAP | +--------+ ------------------------------>| Store | | Client |/ ms.sp.net +---------+ | Device |<---\ SIP +--------+ ^ +--------+ \=============| Media | __| HTTP | Server |---/ +--------+ In this example, the client issues a request to the IMAP store for an object. The client knows that it needs real-time playback. The client can know this, for example, if it knows the object is a multimedia object. The client can determine this by convention (e.g., the only message types stored are multimedia objects) or from examining the content-type of the body part. Since the client requires real-time playback of the object, it issues an IMAP CHANNEL request, requesting an appropriate protocol, such as SIP [4] or RTSP [5], for control of the object transport. In the example above, the client asks for a SIP stream by issuing the following IMAP CHANNEL request. C: 927 CHANNEL (sip:) (2 3.2) This requests the server to fetch section 3.2 from body part 2. The client requests SIP as the return mechanism. The server responds with a URI that is opaque to the client. Here is an example using SIP netann [6]. S: * 1 CHANNEL 2 \ sip:annc@ms.sp.net;play=http://imap.sp.net/cgi-bin/get-obj?1af4e92 S: 927 OK done Burger Informational - Expires August 2002 3 CHANNEL Use Cases February 2002 4.2. Clients Configured With "Close" Hosts Clients, such as 3G wireless mobile terminals, can retrieve RTSP, but may have limitations on which servers they can communicate with. Likewise, the client may have a preferred set of hosts. Here is an exemplary configuration. imap.sp.net IMAP Store Client close.sp.net Device Close Media far.other.com Server Very Far far.sp.net Media Far Server Media Server In this example, the client issues a request to the IMAP for the object. The client, through means outside IMAP, knows the "distance" to the relevant media servers. The client issues the following IMAP CHANNEL request. C: 1023 CHANNEL (rtsp://close.sp.net rtsp://far.sp.net rtsp: imap:) (2 3.2) (9 1) (11 4.5) This requests the server to fetch section 3.2 from message 2, section 1 from message 9, and section 4.5 from message 11, with the preferred order of servers for retrieving the object. Note the listing of the partial-URI is for readability. An actual request would have a space-separated list. The server responds with (a set of) URI. Here is an example response. S: * 2 CHANNEL 3.2 rtsp://far.sp.net/playback/431987 S: * 9 CHANNEL 1 rtsp://close.sp.net/v531hn034f S: * 11 CHANNEL 4.5 rtsp://far.other.com/m11p4e5.gsm \ rtsp://imap.sp.net/m11p4e5.au S: 1023 OK done The first response shows that the server could not satisfy the request at the close media server, but could at the far one. The second response shows that the server could satisfy the request from the close media server. The third response show a copy available in another domain and a copy on the IMAP server itself. Note that the determination of whether to send a list or not is up to the IMAP server. Burger Informational - Expires August 2002 4 CHANNEL Use Cases February 2002 4.3. Transcoding Service A description of a transcoding service, for example, from MS-GSM to G.726, goes here. 4.4. Cluster Server A description of using a proxy server and a media server to front end a cluster of message stores goes here. 5. 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. 6. 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 Hole, S., Nerenberg, L., and Leiba, B., "IMAP4 Channel Transport Mechanism", draft-nerenberg-imap-channel-01.txt, November 2001, work in progress 4 Rosenberg , J., et. al., "SIP: Session Initiation Protocol", draft-ietf-sip-rfc2543bis-07.txt, February 2002, work in progress 5 Schulzrinne, H., Rau, A., and Lanphier, R., "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998 6 O'Connor, W., Burger, E., and Van Dyke, J., "Networks Announcements with SIP", draft-burger-sipping-netann-01.txt, November 2001, work in progress 7. Acknowledgments Burger Informational - Expires August 2002 5 CHANNEL Use Cases February 2002 I would like to thank Greg Vaudreuil and Glen Parsons for convincing me this is a worthwhile effort. Also to Lyndon Nerenberg for reminding me to get this draft out! 8. Author's Address Eric Burger SnowShore Networks, Inc. Chelmsford, MA USA Phone: +1 978/367-8403 Email: eburger@snowshore.com Burger Informational - Expires August 2002 6 CHANNEL Use Cases 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 7