< draft-newman-lemonade-compose-00.txt		draft-newman-lemonade-compose-01.txt >
	Network Working Group C. Newman		Network Working Group C. Newman
	Internet-Draft Sun Microsystems		Internet-Draft Sun Microsystems
	Expires: December 19, 2003 June 20, 2003		Expires: August 10, 2004 February 10, 2004
	Message Composition		Message Submission with Composition
	draft-newman-lemonade-compose-00.txt		draft-newman-lemonade-compose-01.txt
	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 RFC2026.		all provisions of Section 10 of RFC2026.
	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 other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	skipping to change at page 1, line 30 ¶		skipping to change at page 1, line 30 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at http://		The list of current Internet-Drafts can be accessed at http://
	www.ietf.org/ietf/1id-abstracts.txt.		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.
	This Internet-Draft will expire on December 19, 2003.		This Internet-Draft will expire on August 10, 2004.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Abstract
	The submission profile of Simple Mail Transfer Protocol (SMTP)		The submission profile of Simple Mail Transfer Protocol (SMTP)
	provides a standard way for an email client to submit a complete		provides a standard way for an email client to submit a complete
	message for delivery. The chunking extension provides a way for a		message for delivery. The chunking extension provides a way for a
	client to compose a message for submission from a series of client		client to compose a message for submission from a series of client
	provided pieces. This specification further extends the chunking		provided pieces. This specification further extends the chunking
	facility so that a client can compose a message from additional		facility so that a client can compose a message from additional
	sources. For example, a client could use this facility to forward a		sources. For example, a client could use this facility to forward a
	message from an IMAP server or forward a web page as an attachment to		message from an IMAP server or forward a web page as an attachment to
	a new message.		a new message.
	Table of Contents		Table of Contents
	1. Conventions Used in this Document . . . . . . . . . . . . . . 3		1. Conventions Used in this Document . . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. BURL Submission Extension . . . . . . . . . . . . . . . . . . 3		3. BURL Submission Extension . . . . . . . . . . . . . . . . . . 3
	3.1 SMTP Submission Extension Registration . . . . . . . . . . . . 3		3.1 SMTP Submission Extension Registration . . . . . . . . . . . . 3
	3.2 Composition Transation . . . . . . . . . . . . . . . . . . . . 4		3.2 Composition Transaction . . . . . . . . . . . . . . . . . . . 4
	3.3 Supported URIs . . . . . . . . . . . . . . . . . . . . . . . . 4		3.3 Supported URIs . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.4 Transfer Encoding Conversion . . . . . . . . . . . . . . . . . 5		3.4 Transfer Encoding Conversion . . . . . . . . . . . . . . . . . 5
	3.5 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		3.5 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.6 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 6		3.6 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. Message Composition for Small Devices . . . . . . . . . . . . 6		4. Message Submission with Composition for Small Devices . . . . 6
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 7		6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	Normative References . . . . . . . . . . . . . . . . . . . . . 7		7. Changes from -00 . . . . . . . . . . . . . . . . . . . . . . . 7
	Informative References . . . . . . . . . . . . . . . . . . . . 8		Normative References . . . . . . . . . . . . . . . . . . . . . 8
			Informative References . . . . . . . . . . . . . . . . . . . . 9
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9		Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9
	Intellectual Property and Copyright Statements . . . . . . . . 10		Intellectual Property and Copyright Statements . . . . . . . . 10
	1. Conventions Used in this Document		1. 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 defined in "Key words for		in this document are to be interpreted as defined in "Key words for
	use in RFCs to Indicate Requirement Levels" [5].		use in RFCs to Indicate Requirement Levels" [5].
	The formal syntax use the Augmented Backus-Naur Form (ABNF) [6]		The formal syntax use the Augmented Backus-Naur Form (ABNF) [6]
	skipping to change at page 4, line 21 ¶		skipping to change at page 4, line 21 ¶
	fail and the data is consumed, and the BURL commands also fail		fail and the data is consumed, and the BURL commands also fail
	without triggering a fetch of the URL.		without triggering a fetch of the URL.
	5. This extension adds no new parameters to the MAIL or RCPT verbs.		5. This extension adds no new parameters to the MAIL or RCPT verbs.
	6. The BURL verb is used during a CHUNKING SMTP transaction. If the		6. The BURL verb is used during a CHUNKING SMTP transaction. If the
	argument is a valid URL which the submit server can resolve to a		argument is a valid URL which the submit server can resolve to a
	data object, the submit server will resolve the URL and		data object, the submit server will resolve the URL and
	optionally apply a content-transfer-encoding.		optionally apply a content-transfer-encoding.
	3.2 Composition Transation		3.2 Composition Transaction
	When a composition client connects to a composition server, it will		When a composition client connects to a composition server, it will
	first authenticate (using SMTP AUTH and perhaps STARTTLS), and then		first authenticate (using SMTP AUTH and perhaps STARTTLS), and then
	can compose and submit any number of messages with full		can compose and submit any number of messages with full
	interoperabilty with important SMTP extensions such as delivery		interoperability with important SMTP extensions such as delivery
	status notifications [14]. Each message which is composed and		status notifications [14]. Each message which is composed and
	submitted is called a message composition transation.		submitted is called a message composition transaction.
	A message composition transaction will typically consist of a MAIL		A message composition transaction will typically consist of a MAIL
	FROM, one or more RCPT TO headers, an initial BDAT, and an optional		FROM, one or more RCPT TO headers, an initial BDAT, an optional
	series of BURL or BDAT commands, and a BDAT command with the "LAST"		series of BURL or BDAT commands, and a BURL or BDAT command with the
	tag. The client is permitted to pipelined [22] the entire		"LAST" tag. The client is permitted to pipeline [22] the entire
	transaction in one round-trip. However, it must wait for the results		transaction in one round-trip. However, it MUST wait for the results
	of the "LAST" BDAT command prior to initiating a new transaction.		of the "LAST" BDAT or BURL command prior to initiating a new
			transaction.
	The BURL command directs the server to fetch the data object to which		The BURL command directs the server to fetch the data object to which
	the URL refers, perform any necessary content transfer encoding		the URL refers, perform any necessary content transfer encoding
	conversions on that object and include it in the message. If the URL		conversions on that object and include it in the message. If the URL
	fetch or conversion fails, the server will either fail the entire		fetch or conversion fails, the server will either fail the entire
	transaction (including consuming any subsequent BURL commands in the		transaction (including consuming any subsequent BDAT or BURL commands
	pipeline) or retry the composition later based on the value of the		in the pipeline) or retry the composition later based on the value of
	"failhow" argument to BURL.		the "failhow" argument to BURL.
	3.3 Supported URIs		3.3 Supported URIs
	The BURL EHLO keyword arguments list the types of URIs the		The BURL EHLO keyword arguments list the types of URIs the
	composition server can resolve. If it lists just the scheme name,		composition server can resolve. If it lists just the scheme name,
	that indicates the server supports all forms of that URI which refer		that indicates the server supports all forms of that URI which refer
	to a single data object. In the case of IMAP URLs [20], advertising		to a single data object. In the case of IMAP URLs [20], advertising
	the bare scheme name indicates the server also supports the URLAUTH		the bare scheme name indicates the server also supports the URLAUTH
	[23] extended form.		[23] extended form.
	skipping to change at page 5, line 35 ¶		skipping to change at page 5, line 36 ¶
	transfer encoding conversion after resolving the URL.		transfer encoding conversion after resolving the URL.
	o The "base64" conversion indicates that if the data was already		o The "base64" conversion indicates that if the data was already
	base64 encoded, it should be left unchanged. Otherwise, any		base64 encoded, it should be left unchanged. Otherwise, any
	content transfer encoding is removed and the result is base64		content transfer encoding is removed and the result is base64
	encoded.		encoded.
	o The "8bit" conversion indicates that any content transfer encoding		o The "8bit" conversion indicates that any content transfer encoding
	is removed, lines longer than 998 characters MUST be wrapped onto		is removed, lines longer than 998 characters MUST be wrapped onto
	multiple lines by insertion of a CRLF, NUL octets MUST be dropped,		multiple lines by insertion of a CRLF, NUL octets MUST be dropped,
	and bare newline or bare carrage return MUST be converted to CRLF.		and bare newline or bare carriage return MUST be converted to
			CRLF.
	o The "none" conversion indicates that the data is unchanged and any		o The "none" conversion indicates that the data is unchanged and any
	original content transfer encoding is left in place. If the		original content transfer encoding is left in place. If the
	server does not advertise BINARYMIME and if the raw data would		server does not advertise BINARYMIME and if the raw data would
	require any changes to be labelled "8bit", then the server MUST		require any changes to be labelled "8bit", then the server MUST
	fail the BURL command.		fail the BURL command.
	o The "binary" conversion is only permitted if the BINARYMIME EHLO		o The "binary" conversion is only permitted if the BINARYMIME EHLO
	keyword was advertised, and indicates any content transfer		keyword was advertised, and indicates any content transfer
	encoding is to be removed and the data is to be included otherwise		encoding is to be removed and the data is to be included otherwise
	skipping to change at page 6, line 19 ¶		skipping to change at page 6, line 21 ¶
	3.6 Formal Syntax		3.6 Formal Syntax
	The following syntax specification inherits ABNF [6] and Uniform		The following syntax specification inherits ABNF [6] and Uniform
	Resource Identifiers [7].		Resource Identifiers [7].
	burl-param = scheme / absoluteURI / trusted-domain		burl-param = scheme / absoluteURI / trusted-domain
	; parameter to BURL EHLO keyword		; parameter to BURL EHLO keyword
	burl-cmd = "BURL" SP conversion SP failhow		burl-cmd = "BURL" SP conversion SP failhow
	SP absoluteURI CRLF		SP absoluteURI [SP end-marker] CRLF
	conversion = "base64" / "8bit" / "binary" / "none"		conversion = "base64" / "8bit" / "binary" / "none"
	failhow = "now" / "retry"		failhow = "now" / "retry"
			end-marker = "LAST"
	trusted-domain = scheme "://" authority		trusted-domain = scheme "://" authority
	4. Message Composition for Small Devices		4. Message Submission with Composition for Small Devices
	A Message Submission [8] server is considered to be a compliant		A Message Submission [8] server is considered to be a compliant
	Message Composition server if it implements the following		Message Submission with Composition server if it implements the
	specifications:		following specifications:
	o BURL (Section 3): Mandatory		o BURL (Section 3): Mandatory
	o DSN [14]: Mandatory		o DSN [14]: Mandatory
	o STARTTLS [13]: Mandatory		o STARTTLS [13]: Mandatory
	o CHUNKING [12]: Mandatory		o CHUNKING [12]: Mandatory
	o BINARYMIME [12]: Mandatory		o BINARYMIME [12]: Mandatory
	skipping to change at page 7, line 41 ¶		skipping to change at page 7, line 46 ¶
	Implementations which support the URLAUTH [23] form of IMAP URLs MUST		Implementations which support the URLAUTH [23] form of IMAP URLs MUST
	implement both the SMTP STARTTLS [13] and the IMAP STARTTLS [15]		implement both the SMTP STARTTLS [13] and the IMAP STARTTLS [15]
	extensions and MUST have a configuration setting which requires their		extensions and MUST have a configuration setting which requires their
	use with such IMAP URLs.		use with such IMAP URLs.
	When a client uses the SMTP STARTTLS to send a BURL command which		When a client uses the SMTP STARTTLS to send a BURL command which
	references non-public information, the message submission server MUST		references non-public information, the message submission server MUST
	use STARTTLS or a mechanism providing equivalent data privacy when		use STARTTLS or a mechanism providing equivalent data privacy when
	resolving that URL.		resolving that URL.
			7. Changes from -00
			o Added the end-marker "LAST", so this could be used without BDAT
			and works with a pre-composed message.
			o Changed "Message Composition" to "Message Submission with
			Composition" in several places.
			o Correct Spelling Errors
	Normative References		Normative References
	[1] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker,		[1] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker,
	"SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July		"SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July
	1994.		1994.
	[2] Klensin, J., Freed, N. and K. Moore, "SMTP Service Extension		[2] Klensin, J., Freed, N. and K. Moore, "SMTP Service Extension
	for Message Size Declaration", STD 10, RFC 1870, November 1995.		for Message Size Declaration", STD 10, RFC 1870, November 1995.
	[3] Freed, N., "SMTP Service Extension for Returning Enhanced Error		[3] Freed, N., "SMTP Service Extension for Returning Enhanced Error
	skipping to change at page 10, line 29 ¶		skipping to change at page 10, line 29 ¶
	be obtained from the IETF Secretariat.		be obtained from the IETF Secretariat.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights which may cover technology that may be required to practice		rights which may cover technology that may be required to practice
	this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF Executive
	Director.		Director.
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of		Internet organizations, except as needed for the purpose of
	skipping to change at page 11, line 7 ¶		skipping to change at page 11, line 7 ¶
	The limited permissions granted above are perpetual and will not be		The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assignees.		revoked by the Internet Society or its successors or assignees.
	This document and the information contained herein is provided on an		This document and the information contained herein is provided on an
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Acknowledgement		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 20 change blocks.
	27 lines changed or deleted		42 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/