Diff: draft-freed-bsmtp-00.txt - draft-freed-bsmtp-01.txt

	< draft-freed-bsmtp-00.txt	draft-freed-bsmtp-01.txt >

	Network Working Group Ned Freed, Innosoft	Network Working Group Ned Freed, Innosoft
	Internet Draft Dan Newman, Innosoft	Internet Draft Dan Newman, Innosoft

	<draft-freed-bsmtp-00.txt> Mark Hoy, SunSoft	<draft-freed-bsmtp-01.txt> Mark Hoy, SunSoft
	Jacques Belissent, SunSoft	Jacques Belissent, SunSoft

	The	The
	Batch SMTP	Batch SMTP
	Media Type	Media Type


	December 1997	August 1998

	Status of this Memo	Status of this Memo

	This document is an Internet-Draft. Internet-Drafts are	This document is an Internet-Draft. Internet-Drafts are
	working documents of the Internet Engineering Task Force	working documents of the Internet Engineering Task Force
	(IETF), its areas, and its working groups. Note that other	(IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-	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. Internet-Drafts may be updated, replaced, or obsoleted	months. Internet-Drafts may be updated, replaced, or obsoleted
	by other documents at any time. It is not appropriate to use	by other documents at any time. It is not appropriate to use
	Internet-Drafts as reference material or to cite them other	Internet-Drafts as reference material or to cite them other
	than as a "working draft" or "work in progress".	than as a "working draft" or "work in progress".


	To learn the current status of any Internet-Draft, please	To view the entire list of current Internet-Drafts, please check
	check the 1id-abstracts.txt listing contained in the	the "1id-abstracts.txt" listing contained in the Internet-Drafts
	Internet-Drafts Shadow Directories on ds.internic.net (US East	Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
	Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast),	(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
	or munnari.oz.au (Pacific Rim).	(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
		(US West Coast).


	Copyright (C) The Internet Society (1997). All Rights	Copyright (C) The Internet Society (1998). All Rights
	Reserved.	Reserved.

	1. Abstract	1. Abstract

	This document defines a MIME content type suitable for	This document defines a MIME content type suitable for

	tunneling a an ESMTP [RFC-821, RFC-1869] transaction through	tunneling an ESMTP [RFC-821, RFC-1869] transaction through any
	any MIME-capable transport. This type can be used for a	MIME-capable transport. This type can be used for a variety
	variety of purposes, including:	of purposes, including:


	(1) Extending end-to-end MIME-based security services (e.g.	(1) Extending end-to-end MIME-based security services
	[RFC-1847]) to cover message envelope information as	(e.g., [RFC-1847]) to cover message envelope
	well as message content.	information as well as message content.

	(2) Making it possible to use specific SMTP extensions such	(2) Making it possible to use specific SMTP extensions such
	as NOTARY [RFC-1891] over unextended SMTP transport	as NOTARY [RFC-1891] over unextended SMTP transport
	infrastructure.	infrastructure.

	(3) Enabling the transfer of multiple separate messages in	(3) Enabling the transfer of multiple separate messages in
	a single transactional unit.	a single transactional unit.

	1.1. Requirements Notation	1.1. Requirements Notation


	skipping to change at page 5, line 13 ¶	skipping to change at page 5, line 13 ¶
	context of batch SMTP. For example, the pipelining extension	context of batch SMTP. For example, the pipelining extension
	[RFC-1854] makes no sense in the absence of a network	[RFC-1854] makes no sense in the absence of a network
	connection.	connection.

	4.3. Handling Multiple Messages	4.3. Handling Multiple Messages

	Generators SHOULD attempt to minimize the number of messages	Generators SHOULD attempt to minimize the number of messages
	placed in a single application/batch-SMTP object. Ideally a	placed in a single application/batch-SMTP object. Ideally a
	single application/batch-SMTP object will be created for each	single application/batch-SMTP object will be created for each
	message. Note, however, that some uses of application/batch-	message. Note, however, that some uses of application/batch-

	SMTP (e.g. mail bagging) may exist solely to take advantage of	SMTP (e.g., mail bagging) may exist solely to take advantage
	the multiple messages in a single container capability of	of the multiple messages in a single container capability of
	batch SMTP, so requiring a one message per container is not	batch SMTP, so requiring a one message per container is not
	possible.	possible.


	DISCUSSION: The SMTP protocols provides for the transfer of a	DISCUSSION: The SMTP protocol provides for the transfer of a
	series of messages over a single connection. This extends in a	series of messages over a single connection. This extends in a
	natural way to batch SMTP. However, the issues in batch SMTP	natural way to batch SMTP. However, the issues in batch SMTP
	are somewhat different. Suppose, for example, that a batch	are somewhat different. Suppose, for example, that a batch
	SMTP processor receives an application/batch-SMTP object	SMTP processor receives an application/batch-SMTP object
	containing two messages but is unable to process the second	containing two messages but is unable to process the second
	message because of a storage allocation failure. But not only	message because of a storage allocation failure. But not only
	does this failure preclude processing of the second message,	does this failure preclude processing of the second message,
	it also precludes requeuing or otherwise noting that the first	it also precludes requeuing or otherwise noting that the first
	message has already been processed. Subsequent reprocessing of	message has already been processed. Subsequent reprocessing of
	the application/batch-SMTP then leads to duplication of the	the application/batch-SMTP then leads to duplication of the

	skipping to change at page 5, line 42 ¶	skipping to change at page 5, line 42 ¶
	problems with SMTP synchronization that in practice often lead	problems with SMTP synchronization that in practice often lead
	to duplicated messages. Since this behavior is inherent in	to duplicated messages. Since this behavior is inherent in
	SMTP to begin with it is not incumbent on application/batch-	SMTP to begin with it is not incumbent on application/batch-
	SMTP to completely address the issue. Nevertheless, it seems	SMTP to completely address the issue. Nevertheless, it seems
	prudent for application/batch-SMTP to try and not make matters	prudent for application/batch-SMTP to try and not make matters
	even worse.	even worse.

	5. Tranport of application/batch-SMTP objects	5. Tranport of application/batch-SMTP objects

	Application/batch-SMTP objects may be transported by any	Application/batch-SMTP objects may be transported by any

	transport capable of preserving their MIME labelling, e.g.	transport capable of preserving their MIME labelling, e.g.,
	HTTP or SMTP.	HTTP or SMTP.

	Transports MUST remain cognizant of the special nature of	Transports MUST remain cognizant of the special nature of
	application/batch-SMTP. An application/batch-SMTP object	application/batch-SMTP. An application/batch-SMTP object
	contains one or more "frozen" SMTP message transactions. SMTP	contains one or more "frozen" SMTP message transactions. SMTP
	message transactions typically carry with them various	message transactions typically carry with them various

	assumptions about quality of service, e.g. that messages will	assumptions about quality of service, e.g., that messages will
	either be delivered successfully or a nondelivery notification	either be delivered successfully or a nondelivery notification
	will be returned, that a nondelivery notification will be	will be returned, that a nondelivery notification will be
	returned if delivery cannot be accomplished in a timely	returned if delivery cannot be accomplished in a timely
	fashion, and so on. It is vital that the encapsulation of	fashion, and so on. It is vital that the encapsulation of
	these objects for carriage over other forms of transport not	these objects for carriage over other forms of transport not
	interfere with these capabilities.	interfere with these capabilities.

	6. Processing of application/batch-SMTP material	6. Processing of application/batch-SMTP material

	Processing of application/batch-SMTP material is considerably	Processing of application/batch-SMTP material is considerably

	skipping to change at page 7, line 17 ¶	skipping to change at page 7, line 17 ¶
	delivering the message.	delivering the message.

	(5) MUST accept any of the additional parameters defined by	(5) MUST accept any of the additional parameters defined by
	the 8bitMIME, SIZE, and NOTARY SMTP extensions on the	the 8bitMIME, SIZE, and NOTARY SMTP extensions on the
	MAIL FROM and RCPT TO commands.	MAIL FROM and RCPT TO commands.

	(6) MUST accept the DATA command even when no valid	(6) MUST accept the DATA command even when no valid
	recipients are present. 8bit MIME messages MUST be	recipients are present. 8bit MIME messages MUST be
	accepted.	accepted.


	(7) MUST accept the RSET command and handle multple	(7) MUST accept the RSET command and handle multiple
	messages in a single application/batch-SMTP object.	messages in a single application/batch-SMTP object.
	Processors MUST process each message in an	Processors MUST process each message in an
	application/batch-SMTP object once and SHOULD take	application/batch-SMTP object once and SHOULD take
	whatever steps are necessary to avoid processing a	whatever steps are necessary to avoid processing a
	message more than once. For example, if processing of	message more than once. For example, if processing of
	an application/batch-SMTP object containing multiple	an application/batch-SMTP object containing multiple
	messages is interrupted at an intermediate point it	messages is interrupted at an intermediate point it
	should subsequently be restarted at the end of the last	should subsequently be restarted at the end of the last
	message that was completely processed.	message that was completely processed.


	skipping to change at page 10, line 35 ¶	skipping to change at page 10, line 35 ¶
	email: ned.freed@innosoft.com	email: ned.freed@innosoft.com

	Mark Hoy	Mark Hoy
	SunSoft	SunSoft

	Jacques Bellisent	Jacques Bellisent
	SunSoft	SunSoft

	11. Full Copyright Statement	11. Full Copyright Statement


	Copyright (C) The Internet Society (1997). All Rights	Copyright (C) The Internet Society (1998). All Rights
	Reserved.	Reserved.

	This document and translations of it may be copied and	This document and translations of it may be copied and
	furnished to others, and derivative works that comment on or	furnished to others, and derivative works that comment on or
	otherwise explain it or assist in its implementation may be	otherwise explain it or assist in its implementation may be
	prepared, copied, published and distributed, in whole or in	prepared, copied, published and distributed, in whole or in
	part, without restriction of any kind, provided that the	part, without restriction of any kind, provided that the
	above copyright notice and this paragraph are included on all	above copyright notice and this paragraph are included on all
	such copies and derivative works. However, this document	such copies and derivative works. However, this document
	itself may not be modified in any way, such as by removing	itself may not be modified in any way, such as by removing

End of changes. 12 change blocks.
	21 lines changed or deleted	22 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/