One document matched: draft-nerenberg-imap-channel-02.txt
Differences from draft-nerenberg-imap-channel-01.txt
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
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
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)
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.
Add UID CHANNEL.
Clarify response when client issues a command with an unsupported
scheme.
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
URI.
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
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.
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.
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
<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.
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 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
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 correspond-
ing request, therefore responses to UID CHANNEL commands report the
message UID rather than the message sequence number.
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
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 <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,
scheme.
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
<lyndon@atg.aciworldwide.com> <steve.hole@messagingdirect.com>
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
<leiba@watson.ibm.com>
Phone: +1 914 784 7941
Nerenberg draft-nerenberg-imap-channel-02.txt [Page 6]
| PAFTECH AB 2003-2026 | 2026-04-23 16:04:53 |