IMAP4 Channel Transport Mechanism

Versions: 00 01 02                                                      
Network Working Group                                            S. Hole
Internet Draft: IMAP4 Channel Transport Mechanism           L. Nerenberg
Document: draft-nerenberg-imap-channel-02.txt              ACI Worldwide
                                                                B. Leiba
                                                            IBM Research
                                                               June 2002

                   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

     Internet Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other docu-
     ments at any time.  It is inappropriate to use Internet Drafts as
     reference material or to cite them other than as "work in

     The list of current Internet Drafts can be accessed at

     The list of Internet Draft Shadow Directories can be accessed at

     A revised version of this draft document will be submitted to the
     RFC editor as a Proposed Standard for the Internet Community.  Dis-
     cussion and suggestions for improvement are requested.  Distribu-
     tion of this draft is unlimited.

0.  Administrivia

Discussion concerning this draft should be directed to the
<> mailing list. (To subscribe: echo subscribe |

Changes in -02:

     Changed <channel-set> to use <section-spec> instead of <section-
     text>.  This allows retrieval of headers and MIME structure.

     <channel-data> returns a <section-spec>, not <nz-number> (to match
     <channel> syntax).

Nerenberg          draft-nerenberg-imap-channel-02.txt          [Page 1]

Internet Draft      IMAP4 Channel Transport Mechanism          June 2002

     Add missing SP tokens to grammar.

     Grammar fix to allow foo: as a valid URI in a request.


     Clarify response when client issues a command with an unsupported

     Add section on command sequencing.

     Note arbitrary ordering of untagged responses.

     Replace URI-reference with absoluteURI. The IMAP server can't main-
     tain the state required to deal with relative URIs. This also
     solves an ambiguity between parsing "NIL" as <nil> or as a relative

Outstanding Issues

     Responses encode the URL as an <absoluteURI>. Does the syntax of
     <absoluteURI> 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 <absoluteURI> and
     the rest of IMAP.

     Security considerations needs to be written.

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

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.

     The examples in this document do NOT form part of the specifica-
     tion.  Where conflicts exist between the text and the formal gram-
     mar, the grammar is authoritative.

Nerenberg          draft-nerenberg-imap-channel-02.txt          [Page 2]

Internet Draft      IMAP4 Channel Transport Mechanism          June 2002

3.  Protocol Framework

     This memo defines the following extensions to [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
     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.



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

     <channel-uri-list> is a list of URIs or schemes specifying how the
     client is willing to retrieve the message data. If <chan-
     nel-uri-list> contains more than one element the server must enu-
     merate the list in order and SHOULD return the message data via the
     first item in the list it is capable of using.

     <channel-set> is a list of message-number/body-section pairs
     describing the content to be retrieved. The message number speci-
     fies the sequence number of the message to act on, or in the case
     of a UID CHANNEL command, the UID of the message.


          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 mes-
          sage 3. The preferred retrieval scheme is RTSP. If RTSP isn't
          available the 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-num-
     ber/body-section pair specified by the corresponding CHANNEL

Nerenberg          draft-nerenberg-imap-channel-02.txt          [Page 3]

Internet Draft      IMAP4 Channel Transport Mechanism          June 2002


          * message-number CHANNEL section-spec URI

     The ordering of these responses is arbitrary.  The message number
     and <section-spec> in the response mirror those in the correspond-
     ing 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://
          S: * 3 CHANNEL 1
          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 <channel-uri-list> 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 [ABNF], and incorporates by ref-
     erence the Core Rules from that document.  This syntax extends the
     grammar specified in [IMAP4rev1].

     The following tokens are incorporated from [URI]: absoluteURI,

Nerenberg          draft-nerenberg-imap-channel-02.txt          [Page 4]

Internet Draft      IMAP4 Channel Transport Mechanism          June 2002

     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 <channel-data> to <response-data>

5.  References

     [ABNF] Crocker, D., P. Overell, "Augmented BNF for Syntax Specifi-
     cations: ABNF."  RFC2234, November 1997

     [IMAP4rev1] Crispin, M., "Internet Message Access Protocol - Ver-
     sion 4rev1," Work in Progress

     [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
     Requirement Levels," BCP 9, RFC2119, March 1997

     [URI] Berners-Lee, T., et al, "Uniform Resource Identifiers (URI):
     Generic Syntax," RFC2396, August 1998

6.  Security Considerations

     >>> TBD <<<

Nerenberg          draft-nerenberg-imap-channel-02.txt          [Page 5]

Internet Draft      IMAP4 Channel Transport Mechanism          June 2002

7.  Authors' Addresses

      Lyndon Nerenberg                    Steve Hole
      ACI Worldwide                       ACI Worldwide
      Suite 900                           Suite 900
      10117 - Jasper Avenue               10117 - Jasper Avenue
      Edmonton, Alberta                   Edmonton, Alberta
      Canada T5J 1W8                      Canada T5J 1W8

      <>       <>
      Phone: +1 780 424 4922              Phone: +1 780 424 4922

      Barry Leiba
      IBM T.J. Watson Research Center
      30 Saw Mill River Road
      Hawthorne, NY  10532
      Phone: +1 914 784 7941

Nerenberg          draft-nerenberg-imap-channel-02.txt          [Page 6]