Network Working Group E. Burger Internet Draft SnowShore Networks, Inc. Document: draft-ietf-lemonade-imap-channel-00.txt June 22, 2003 Updates: RFC 2060 Expires: December 2003 IMAP CHANNEL Protocol and 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. Discussion of this and related drafts are on the LEMMONADE list. To subscribe, send the message "subscribe" to lemonade-request@ietf.org. Abstract Environments that extend beyond traditional text-based e-mail use IMAP4 to serve rich media content. One example is a cellular telephone that can retrieve and send MIME-encoded audio data through IMAP4. While IMAP4 can exchange this type of content, some applications will work better if the message content can be manipulated using schemes external to the IMAP4 connection. In our cellular telephone example, it might be preferable for the telephone client to retrieve the audio data using RTSP. This specification defines a mechanism for an IMAP4 client to request message content from a server through an external scheme. Burger Expires December 2003 1 CHANNEL Use Cases June 2003 Table of Contents 1. Conventions used in this document..................................2 2. Definitions........................................................3 2.1. Keywords.........................................................3 2.2. Jitter...........................................................3 2.3. Latency..........................................................3 2.4. Real-Time Stream.................................................3 2.5. IMAP Store.......................................................3 2.6. Client Device....................................................3 2.7. Media Server.....................................................4 3. Protocol Framework.................................................4 3.1. CAPABILITY Identification........................................4 3.2. CHANNEL Command..................................................4 3.3. CHANNEL Response.................................................5 3.4. Command Sequencing...............................................5 4. Formal Protocol Syntax.............................................5 5. Use Cases..........................................................6 5.1. Conventional Message Store in Real-Time Network..................6 5.2. Clients Configured With "Close" Hosts............................7 5.3. Transcoding Service..............................................9 5.4. Mail Sending service............................................10 6. Security Considerations...........................................11 7. References........................................................12 8. Contributors......................................................13 9. Acknowledgments...................................................13 10. Stuff to Do......................................................13 11. Author's Address.................................................13 1. 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. In examples, "C:" and "S:" preface lines sent by the client and the server respectively. The examples in this document do NOT form part of the specification. Where conflicts exist between the text and the formal grammar, the grammar is authoritative. 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 Expires December 2003 2 CHANNEL Use Cases June 2003 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. Definitions 2.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.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.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.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.5. IMAP Store An IMAP Store is a repository for messages accessed by the IMAP protocol. 2.6. Client Device A client device is a device that presents messages to the user. Burger Expires December 2003 3 CHANNEL Use Cases June 2003 2.7. Media Server A media server is a device that transforms or adapts media (audio or video) into an appropriate format for a client device. 3. Protocol Framework This memo defines the following extensions to [3]. 3.1. CAPABILITY Identification IMAP4 servers that support this extension MUST include a CHANNEL capability response in the response list to the CAPABILITY command. This entry indicates the server supports the extension, and lists the schemes available to the CHANNEL command. The capability response consists of the string "CHANNEL=" followed by a list of schemes supported by the CHANNEL extension. Example: * CAPABILITY IMAP4rev1 AUTH=DIGEST-MD5 CHANNEL=imap,ftp 3.2. CHANNEL Command The CHANNEL command requests that message data be retrieved through an external scheme. Clients may issue a partially-qualified URI, in which case the server will determine the final connection end-point. What constitutes a partially-qualified URI is implemen- tation defined. The syntax of the CHANNEL command is: tag CHANNEL channel-uri-list channel-set is a list of URIs or schemes specifying how the client is willing to retrieve the message data. If contains more than one element the server must enumerate the list in order and SHOULD return the message data via the first item in the list it is capable of using. is a list of message-number/body-section pairs describing the content to be retrieved. The message number specifies the sequence number of the message to act on, or in the case of a UID CHANNEL command, the UID of the message. Example: C: 0 CHANNEL (rtsp: imap:) (1 2)(3 1)(3 9.1) asks for section 2 of message 1 and sections 1 and 9.1 of message 3. The preferred retrieval scheme is RTSP. If RTSP isn't available the Burger Expires December 2003 4 CHANNEL Use Cases June 2003 IMAP scheme should be attempted. In either case the server will fill in the connection end-point information. 3.3. CHANNEL Response An untagged CHANNEL response is returned for each message- number/body-section pair specified by the corresponding CHANNEL command: * message-number CHANNEL section-spec URI The ordering of these responses is arbitrary. The message number and in the response mirror those in the corresponding request, therefore responses to UID CHANNEL commands report the message UID rather than the message sequence number. The responses to the example command in the previous section might look like: S: * 1 CHANNEL 2 rtsp://frobozz.example.com/144124 S: * 3 CHANNEL 1 imap://user@example.com:/inbox;uidvalidity=2/;uid=33 S: * 3 CHANNEL 9.1 NIL S: 0 OK done The NIL response to the section 9.1 request indicates that the part could not be retrieved via either of the requested schemes. This could be caused by the inability to convert or represent the content via the requested schemes, or because a resource was unavailable. The server MUST NOT issue an untagged CHANNEL response containing a URL until such time as that URL is avaliable for the client to dereference. The lifetime of the URL is implementation defined. If any one of the schemes in the does not match one of the schemes listed in the server channel capability list the server: 1) MUST NOT execute any part of the command, 2) MUST NOT return any untagged responses to the command, and 3) MUST issue only a tagged BAD completion response. 3.4. Command Sequencing Since there is no way to distinguish between responses to CHANNEL and UID CHANNEL, clients MUST NOT issue a UID CHANNEL command while a CHANNEL command is in progress. Conversely, clients MUST NOT issue a CHANNEL command while a UID CHANNEL command is in progress. These restrictions are in addition to the normal sequencing rules that apply to UID-style commands. 4. Formal Protocol Syntax The following syntax specification uses the augmented Backus-Naur Form (ABNF) notation as defined in [4], and incorporates by Burger Expires December 2003 5 CHANNEL Use Cases June 2003 reference the Core Rules from that document. This syntax extends the grammar specified in [IMAP4rev1]. The following tokens are incorporated from [5]: absoluteURI and scheme. capability =/ "CHANNEL=" scheme *("," scheme) channel = ["UID" SP] "CHANNEL" SP channel-uri-list SP channel-set channel-data = "CHANNEL" SP section-spec SP (absoluteURI / nil) channel-set = 1*("(" nz-number SP section-spec ")") channel-uri-list = "(" channel-uri-reference 1*(SP channel-uri-reference) ")" channel-uri-reference = absoluteURI / scheme ":" command-select =/ channel response-data = "*" SP (resp-cond-state / resp-cond-bye / mailbox-data / message-data / capability-data / channel-data) CRLF ; adds to 5. Use Cases 5.1. Conventional Message Store in Real-Time Network 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. Burger Expires December 2003 6 CHANNEL Use Cases June 2003 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 [6] or RTSP [7], 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 message 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 [8]. S: * 1 CHANNEL 2 sip:annc@ms.sp.net;play=http://imap.sp.net/cgi-bin/get-obj?1af4e92 S: 927 OK done 5.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. Burger Expires December 2003 7 CHANNEL Use Cases June 2003 +-------------+ | imap.sp.net | | IMAP | | Store | +-------------+ +--------+ +--------------+ | Client | | close.sp.net | | Device | | Close | +---------------+ +--------+ | Media | | far.other.com | | Server | | Very | +--------------+ | Far | | Media | +------------+ | Server | | far.sp.net | +---------------+ | Far | | 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 Expires December 2003 8 CHANNEL Use Cases June 2003 5.3. Transcoding Service Often, the object media type in the message store is different than what the user device can display. For example, MS-GSM is a convenient audio format for unified messaging systems, as it is relatively compact, has decent audio quality, and is ubiquitous. However, MS-GSM is not a good audio format for telephony devices. Telephony devices such as mobile phones expect GSM; long distance networks expect G.726; voice-over-IP network may expect G.729ab; and enterprise gateways expect G.711. In addition, objects may need transformation. For example, one may wish to access a 1000x1000 pixel image that is in a high-fidelity format, such as a 600 dpi bitmap in 16-bit color. However, the user's device may only be able to display 320x320 pixel PNG at 72 dpi resolution in 8-bit color. Note the former image is around 16 Mb, while the latter image is well under 1Mb. For high-latency networks, this difference in object size is significant. Thus, there is a need to transcode objects from one format to another. The OPES work group [9] is addressing the general case for object transformation. Simply requesting an http: URL that an OPES server will intercept will cause the appropriate transformation to occur. The following is an example of transparent, OPES transcoding. For more detailed examples, see [10]. +---------+ IMAP +--------+ | User |--------------------------------->| IMAP | | Device |--\ | Store | +---------+ \ +--------+ || \http ^ || \ +--------+ ----------| || \->| OPES | / || | Server | / || +--------+ / || | / || Media |ocp / Fetch || (e.g., GSM-AMR) v / (e.g., NFS, IMAP) || +--------+ / (e.g., MS-GSM) ================| Media |--/ | Server | +--------+ In addition, the client can directly request transcoding services from the media server. In the following example, the client requests a SIP media stream. The IMAP store returns a SIP URI that Burger Expires December 2003 9 CHANNEL Use Cases June 2003 indicates a request for a transcoding service. Here is an example request flow. C: 1023 CHANNEL (sip:) (7) S: * 7 sip:annc@ms.sp.net;play=file://store.sp.net/msgs/412.wav In this example, the transcoding request is implicit. The file is self-describing (a WAVE file), and the media the user device wants to receive the message in gets negotiated in the normal SIP offer- answer negotiation. 5.4. Mail Sending service Often clients may wish to send a message through SMTP that exists in the IMAP store without downloading the message to the client first. One can do this by using a "mailto:" URL with the CHANNEL command. The addresses provided in the "mailto:" URL are the SMTP envelope recipients to which the message store is to send the message. The common case would be as follows: C: 0 CHANNEL (mailto:burger@example.com) (5) This requests the server to send all of message 5 to the address "burger@example.com" via SMTP [11]. The store sends the message as it is in the IMAP store. The store MUST NOT change either the message's contents or its headers. This is so clients may send messages to users without revealing their addresses in the header of the message (as is done using empty groups in the destination addresses or sending blind carbon copies). However, if the "mailto:" URL specifies header names, these may be prepended to the message before it is sent. For example: C: 1 CHANNEL (mailto:resnick@example.com? resent-from=burger@example.net& resent-to=resnick@example.com) (6) The above would request that message 6 be sent to resnick@example.com" with the following header fields prepended to the message: Resent-From: burger@example.net Resent-To: resnick@example.com This is quite useful for implementing a "Resend" service in a client, where the client wants to send an exact copy of a previously received message to somewhere else with only the resent trace fields prepended to the message. The preceding uses of CHANNEL also apply if a part of a message is specified in the channel-set that has a MIME type of "message/rfc822". However, if a part is specified in the channel- Burger Expires December 2003 10 CHANNEL Use Cases June 2003 set that is not "message/rfc822", then the message is sent with the top-level MIME type the same as the part specified. If multiple parts are specified in the channel-set (even if one or more of them are entire messages or parts of type "message/rfc822"), all of those parts are sent together as a single "multipart/mixed" message. For both of these cases, the client MUST specify any RFC 2822 header fields it desires for the message in the URL; the MIME header fields (such as "Content-Type:" and "Content-Transfer-Encoding:") for the message will be provided by the server before sending the message. For example: C: 1 CHANNEL (mailto:resnick@example.com? to=Pete%20Resnick%20& from=Eric%20Burger%20& date=21%20Sep%202002%2010%3A29%3A00%20-0500) (7)(8 1)(9 5.2) The above will send a message with header fields similar to these: To: Pete Resnick From: Eric Burger Date: 21 Sep 2002 10:29:00 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=... Content-Transfer-Encoding: 7bit The header will be followed by message 7 as a part with a MIME type of "message/rfc822", then part 1 of message 8 with its own MIME type, and finally part 5.2 of message 9, again with its own MIME type (all of course with the appropriate MIME boundary and Content- Transfer-Encoding). Note: The use of "mailto:" specified in this document differs slightly from the definition in RFC 2368. Unlike RFC 2368, mailto:resnick@example.com is *not* equivalent to mailto:?to=resnick@example.com in the case of the CHANNEL command. The former sends the message to "resnick@example.com". The latter prepends a "To: resnick@example.com" field to the message (and in this particular example, sends to no one since there is no destination address specified). 6. 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. Burger Expires December 2003 11 CHANNEL Use Cases June 2003 The mailto: mechanism can be used to send e-mail via SMTP. This has some of the same security implications as specified in RFC 2821, section 7. 7. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. INFORMATIVE 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 NORMATIVE 3 Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996 INFORMATIVE 4 Crocker, D., P. Overell, "Augmented BNF for Syntax Specifications: ABNF." RFC2234, November 1997 NORMATIVE 5 Berners-Lee, T., et al, "Uniform Resource Identifiers (URI): Generic Syntax," RFC2396, August 1998 NORMATIVE 6 J. Rosenberg, et. al., "SIP: Session Initiation Protocol", RFC 3261, June 2002. NORMATIVE 7 Schulzrinne, H., Rau, A., and Lanphier, R., "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998 INFORMATIVE 8 Van Dyke, J., Burger, E. (Ed.), Spitzer, A., and O'Connor, W., "Basic Network Media Services with SIP", draft-burger-sipping- netann-01.txt, November 2002, work in progress INFORMATIVE 9 Barbir, A. et. al., "An Architecture for Open Pluggable Edge Services (OPES)", draft-ietf-opes-architecture-03.txt, August 2002, work in progress INFORMATIVE 10 Barbir, A., Burger, E., Chen, R., McHenry, S., Orman, H., and Penno, R., "OPES Use Cases and Deployment Scenarios", draft-ietf- opes-scenarios-01, August 2002, work in progress INFORMATIVE Burger Expires December 2003 12 CHANNEL Use Cases June 2003 11 Klensin, J. (ed.), "Simple Mail Transfer Protocol", RFC 2821, April 2001. NORMATIVE 8. Contributors Lyndon Nerenberg shepherded through the three IMAP CHANNEL drafts by Steve Hole, Lyndon Nerenberg, and Barry Leiba. Any mistyping, misquoting, or lack of update is purely my own fault. Pete Resnick supplied the CHANNEL protocol machinery, as well as the mailto: use case. However, any transcoding errors are my own. 9. Acknowledgments 10. Stuff to Do Responses encode the URL as an . Does the syntax of conflict with the base IMAP grammar? There are enough punctuation characters available in a URL to put a protocol parser into an intractable state. Someone (besides the draft authors) needs to verify there are no conflicts between and the rest of IMAP. Security considerations needs to be expanded. Fully separate Normative & Informative references. 11. Author's Address Eric Burger SnowShore Networks, Inc. 285 Billerica Rd. Chelmsford, MA 01824-4120 USA Phone: +1 978/367-8400 Email: eburger@ieee.org Burger Expires December 2003 13 CHANNEL Use Cases June 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). 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 Expires December 2003 14