< draft-newman-mime-cdisp-metadata-01.txt		draft-newman-mime-cdisp-metadata-02.txt >
	Network Working Group C. Newman		Network Working Group C. Newman
	Internet Draft: Metadata Content-Disposition Type Innosoft		Internet Draft: Ancillary Content-Disposition Type Innosoft
	Document: draft-newman-mime-cdisp-metadata-01.txt July 1998		Document: draft-newman-mime-cdisp-metadata-02.txt March 1999
	Expires in six months
	Metadata Content-Disposition Type		Ancillary Content-Disposition Type
	Status of this memo		Status of this memo
	This document is an Internet-Draft. Internet-Drafts are working		This document is an Internet-Draft and is in full conformance with
	documents of the Internet Engineering Task Force (IETF), its areas,		all provisions of Section 10 of RFC 2026.
	and its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.		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		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
	documents at any time. It is inappropriate to use Internet-Drafts		documents at any time. It is inappropriate to use Internet-Drafts
	as reference material or to cite them other than as "work in		as reference material or to cite them other than as "work in
	progress."		progress."
	To view the entire list of current Internet-Drafts, please check		The list of current Internet-Drafts can be accessed at
	the "1id-abstracts.txt" listing contained in the Internet-Drafts		http://www.ietf.org/ietf/1id-abstracts.txt.
	Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
	(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au		The list of Internet-Draft Shadow Directories can be accessed at
	(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US		http://www.ietf.org/shadow.html.
	West Coast).
	Abstract		Abstract
	The Content-Disposition [CDISP] header defines two disposition		The Content-Disposition [CDISP] header defines two disposition
	types: ``inline'' and ``attachment'' which can affect presentation		types: ``inline'' and ``attachment'' which can affect presentation
	of a MIME [MIME-IMB] body part. There have been a number of cases		of a MIME [MIME-IMB] body part. There have been a number of cases
	where one MIME body part contains metadata for another MIME body		where one MIME body part is ancillary or contains meta-data for
	part and is neither suitable for inline display by itself, nor is		another MIME body part and is neither suitable for inline display
	it useful if treated as an independent attachment and saved to a		by itself, nor is it useful if treated as an independent attachment
	file by itself. If the recipient UA is not familiar with the		and saved to a file by itself. If the recipient UA is not familiar
	specific media type, the user often is presented with a useless		with the specific media type, the user often is presented with a
	unrecognizable attachment. This memo proposes a third disposition		useless unrecognizable attachment. This memo proposes a third
	type, ``metadata'', to address this situation.		disposition type, ``ancillary'', to address this situation.
	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" [KEYWORDS].		use in RFCs to Indicate Requirement Levels" [KEYWORDS].
	2. The Metadata Disposition Type		2. The Ancillary Disposition Type
	A body part can be designated "metadata" if it contains metadata		A body part can be designated "ancillary" if it is ancillary to the
	for one or more other body parts in the containing multipart and is		primary content of the containing multipart and is unlikely to be
	unlikely to be useful if saved to a file by itself or viewed		useful if saved to a file by itself or viewed independently. If an
	independently. If an interpreting user agent sees an unknown media		interpreting user agent sees an unknown media type with an
	type with a "metadata" disposition type, it SHOULD indicate in some		"ancillary" disposition type, it SHOULD indicate in some way that
	way that the body part is unlikely to be useful to the user.		the body part is unlikely to be useful to the user.
	For example, in a multipart/appledouble [MACMIME], the		For example, in a multipart/appledouble [MACMIME], the
	application/applefile body part SHOULD have a "metadata"		application/applefile body part SHOULD have an "ancillary"
	disposition type as it is usually useless by itself.		disposition type as it is usually useless by itself.
	In a multipart/security [MIME-SEC], the signature body part is		In a multipart/security [MIME-SEC], the signature body part can be
	usually useless without the text it signs and thus would usually		useless without the text it signs and thus might have a disposition
	have a disposition type of "metadata."		type of "ancillary."
			If a client automatically attaches ancillary information to every
			message sent (e.g., a vcard [VCARD] or vendor proprietary
			information intended for special processing by a recipient running
			the same software), that information is a good candidate for this
			label.
	2. Amended Formal Syntax		2. Amended Formal Syntax
	This amends the formal syntax [ABNF] for "disposition-type"		This amends the formal syntax [ABNF] for "disposition-type"
	[CDISP]:		[CDISP]:
	disposition-type =/ "metadata"		disposition-type =/ "ancillary"
	3. Security Considerations		3. Security Considerations
	This does not add additional security considerations beyond those		This does not add additional security considerations beyond those
	which already apply to the Content-Disposition header field		which already apply to the Content-Disposition header field
	[CDISP].		[CDISP].
	4. References		4. References
	[ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:		[ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
	ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd,		ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd,
	November 1997.		November 1997.
	[CDISP] Troost, Dorner, Moore, "Communicating Presentation		[CDISP] Troost, Dorner, Moore, "Communicating Presentation
	Information in Internet Messages: The Content-Disposition Header		Information in Internet Messages: The Content-Disposition Header
	Field", RFC 2183, New Century Systems, Qualcomm Incorporated,		Field", RFC 2183, New Century Systems, Qualcomm Incorporated,
	University of Tennessee, August 1997.		University of Tennessee, August 1997. Draft Standard revision is a
			WORK-IN-PROGRESS.
	[MACMIME] Faltstrom P., Crocker, D., and E. Fair, "MIME		[MACMIME] Faltstrom P., Crocker, D., and E. Fair, "MIME
	Encapsulation of Macintosh Files - MacMIME", RFC 1740, KTH,		Encapsulation of Macintosh Files - MacMIME", RFC 1740, KTH,
	Brandenburg Consulting, Apple Computer Inc., December 1994.		Brandenburg Consulting, Apple Computer Inc., December 1994.
	[MIME-IMB] Freed, Borenstein, "Mulitpurpose Internet Mail		[MIME-IMB] Freed, Borenstein, "Mulitpurpose Internet Mail
	Extensions (MIME) Part One: Format of Internet Message Bodies", RFC		Extensions (MIME) Part One: Format of Internet Message Bodies", RFC
	2045, Innosoft, First Virtual, November 1996.		2045, Innosoft, First Virtual, November 1996.
	[MIME-SEC] Galvin, Murphy, Crocker, Freed, "Security Multiparts for		[MIME-SEC] Galvin, Murphy, Crocker, Freed, "Security Multiparts for
	MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, Trusted		MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, Trusted
	Information Systems, CyberCash, Innosoft International, October		Information Systems, CyberCash, Innosoft International, October
	1995.		1995.
			[VCARD] Dawson, F., Howes, T., "vCard MIME Directory Profile", RFC
			2426, Lotus Development Corporation, September 1998.
	5. Author's Address		5. Author's Address
	Chris Newman		Chris Newman
	Innosoft International, Inc.		Innosoft International, Inc.
	1050 Lakes Drive		1050 Lakes Drive
	West Covina, CA 91790 USA		West Covina, CA 91790 USA
	Email: chris.newman@innosoft.com		Email: chris.newman@innosoft.com
End of changes. 12 change blocks.
	34 lines changed or deleted		45 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/