Network Working Group S. Hole Internet Draft: IMAP4 Channel Transport Mechanism L. Nerenberg Document:draft-nerenberg-imap-channel-00.txt ACI/Messagingdirectdraft-nerenberg-imap-channel-01.txt ACI Worldwide B. Leiba IBM ResearchFebruaryNovember 2001 IMAP4 Channel Transport Mechanism Status of this memo This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 otherdocumentsdocu- ments at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as "work in progress.rq 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. A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community.DiscussionDis- cussion and suggestions for improvement are requested.DistributionDistribu- tion of this draft is unlimited. 0. Administrivia Lines prefixed with ">>>" aremeta-comments.meta-comments and will not appear in the final document. Discussion concerning this draft should be directed to the <ietf-imap-voice@imc.org> mailing list. (To subscribe: echo subscribe | mail ietf-imap-voice-request@imc.org) 1. Abstract IMAP4 is being used to serve rich media content in environments that extend beyond traditional text-based e-mail. One example is a cellular telephone that can retrieve and send MIME-encoded audio data through IMAP4. While this type of content can be exchanged natively using IMAP4, 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 specifications defines a mechanism for an IMAP4 client to request message content from a server through an external scheme. 2. Conventions Used in this Document The key words "MUST," "MUST NOT," "SHOULD," "SHOULD NOT," and "MAY" in this document are to be interpreted as described in [KEYWORD]. In examples, "C:" and "S:" preface lines sent by the client and the server respectively. 3.Overview 4.Protocol Framework This memo defines the following extensions to[IMAP4]. 4.1.[IMAP4rev1]. 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 theexternalschemes available to the CHANNEL command. Thecapabil- itycapability response consists of the string "CHANNEL=" followed by acomma- seperatedcomma-seperated list of schemes supported by the CHANNELservices. >>> e.g. CHANNEL=rtsp,imap >>> >>> Is this comma-list syntax going to mess things up for >>> parsers? We prefer it because it's more compact than >>> CHANNEL=rtsp CHANNEL=imap (AUTH-style lists). 4.2.extension. 3.2. CHANNEL Command The CHANNEL command requests that message data be retrieved through an external scheme.The scheme is specified using a URI [URI].Clients may issue a partially-qualified URI, in which case the server will determine the final connection end-point. Whatconsti- tutesconstitutes a partially-qualified URI isimplementationimplemen- tation defined, however every URI MUST contain at least a scheme. The syntax of the CHANNEL command is: tag CHANNELuri_list msg_set uri_listuri-list channel-set uri-list is a list of URIs specifyingthe locations wherehow the client is willing to retrieve the message data. Ifthe list con- tainsuri-list contains more than oneelementele- ment the server must enumerate the list in order and SHOULD return the message data via the first URI it is capable of using. >>> the intent is that the client can indicate a list of >>> services in descending order of usefulness/quality. >>> Also, there is no guarantee that a server can express>>>a >>> particular body section through all of its advertised >>> schemes, thus the list provides fallback for the server >>> as well as the client.msg_setchannel-set is a list ofmessages andmessage body sections to be retrieved through the specified URI. >>> example syntax: >>>>>>0 CHANNEL("rtsp:" "imap:")(rtsp imap) (1(body[2])) (3 (body[1] body[9])) >>>2)(3 1)(3 9.1) >>> asks for section 2 of message 1 andsectionsections 1 and 9.1 >>> of message 3. The preferred method is RTSP, however if >>>3 via RTSP. IfRTSP isn't available/usable, try IMAP. In>>>either case, >>> the server will fill in the connection end-point >>> information.4.3.You cannot ask for .HEADERS or .MIME data >>> with CHANNEL. 3.3. CHANNEL Response The CHANNEL response returns connection status and location infor- mation to the client. One untagged response is returned for each body section requested. >>> example response to above command: >>> >>> S: * 1 CHANNEL((body[2]) "rtsp://example.com/1441243")2 rtsp://frobozz.example.com/144124 >>> S: * 3 CHANNEL((body[1])1 >>>S: "imap://user@imap.example.com:/inbox;uidvalidity=2/;uid=33")imap://user@example.com:/inbox;uidvalidity=2/;uid=33 >>> S: * 3 CHANNEL((body[9]) NIL)9.1 NIL >>> S: 0 OK done >>> >>> The NIL response to thebody[9]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>>>through the schemes, >>> or because some resource was unavailable.5.The server MUST NOT issue an untagged CHANNEL response containing a URL until such time as that URL is valid and avaliable for the client to dereference. The lifetime of the URL is implementation defined. 4. Formal Protocol Syntax The following syntax specification uses the augmented Backus-Naur Form(BNF)(ABNF) notation asused in [IMAP4]. Except as noted otherwise, all alphabetic characters are case- insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these stringsdefined ina case-insensitive fashion.[ABNF], and incorporates by ref- erence the Core Rules from that document. This syntax extends the grammar specified in[IMAP4]. >>> TO BE DONE 6.[IMAP4rev1]. The following tokens are incorporated from [URI]: scheme, URI-ref- erence. capability =/ "CHANNEL=" scheme *["," scheme] channel = "CHANNEL" SP uri-list SP channel-set channel-data = "CHANNEL" nz-number (URI-reference / nil) channel-set = 1*( "(" nz-number SP section-part ")" ) command-select =/ channel response-data = "*" SP (resp-cond-state / resp-cond-bye / mailbox-data / message-data / capability-data / channel-data) CRLF ; adds <channel-data> to IMAP4rev1 ; <response-data> uri-list = "(" URI-reference *[SP URI-reference] ")" 5. References[IMAP4][ABNF] Crocker, D., P. Overell, "Augmented BNF for Syntax Specifi- cations: ABNF." RFC2234, November 1997 [IMAP4rev1] Crispin, M., "Internet Message Access ProtocolVersion- Ver- sion 4rev1,"RFC2060, University of Washington, December 1996 [URI] Berners-Lee, T., et al, "Uniform Resource Identifiers (URI): Generic Syntax," RFC2396, August 1998Work in Progress [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 9, RFC2119, March 19977.[URI] Berners-Lee, T., et al, "Uniform Resource Identifiers (URI): Generic Syntax," RFC2396, August 1998 6. Security Considerations8.7. Authors' Addresses Lyndon Nerenberg Steve HoleACI/MessagingDirect ACI/MessagingDirectACI Worldwide ACI Worldwide Suite 900 Suite 900 10117 - Jasper Avenue 10117 - Jasper Avenue Edmonton, Alberta Edmonton, Alberta Canada T5J 1W8 Canada T5J 1W8<lyndon@messagingdirect.com><lyndon@atg.aciworldwide.com> <steve.hole@messagingdirect.com> Barry Leiba IBM T.J. Watson Research Center 30 Saw Mill River Road Hawthorne, NY 10532 <leiba@watson.ibm.com> Phone: +1 914 784 7941