[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group                                            S. Hole
Internet Draft: IMAP4 Channel Transport Mechanism           L. Nerenberg
Document: draft-nerenberg-imap-channel-01.txt              ACI Worldwide
                                                                B. Leiba
                                                            IBM Research
                                                           November 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 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
     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.  Dis-
     cussion and suggestions for improvement are requested.  Distribu-
     tion of this draft is unlimited.

0.  Administrivia

Lines prefixed with ">>>" are 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



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

Internet Draft      IMAP4 Channel Transport Mechanism      November 2001


     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.  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
     comma-seperated 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, however every URI MUST contain at least a scheme.

     The syntax of the CHANNEL command is:

        tag CHANNEL uri-list channel-set

     uri-list is a list of URIs specifying how the client is willing to
     retrieve the message data. If uri-list contains more than one ele-
     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.

     channel-set is a list of message body sections to be retrieved



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

Internet Draft      IMAP4 Channel Transport Mechanism      November 2001


     through the specified URI.

     >>> example syntax:
     >>>  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 method is RTSP, however if
     >>> RTSP isn't available/usable, try IMAP. In either case,
     >>> the server will fill in the connection end-point
     >>> information.  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 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 through the schemes,
     >>> or because some resource was unavailable.

     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 (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]: 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 ")" )




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

Internet Draft      IMAP4 Channel Transport Mechanism      November 2001


     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

     [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


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

      <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










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


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/