Lemonade Working Group L. Nerenberg
Internet-Draft Orthanc Systems
Expires: January 16, 2005 S. Hole
ACI Worldwide
B. Leiba
IBM T.J. Watson Research Center
July 18, 2004
IMAP4 Channel Transport Mechanism
draft-ietf-lemonade-imap-channel-02
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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.
This Internet-Draft will expire on January 16, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Nerenberg, et al. Expires January 16, 2005 [Page 1]
Internet-Draft IMAP4 Channel Transport Mechanism July 2004
Table of Contents
1. Conventions Used in this Document . . . . . . . . . . . . . . 3
2. Protocol Framework . . . . . . . . . . . . . . . . . . . . . . 3
2.1 CAPABILITY Identification . . . . . . . . . . . . . . . . 3
2.2 CHANNEL Command . . . . . . . . . . . . . . . . . . . . . 3
2.3 UID CHANNEL Command . . . . . . . . . . . . . . . . . . . 4
2.4 CHANNEL Response . . . . . . . . . . . . . . . . . . . . . 4
2.5 CHANNELSCHEMES Command . . . . . . . . . . . . . . . . . . 4
2.6 CHANNELSCHEMES Response . . . . . . . . . . . . . . . . . 5
3. Command Sequencing . . . . . . . . . . . . . . . . . . . . . . 5
4. Formal Protocol Syntax . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
A. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
B. Administrivia . . . . . . . . . . . . . . . . . . . . . . . . 7
C. Document Revision History . . . . . . . . . . . . . . . . . . 8
C.1 Changes in draft -02 . . . . . . . . . . . . . . . . . . . 8
D. Outstanding Issues . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . 9
Nerenberg, et al. Expires January 16, 2005 [Page 2]
Internet-Draft IMAP4 Channel Transport Mechanism July 2004
1. 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.
2. Protocol Framework
This memo defines the following extensions to [IMAP4].
2.1 CAPABILITY Identification
IMAP4 servers that support this extension MUST advertise the
"CHANNEL" capability.
2.2 CHANNEL Command
The CHANNEL command requests that message data be retrieved through
an external scheme. Clients may issue a request specifying a
partially-qualified URI, in which case the server will determine the
final connection end\-point. What constitutes a partially-qualified
URI is implementation defined.
The syntax of the CHANNEL command is:
tag CHANNEL channel-uri-list channel-set
<channel-uri-list> is a list of URIs and schemes specifying how the
client desires to retrieve the message data. If <channel-uri-list>
contains more than one element the server SHOULD return the message
data using the first element 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 specifies
the sequence number of the message to act on.
The CHANNEL command is only valid in the selected state.
Example:
C: 0 CHANNEL (rtsp ftp://marvin@example.net/incoming/)
(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
IMAP server should attempt to transfer the requested data to the FTP
Nerenberg, et al. Expires January 16, 2005 [Page 3]
Internet-Draft IMAP4 Channel Transport Mechanism July 2004
server at example.com.
In either case the server will fill in the connection end-point
information.
2.3 UID CHANNEL Command
The UID CHANNEL command is identical to the CHANNEL command with the
exception that the message numbers in the sequence sets refer to
unique identifiers instead of message sequence numbers.
2.4 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
<section-spec> 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 server MUST NOT issue an untagged CHANNEL response containing a
URI until such time as that URI is avaliable for the client to
dereference. The lifetime of the URI is implementation defined.
For example, 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
ftp://marvin@example.com/incoming/abzzqfw11423
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 any of the requested schemes. For
example, this could be caused by the inability to convert or
represent the content via the requested schemes, or because a
resource was unavailable.
2.5 CHANNELSCHEMES Command
The CHANNELSCHEMES command queries the server for the list of schemes
it supports.
Nerenberg, et al. Expires January 16, 2005 [Page 4]
Internet-Draft IMAP4 Channel Transport Mechanism July 2004
The syntax of the CHANNELSCHEMES command is:
tag CHANNELSCHEMES
2.6 CHANNELSCHEMES Response
A tagged CHANNELSCHEMES response is returned in response to a
CHANNELSCHEMES command.
The syntax of the CHANNELSCHEMES response is:
tag CHANNELSCHEMES channelschemes-data
3. Command Sequencing
There is no way to distinguish between a response to a CHANNEL
command and a UID CHANNEL command, therefore 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.
Servers MUST NOT send an EXPUNGE response while responding to a
CHANNEL command, however a server MAY send an EXPUNGE response during
a UID CHANNEL command.
4. Formal Protocol Syntax
The following syntax specification uses the augmented Backus-Naur
Form (ABNF) notation as defined in [ABNF], and incorporates by
reference the Core Rules from that document. This syntax extends the
grammar specified in [IMAP4].
The following tokens are incorporated from [URI]: absoluteURI,
scheme.
Nerenberg, et al. Expires January 16, 2005 [Page 5]
Internet-Draft IMAP4 Channel Transport Mechanism July 2004
channel = "CHANNEL" SP channel-uri-list
SP channel-set
channelschemes = "CHANNELSCHEMES"
channelschemes-data = astring / "(" astring 1*(SP astring) ")"
; <astring> encodes a <scheme>
channel-data = nz-number SP "CHANNEL" SP section-spec SP
astring
; <astring> encodes an <absoluteURI>
channel-set = 1*("(" nz-number SP section-spec ")")
; <nz-number> refers to the message sequence
; number or unique identifier.
channel-uri-list = "(" channel-uri
*(SP channel-uri) ")"
channel-uri = astring
; <absoluteURI> / <scheme>
; represented as an IMAP <astring>
command-auth =/ channelschemes
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>
uid =/ channel
5. Security Considerations
It is assumed that the IMAP server and its cooperating client share
an authorization (and authentication) namespace.
6 Normative References
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
Nerenberg, et al. Expires January 16, 2005 [Page 6]
Internet-Draft IMAP4 Channel Transport Mechanism July 2004
[KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
Authors' Addresses
Lyndon Nerenberg
Orthanc Systems
304 - 1755 Robson Street
Vancouver, BC V6G 3B7
CA
EMail: lyndon+rfc-imap-channel@orthanc.ca
Steve Hole
ACI Worldwide
Suite 1807
10088 - 102 Avenue
Edmonton, Alberta T5J 2Z1
CA
Phone: +1 780 424 4922
Fax: +1 780 424 4925
EMail: steve.hole@messagingdirect.com
Barry Leiba
IBM T.J. Watson Research Center
30 Saw Mill River Road
Hawthorne, NY 10532
US
Phone: +1 914 784 7941
EMail: leiba@watson.ibm.com
Appendix A. IANA Considerations
IANA is requested to update the IMAP capabilities registry to add the
CHANNEL capability defined by this memo.
Appendix B. Administrivia
[This appendix will not appear in the final document.]
Nerenberg, et al. Expires January 16, 2005 [Page 7]
Internet-Draft IMAP4 Channel Transport Mechanism July 2004
Discussion concerning this draft should be directed to the
<lemonade@ietf.org> mailing list.
Appendix C. Document Revision History
[This appendix will not appear in the final document.]
Appendix C.1 Changes in draft -02
1. Revert text to that from draft-nerenberg-imap-channel-01, which
again forms the baseline document for the specification. The
usage and implementation guide will be split out into another
memo seperate from the specification itself.
2. Revert to the simple string "channel" for the capability. The
old scheme (channel=foo,bar) required parsable capabilities. A
new command (CHANNELSCHEMES) is proposed for discovering the
supported scheme list.
3. The grammar has been cleaned up and synced with RFC3501.
4. References to schemes in the protocol no longer include the
trailing ":" in the scheme name (e.g. we now use "ftp" rather
than "ftp:"). The grammar is now unambiguous with reference to
the use of <scheme> and <absoluteURI> (a scheme name cannot
contain a ":", and an <absoluteURI> requires one). Both types
are now encoded as <astring>.
5. Document reformatted to meet the latest RFC Editor's
requirements.
6. Added a CHANNELSCHEMES command, used to discover the schemes
supported by the server.
Appendix D. Outstanding Issues
[This appendix will not appear in the final document.]
1. The Security Considerations section needs to be expanded.
2. Examples need a seperate section.
Nerenberg, et al. Expires January 16, 2005 [Page 8]
Internet-Draft IMAP4 Channel Transport Mechanism July 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Nerenberg, et al. Expires January 16, 2005 [Page 9]
