< draft-nerenberg-imap-channel-00.txt		draft-nerenberg-imap-channel-01.txt >
	Network Working Group S. Hole		Network Working Group S. Hole
	Internet Draft: IMAP4 Channel Transport Mechanism L. Nerenberg		Internet Draft: IMAP4 Channel Transport Mechanism L. Nerenberg
	Document: draft-nerenberg-imap-channel-00.txt ACI/Messagingdirect		Document: draft-nerenberg-imap-channel-01.txt ACI Worldwide
	B. Leiba		B. Leiba
	IBM Research		IBM Research
	February 2001		November 2001
	IMAP4 Channel Transport Mechanism		IMAP4 Channel Transport Mechanism
	Status of this memo		Status of this memo
	This document is an Internet Draft and is in full conformance with		This document is an Internet Draft and is in full conformance with
	all provisions of Section 10 of RFC 2026.		all provisions of Section 10 of RFC 2026.
	Internet Drafts are working documents of the Internet Engineering		Internet Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet		other groups may also distribute working documents as Internet
	Drafts.		Drafts.
	Internet Drafts are draft documents valid for a maximum of six		Internet Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other		months and may be updated, replaced, or obsoleted by other docu-
	documents at any time. It is inappropriate to use Internet Drafts		ments at any time. It is inappropriate to use Internet Drafts as
	as reference material or to cite them other than as "work in		reference material or to cite them other than as "work in
	progress.rq		progress.rq
	The list of current Internet Drafts can be accessed at		The list of current Internet Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet Draft Shadow Directories can be accessed at		The list of Internet Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	A revised version of this draft document will be submitted to the		A revised version of this draft document will be submitted to the
	RFC editor as a Proposed Standard for the Internet Community.		RFC editor as a Proposed Standard for the Internet Community. Dis-
	Discussion and suggestions for improvement are requested.		cussion and suggestions for improvement are requested. Distribu-
	Distribution of this draft is unlimited.		tion of this draft is unlimited.
	0. Administrivia		0. Administrivia
	Lines prefixed with ">>>" are meta-comments.		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		1. Abstract
	IMAP4 is being used to serve rich media content in environments		IMAP4 is being used to serve rich media content in environments
	that extend beyond traditional text-based e-mail. One example is a		that extend beyond traditional text-based e-mail. One example is a
	cellular telephone that can retrieve and send MIME-encoded audio		cellular telephone that can retrieve and send MIME-encoded audio
	data through IMAP4. While this type of content can be exchanged		data through IMAP4. While this type of content can be exchanged
	natively using IMAP4, some applications will work better if the		natively using IMAP4, some applications will work better if the
	message content can be manipulated using schemes external to the		message content can be manipulated using schemes external to the
	IMAP4 connection. In our cellular telephone example, it might be		IMAP4 connection. In our cellular telephone example, it might be
	preferable for the telephone client to retrieve the audio data		preferable for the telephone client to retrieve the audio data
	using RTSP. This specifications defines a mechanism for an IMAP4		using RTSP. This specifications defines a mechanism for an IMAP4
	client to request message content from a server through an external		client to request message content from a server through an external
	scheme.		scheme.
	2. Conventions Used in this Document		2. Conventions Used in this Document
	The key words "MUST," "MUST NOT," "SHOULD," "SHOULD NOT," and "MAY"		The key words "MUST," "MUST NOT," "SHOULD," "SHOULD NOT," and "MAY"
	in this document are to be interpreted as described in [KEYWORD].		in this document are to be interpreted as described in [KEYWORD].
	In examples, "C:" and "S:" preface lines sent by the client and the		In examples, "C:" and "S:" preface lines sent by the client and the
	server respectively.		server respectively.
	3. Overview		3. Protocol Framework
	4. Protocol Framework
	This memo defines the following extensions to [IMAP4].		This memo defines the following extensions to [IMAP4rev1].
	4.1. CAPABILITY Identification		3.1. CAPABILITY Identification
	IMAP4 servers that support this extension MUST include a CHANNEL		IMAP4 servers that support this extension MUST include a CHANNEL
	capability response in the response list to the CAPABILITY command.		capability response in the response list to the CAPABILITY command.
	This entry indicates the server supports the extension, and lists		This entry indicates the server supports the extension, and lists
	the external schemes available to the CHANNEL command. The capabil-		the schemes available to the CHANNEL command. The capability
	ity response consists of the string "CHANNEL=" followed by a comma-		response consists of the string "CHANNEL=" followed by a
	seperated list of CHANNEL services.		comma-seperated list of schemes supported by the CHANNEL extension.
	>>> 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. CHANNEL Command		3.2. CHANNEL Command
	The CHANNEL command requests that message data be retrieved through		The CHANNEL command requests that message data be retrieved through
	an external scheme. The scheme is specified using a URI [URI].		an external scheme. Clients may issue a partially-qualified URI, in
	Clients may issue a partially-qualified URI, in which case the		which case the server will determine the final connection
	server will determine the final connection end-point. What consti-		end-point. What constitutes a partially-qualified URI is implemen-
	tutes a partially-qualified URI is implementation defined, however		tation defined, however every URI MUST contain at least a scheme.
	every URI MUST contain at least a scheme.
	The syntax of the CHANNEL command is:		The syntax of the CHANNEL command is:
	tag CHANNEL uri_list msg_set		tag CHANNEL uri-list channel-set
	uri_list is a list of URIs specifying the locations where the		uri-list is a list of URIs specifying how the client is willing to
	client is willing to retrieve the message data. If the list con-		retrieve the message data. If uri-list contains more than one ele-
	tains more than one element the server must enumerate the list in		ment the server must enumerate the list in order and SHOULD return
	order and SHOULD return the message data via the first URI it is		the message data via the first URI it is capable of using.
	capable of using.
	>>> the intent is that the client can indicate a list of		>>> the intent is that the client can indicate a list of
	>>> services in descending order of usefulness/quality.		>>> services in descending order of usefulness/quality.
			>>> Also, there is no guarantee that a server can express a
	>>> Also, there is no guarantee that a server can express		>>> particular body section through all of its advertised
	>>> a particular body section through all of its advertised
	>>> schemes, thus the list provides fallback for the server		>>> schemes, thus the list provides fallback for the server
	>>> as well as the client.		>>> as well as the client.
	msg_set is a list of messages and body sections to be retrieved		channel-set is a list of message body sections to be retrieved
	through the specified URI.		through the specified URI.
	>>> example syntax:		>>> example syntax:
	>>>		>>> 0 CHANNEL (rtsp imap) (1 2)(3 1)(3 9.1)
	>>> 0 CHANNEL ("rtsp:" "imap:") (1 (body[2])) (3 (body[1] body[9]))		>>> asks for section 2 of message 1 and sections 1 and 9.1
	>>>		>>> of message 3. The preferred method is RTSP, however if
	>>> asks for section 2 of message 1 and section 1 of message		>>> RTSP isn't available/usable, try IMAP. In either case,
	>>> 3 via RTSP. If RTSP isn't available/usable, try IMAP. In		>>> the server will fill in the connection end-point
	>>> either case, the server will fill in the connection end-point		>>> information. You cannot ask for .HEADERS or .MIME data
	>>> information.		>>> with CHANNEL.
	4.3. CHANNEL Response		3.3. CHANNEL Response
	The CHANNEL response returns connection status and location infor-		The CHANNEL response returns connection status and location infor-
	mation to the client. One untagged response is returned for each		mation to the client. One untagged response is returned for each
	body section requested.		body section requested.
	>>> example response to above command:		>>> example response to above command:
	>>>		>>>
	>>> S: * 1 CHANNEL ((body[2]) "rtsp://example.com/1441243")		>>> S: * 1 CHANNEL 2 rtsp://frobozz.example.com/144124
	>>> S: * 3 CHANNEL ((body[1])		>>> S: * 3 CHANNEL 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)		>>> S: * 3 CHANNEL 9.1 NIL
	>>> S: 0 OK done		>>> S: 0 OK done
	>>>		>>>
	>>> The NIL response to the body[9] indicates that the part could not		>>> The NIL response to the section 9.1 request indicates
	>>> be retrieved via either of the requested schemes. This could		>>> that the part could not be retrieved via either of the
	>>> be caused by the inability to convert or represent the content		>>> requested schemes. This could be caused by the inability
	>>> through the schemes, or because some resource was unavailable.		>>> to convert or represent the content through the schemes,
			>>> or because some resource was unavailable.
	5. Formal Protocol Syntax		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		The following syntax specification uses the augmented Backus-Naur
	Form (BNF) notation as used in [IMAP4].		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].
	Except as noted otherwise, all alphabetic characters are case-		The following tokens are incorporated from [URI]: scheme, URI-ref-
	insensitive. The use of upper or lower case characters to define		erence.
	token strings is for editorial clarity only. Implementations MUST
	accept these strings in a case-insensitive fashion.
	This syntax extends the grammar specified in [IMAP4].		capability =/ "CHANNEL=" scheme *["," scheme]
	>>> TO BE DONE		channel = "CHANNEL" SP uri-list SP channel-set
	6. References		channel-data = "CHANNEL" nz-number (URI-reference / nil)
	[IMAP4] Crispin, M., "Internet Message Access Protocol Version		channel-set = 1*( "(" nz-number SP section-part ")" )
	4rev1," RFC2060, University of Washington, December 1996		command-select =/ channel
	[URI] Berners-Lee, T., et al, "Uniform Resource Identifiers (URI):		response-data = "*" SP (resp-cond-state / resp-cond-bye /
	Generic Syntax," RFC2396, August 1998		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		[KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels," BCP 9, RFC2119, March 1997		Requirement Levels," BCP 9, RFC2119, March 1997
	7. Security Considerations		[URI] Berners-Lee, T., et al, "Uniform Resource Identifiers (URI):
			Generic Syntax," RFC2396, August 1998
	8. Authors' Addresses		6. Security Considerations
	Lyndon Nerenberg Steve Hole		7. Authors' Addresses
	ACI/MessagingDirect ACI/MessagingDirect
	Suite 900 Suite 900
	10117 - Jasper Avenue 10117 - Jasper Avenue
	Edmonton, Alberta Edmonton, Alberta
	Canada T5J 1W8 Canada T5J 1W8
	<lyndon@messagingdirect.com> <steve.hole@messagingdirect.com>		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		Barry Leiba
	IBM T.J. Watson Research Center		IBM T.J. Watson Research Center
	30 Saw Mill River Road		30 Saw Mill River Road
	Hawthorne, NY 10532		Hawthorne, NY 10532
	<leiba@watson.ibm.com>		<leiba@watson.ibm.com>
	Phone: +1 914 784 7941		Phone: +1 914 784 7941
End of changes. 34 change blocks.
	85 lines changed or deleted		101 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/