< draft-ietf-vpim-cc-07.txt		draft-ietf-vpim-cc-08.txt >
			A new Request for Comments is now available in online RFC libraries.
	Network Working Group E. Burger		RFC 3459
	Internet Draft SnowShore Networks
	Document: draft-ietf-vpim-cc-07.txt
	Category: Standards Track
	Updates: RFC 3204
	Expires December 2002 June 1, 2002
	Critical Content MIME Parameter
	Status of this Memo
	This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC 2026 [1].
	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, and other documents may
	obsolete this one at any time. It is inappropriate to use Internet-
	Drafts as reference material or to cite them other than as "work in
	progress."
	One can access the list of current Internet-Drafts at
	http://www.ietf.org/ietf/1id-abstracts.txt
	One can access the list of Internet-Draft Shadow Directories at
	http://www.ietf.org/shadow.html.
	This document is a work product of the IETF Voice Profile for
	Internet Mail (VPIM) Work Group.
	1. Abstract
	This document describes the use of a mechanism for identifying body
	parts that a sender deems critical in a multi-part Internet mail
	message. The mechanism described is a parameter to Content-
	Disposition, as described by RFC 3204.
	By knowing what parts of a message the sender deems critical, a
	content gateway can intelligently handle multi-part messages when
	providing gateway services to systems of lesser capability.
	Critical content can help a content gateway to decide what parts to
	forward. It can indicate how hard a gateway should try to deliver a
	body part. It can help the gateway to pick body parts that are safe
	to silently delete when a system of lesser capability receives a
	message. In addition, critical content can help the gateway chose
	the notification strategy for the receiving system. Likewise, if
	the sender expects the destination to do some processing on a body
	part, critical content allows the sender to mark body parts that the
	receiver must process.
	Table of Contents
	1. Abstract...........................................................1
	2. Conventions used in this document..................................2
	3. Introduction.......................................................3
	4. Handling Parameter.................................................3
	4.1. REQUIRED.........................................................4
	4.2. OPTIONAL.........................................................4
	4.3. Default Values...................................................4
	4.4. Other Values.....................................................5
	5. Collected Syntax...................................................5
	6. Notification.......................................................5
	6.1. DSN vs. MDN Generation...........................................6
	6.2. Summary..........................................................6
	7. Status Code........................................................7
	8. Requirements for Critical Content..................................8
	8.1. Needs............................................................8
	8.2. Current Approaches...............................................9
	9. The Content Gateway...............................................10
	9.1. Integrated Content Gateway......................................10
	9.2. Disaggregated Delivery Network..................................11
	10. Backward Compatibility Considerations............................11
	11. MIME Interactions................................................11
	11.1. multipart/alternative..........................................11
	11.2. multipart/related..............................................12
	11.3. message/rfc822.................................................12
	12. Implementation Examples..........................................12
	12.1. Content Gateways...............................................12
	12.2. Disaggregated Content Gateway..................................13
	13. Security Considerations..........................................14
	14. IANA Considerations..............................................14
	15. References.......................................................15
	16. Acknowledgments..................................................16
	17. Author's Address.................................................16
	2. Conventions used in this document
	This document refers generically to the sender of a message in the
	masculine (he/him/his) and the recipient of the message in the
	feminine (she/her/hers). This convention is purely for convenience
	and makes no assumption about the gender of a message sender or
	recipient.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
	this document are to be interpreted as described in RFC 2119 [2].
	NOTE: Notes, such as this one, provide additional nonessential
	information that the reader may skip without missing anything
	essential. The primary purpose of these non-essential notes is to
	convey information about the rationale of this document, or to place
	this document in the proper historical or evolutionary context.
	Readers whose sole purpose is to construct a conformant
	implementation may skip such information. However, it may be of use
	to those who wish to understand why we made certain design choices.
	3. Introduction
	The specification of Critical Content is small and compact. For the
	benefit of developers, the specification comes first, the rationale
	after.
	One concept that an implementer must understand is the content
	gateway. Section 9 describes the content gateway. In brief, a
	content gateway has knowledge of the receiving system's
	capabilities. The content gateway passes messages the receiving
	system can process, render or store. The content gateway can modify
	a message, for example by deleting unrenderable or storable body
	parts, for delivery to the receiving system. Finally, the content
	gateway can reject a message that the receiving system cannot
	handle.
	In this document, the "sending agent" is the originator of the
	message. It could be a mail user agent (MUA) for an Internet
	message, or a SIP User Agent Client (UAC) for a SIP [3] message.
	NOTE: This document updates RFC 3204 to separate the Handling
	parameter from the ISUP/QSIG transport mechanism. The protocol
	described here is identical in functionality to RFC 3204 with
	respect to SIP. Future versions of RFC 3204 should reference this
	document for the Handling parameter, as it is orthogonal to the
	tunneling of signaling.
	4. Handling Parameter
	The Handling parameter is a Content-Disposition [5] parameter
	inserted by the sending agent to indicate to the content gateway
	whether to consider the marked body part critical.
	A REQUIRED body part is one the sender requires the receiving system
	to deliver for him to consider the message delivered.
	An OPTIONAL body part is one the sender doesn't care whether the
	receiving system delivers it or not. A content gateway can silently
	delete such body parts if the receiving system cannot deliver the
	part.
	The terms "entity" and "body part" have the meanings defined in [5].
	4.1. REQUIRED
	"Handling=REQUIRED" signifies that this body part is critical to the
	sender.
	If the content gateway cannot pass a body part marked REQUIRED, then
	the entire message has failed. In this case, the content gateway
	MUST take the appropriate failure action.
	NOTE: We say "appropriate action", because the sender may have
	suppressed all notifications. In this case, the appropriate action
	is to silently discard the message. In addition, as a general MIME
	parameter, the MIME body part may not be in an Internet Mail
	message. Moreover, in the SIP case, the appropriate notification is
	a status return code, not a delivery notification.
	4.2. OPTIONAL
	"Handling=OPTIONAL" signifies that the sender does not care about
	notification reports for this body part.
	If the content gateway cannot pass a body part marked OPTIONAL, the
	receiving system may silently delete the body part. The receiving
	system MUST NOT return a delivery failure, unless parts marked
	REQUIRED have also failed.
	4.3. Default Values
	The default value for Handling for a given body part is REQUIRED.
	This enables the existing notification mechanisms to work for
	sending agents that do not know about the content notification
	entity. All body parts are critical, because they have the default
	marking of REQUIRED.
	NOTE: In the case of Internet mail, critical content processing is a
	function of the content gateway and not the mail transfer agent
	(MTA) or user agent (UA). Often, the entity performing content
	gateway processing is the receiving UA. However, in this case the
	UA is acting as a content gateway. Thus the default action for any
	Content-Disposition [5]-compliant user agent to ignore unrecognized
	disposition parameters ensures that this mechanism is compatible
	with the Internet architecture.
	NOTE: This parameter is fully backwards compatible and works as
	expected for Internet mail and SIP.
	NOTE: Some VPIMv2 implementations can receive arbitrary e-mail from
	the Internet. However, these systems are really acting in the
	capacity of an Internet Voice Mail system. In this case, one would
	expect the implementation to provide Internet Voice Mail semantics
	to Internet Voice Mail messages.
	4.4. Other Values
	The content gateway MUST treat unrecognized values as REQUIRED.
	This is to provide backward compatibility with future uses of the
	Content-Criticality entity.
	NOTE: A possible new value is IMPORTANT. An IMPORTANT body part is
	something the sender wants the receiver to get, but would not want
	the message rejected outright if the IMPORTANT body part fails, but
	they do want notification of the failure. However, as no
	implementations do IMPORTANT, it is not important to this version of
	this document.
	5. Collected Syntax
	The format of the collected syntax is in accordance with the ABNF of
	[6]. Note that per RFC 2183 [5], the HANDLING Content-Disposition
	parameter is not case sensitive. In addition, the notification-type
	is not case sensitive.
	"handling" "=" notification-type CRLF
	notification-type = "REQUIRED" / "OPTIONAL" /
	other-handling / generic-param
	other-handling = token
	6. Notification
	One obvious application of critical content is generating a
	(non-)delivery notification in the Internet mail environment. If
	the value of the field is OPTIONAL, the content gateway MUST NOT
	generate a notification. If the value of the field is REQUIRED, the
	content gateway MAY generate a notification, based on the normal
	notification request mechanisms. Normal notification request
	mechanisms include the SMTP RCPT NOTIFY command [7] and the
	Disposition-Notification-To header [8].
	In SIP, all requests have responses. These responses provide
	notification in the status code of the response. For the RFC 3204
	case, a content gateway generates a 415 (Unsupported Media Type)
	response if the field is REQURED.
	If the sending system requests a notification, and a REQUIRED part
	fails, the content gateway will generate a notification for the
	whole message. Conversely, if the gateway cannot pass on a body
	part marked OPTIONAL, the gateway will not generate a notification.
	NOTE: This implies that the content gateway must examine the entire
	message to determine whether it needs to generate a notification.
	However, the content gateway need not examine the message if it
	knows it can store and forward all media types. Said differently,
	Internet e-mail MTAs or gateways can, by default, handle any
	arbitrary MIME-encapsulated type. Some voice mail systems, on the
	other hand, cannot store binary attachments at all, such as
	application/ms-word. The voice mail content gateway, in this
	example, would be scanning for non-renderable body parts in any
	event.
	6.1. DSN vs. MDN Generation
	The content gateway generates a delivery status notification (DSN)
	[8] if it operates as a gateway. The content gateway generates a
	Message Disposition Notification (MDN) [9] if it operates as a mail
	user agent. Section 7 describes the operating modes of a content
	gateway. In short, if there is a MTA that "delivers" the message to
	the content gateway for processing, the MTA takes responsibility for
	DSN processing. In this case, the only option available to the
	content gateway is to generate MDNs. If the content gateway
	operates as a MTA, then it generates DSNs. DSN generation is the
	preferred option.
	If the content gateway is part of a SIP endpoint, then it generates
	the appropriate success or error response code.
	6.2. Summary
	The following table summarizes the actions expected of a conforming
	content gateway.
	NOTE: This section is normative: it suggests what to put into the
	DSN or MDN.
	NOTE: In the case of SIP, this section is informative. See RFC 3204
	for the normative set of actions on failure.
	+--------------------------------------+
	| Sending UA Has Marked Body Part |
	|---------------------+----------------|
	| REQUIRED | OPTIONAL |
	+--------------------+---------------------+----------------+
	| Body Part is | | |
	| Deliverable | Appropriate Action | ignore |
	+--------------------+---------------------+----------------+
	| Body Part is | | |
	| Undeliverable | Fail Entire Message | ignore |
	+--------------------+--------------------------------------+
	The "Appropriate Action" is the action the content gateway would
	take given the context of execution. For example, if a sender
	requests return receipt and the receiver reads a HANDLING body part,
	the receiving UA must generate the appropriate MDN (following the
	rules for MDN). Likewise, if the content gateway cannot deliver the
	body part and the body part is critical, the content gateway
	generates the appropriate DSN or MDN.
	"Optional" means the content gateway ignores the disposition of the
	body part. The content gateway treats the message as if the body
	part was not present in the message.
	7. Status Code
	The critical content indication, in itself, does not guarantee any
	notification. Notification follows the rules described in [3], [7],
	and [8].
	NOTE: The content of actual DSNs or MDNs are beyond the scope of
	this document. This document only specifies how to mark a critical
	body part. On the other hand, we do envision sensible DSN and MDN
	contents. For example, DSNs should include the appropriate failure
	code as enumerated in [10]. Likewise, MDNs should include the
	failure code in the MDN "Failure:" field.
	If the receiving system is to generate a notification based on its
	inability to render or store the media type, the notification should
	use the status code 5.6.1, "Media not supported", from [9].
	For the SIP case, all requests have notification provided by the
	status response message. Per RFC 3204, a content gateway generates
	a 415 (Unsupported Media Type) response.
	8. Requirements for Critical Content
	8.1. Needs
	The need for a critical content identification mechanism comes about
	because of the internetworking of Internet mail systems with
	messaging systems that do not fulfill all of the semantics of
	Internet mail. Such legacy systems have a limited ability to render
	or store all parts of a given message. This document will use the
	case of an Internet mail system exchanging electronic messages with
	a legacy voice messaging system for illustrative purposes.
	Electronic mail has historically been text-centric. Extensions such
	as MIME [11] enable the user agents to send and receive multi-part,
	multimedia messages. Popular multimedia data types include binary
	word processing documents, binary business presentation graphics,
	voice, and video.
	Voice mail has historically been audio-centric. Many voice-
	messaging systems only render voice. Extensions such as fax enable
	the voice mail system to send and receive fax images as well as
	create multi-part voice and fax messages. A few voice mail systems
	can render text using text-to-speech or text-to-fax technology.
	Although theoretically possible, none can today render video.
	An important aspect of the interchange between voice messaging
	services and desktop e-mail client applications is that the
	rendering capability of the voice-messaging platform is often much
	less than the rendering capability of a desktop e-mail client. In
	the e-mail case, the sender has the expectation that the recipient
	receives all components of a multimedia message. This is so even if
	the recipient cannot render all body parts. In most cases, the
	recipient can either find the appropriate rendering tool or tell the
	sender that she cannot read the particular attachment.
	This is an important issue. By definition, a MIME-enabled user
	agent, conforming to [12], will present or make available all of the
	body parts to the recipient. However, a voice mail system may not
	be capable of storing non-voice objects. Moreover, the voice mail
	system may not be capable of notifying the recipient that there were
	undeliverable message parts.
	The inability of the receiving system to render a body part is
	usually a permanent failure. Retransmission of the message will not
	improve the likelihood of a future successful delivery. Contrast
	this with the case with normal data delivery. Traditional message
	failures, such as a garbled message or disabled link will benefit
	from retransmission.
	This situation is fundamentally different from normal Internet mail.
	In the Internet mail case, either the system delivered the message,
	or it didn't. There is no concept of a system partially delivering
	a message.
	In addition, there are many situations where the sender would not
	mind if the system did not deliver non-critical parts of a message.
	For example, the sender's user agent may add body parts to a message
	unbeknownst to the sender. If the receiving system rejected the
	message because it could not render a hidden body part, the sender
	would be understandably confused and upset.
	Thus, there is a need for a method of indicating to a Mail Transfer
	Agent (MTA) or User Agent (UA) that the sender considers parts of a
	message to be critical. From the sender's perspective, he would not
	consider the message delivered if the system did not deliver the
	critical parts.
	8.2. Current Approaches
	One method of indicating critical content of a message is to define
	a profile. The profile defines rules for silently deleting mail
	body parts based on knowledge of the UA capabilities. Citing the
	example above, a voice profile can easily declare that MTAs or UAs
	can silently delete TNEF data and yet consider the message
	successfully delivered. This is, in fact, the approach taken by
	VPIMv2 [13].
	Since one aspect of the issue is deciding when to notify the sender
	that the system cannot deliver part of a message, one could use a
	partial non-delivery notification mechanism to indicate a problem
	with delivering a given body part. However, this requires the user
	request a delivery notification. In addition, the sender may not be
	aware of parts added by the sending user agent. In this case, a
	failure notice would mystify the sender.
	A straightforward alternative implementation method for marking a
	body part critical is to use a Critical-Content MIME entity. This
	has the benefit that criticality is meta information for the body
	part. However, IMAP servers in particular would need to either put
	Critical-Content into the BODYSTRUCTURE method or create a new
	method to retrieve arbitrary MIME entities. Given the experience of
	trying to get Content-Location accepted by IMAP vendors, we chose
	not to go that route.
	What we need is a way of letting the sender indicate what body-parts
	he considers to be critical. The mechanism must not burden the
	sender with failure notifications for non-critical body parts. The
	mechanism must conform to the general notification status request
	mechanism for positive or negative notification. When requested,
	the mechanism must indicate to the sender when a receiving system
	cannot deliver a critical body part.
	9. The Content Gateway
	In this section, we use the definition of [14] for the term
	"gateway."
	A content gateway is a gateway that connects a first network to a
	second network. The second network often has lesser capability than
	the first network. The canonical topology follows. "[MTA]", with
	square brackets, signifies an optional component.
	+---------+
	+---------+ +-----+ | | +-------+ +-----------+
	| Sending |=...=|[MTA]|===| Content |=...=| [MTA] |===| Receiving |
	| UA | +-----+ | Gateway | +-------+ | UA |
	+---------+ | | +-----------+
	+---------+
	First Network Second Network
	The content gateway can be the last hop before the receiving MTA.
	The content gateway can be between networks, and thus not the last
	hop before the receiving MTA. The content gateway can be the first
	MTA the sending UA contacts. Finally, the content gateway can be an
	integrated component of the receiving MTA.
	For the SIP case, consider each MTA as a SIP Proxy, the Sending UA
	as a SIP User Agent Client, and the Receiving UA as a SIP User Agent
	Server.
	9.1. Integrated Content Gateway
	In this situation, the receiving user agent is integrated with the
	content gateway. The integrated content gateway knows the
	capabilities of the user agent. The topology is as follows.
	+---------------------+
	+---------+ +-----+ | : |
	| Sending |=...=|[MTA]|===| Content : Receiving |
	| UA | +-----+ | Gateway : UA |
	+---------+ | : |
	+---------------------+
	First Network Second Network
	The processing of ISUP and QSIG objects, as described in [4], is an
	example of an integrated gateway.
	9.2. Disaggregated Delivery Network
	A degenerate case, although one that does occur, is where the
	content gateway sits behind the final MTA. This happens when one
	implements the content gateway as a post-processing step to a normal
	delivery. For example, one could configure a mail handling system
	to deliver the message to a queue or directory, where the content
	gateway process picks up the message. If there were any directives
	for DSN processing, the delivering MTA would execute them. For
	example, the message could have requested notification on successful
	delivery. The delivering MTA, having delivered the message to the
	queue, would consider the message delivered and thus notify the
	sender of such. However, the content gateway process could then
	discover that the receiving UA cannot render the message. In this
	case, the content gateway generates a NDN, as it is the only option
	available.
	Delivered
	| +---------+
	+---------+ +-----+ v | | +-----------+
	| Sending |=...=| MTA |--> File -->| Content |=...=| Receiving |
	| UA | +-----+ | Gateway | | UA |
	+---------+ | | +-----------+
	+---------+
	First Network Second Network
	10. Backward Compatibility Considerations
	DSN requires ESMTP. If MTAs in the path from the sending UA to the
	receiving UA do not support ESMTP, then that MTA will reject the DSN
	request. In addition, the message will default to notification on
	delay or failure. While not ideal, the sender will know that DSN is
	not available, and that critical content that fails will get
	notification.
	11. MIME Interactions
	11.1. multipart/alternative
	As is true for all Content-Disposition parameters, handling is only
	in effect for the selected alternative. If the selected alternative
	has the critical content indicator, then the entire alternative
	takes on the criticality indicated. That is, if the alternative
	selected has HANDLING=OPTIONAL, then the content gateway MUST NOT
	generate any delivery notifications.
	NOTE: This statement explicitly shows that HANDLING overrides the
	DSN and MDN request mechanisms.
	It is unlikely for a selected alternative to fail, as the content
	gateway presumably picks the alternative specifically because it can
	render it.
	If the selected alternative is a message/rfc822 that encloses a
	multipart MIME message or the selected alternative is itself a
	multipart MIME type, the individual top-level body parts follow the
	HANDLING mechanism described in this document.
	NOTE: This means that a forwarded message's criticality will not
	affect the forwarding agent's intentions.
	11.2. multipart/related
	Criticality fits in rather well with the multipart/related
	construction. For example, consider a multipart/related message
	consisting of a Macintosh data fork and a Macintosh resource fork.
	For a Microsoft Word document, the data fork is likely to be
	critical. The receiving system can safely ignore the resource fork.
	11.3. message/rfc822
	Criticality only affects the outermost level of the message or, in
	the case of multipart/alternative, the outermost level of the
	selected alternative. Specifically, the receiving system ignores
	criticality indicators in embedded body parts. This avoids the
	situation of a forwarded message triggering or suppressing undesired
	reporting. This simply implements the procedures described in [5].
	12. Implementation Examples
	This section is not a normative part of the definition of
	Criticality. However, we hope it helps implementers to understand
	the mechanics of the Handling mechanism.
	We will examine two cases. They are how a content gateway processes
	a message and how a disaggregated content gateway processes a
	message.
	12.1. Content Gateways
	Content gateways examine the contents of a message from a first
	network before the gateway forwards the message to a second network.
	For the purposes of this example, we assume the second network has
	less capability than the first network. In particular, we expect
	there will be certain message body types that the gateway cannot
	pass onto the second network.
	Consider a gateway between the Internet and a text-only short
	message service. A message comes through the gateway containing a
	text part and a tnef part. The sender marks the text part REQUIRED.
	The gateway, knowing the capability of the short message service,
	silently deletes the non-critical, tnef part, passing the critical
	content to the short message service network. Any subsequent
	notifications, such as failure notices or delivery notices, follow
	the normal rules for notification.
	Note the gateway, by silently deleting non-critical content, may
	affect proprietary message correlation schemes. One can envision
	the sending UA inserting a body part for tracking purposes. By
	deleting non-critical content, the content gateway will break such a
	scheme. If a sending UA understands how to mark critical content,
	it should use Internet standard mechanisms for tracking messages,
	such as Message-ID [15].
	What if no body parts have critical content indicators? In this
	case, the entire message is critical. Thus, when the gateway sees
	the tnef part, it will reject the entire message, generating a DSN
	with a status code 5.6.1, "Media not supported".
	Likewise, consider a three part message with a text annotation (part
	1) to a voice message (part 2) with a vCard [16] (part 3). The
	sender marks the first two parts REQUIRED. Now, let us assume the
	receiving MTA (gateway) is a voice mail only system, without even
	the capability to store text. In this case, the gateway, acting as
	the receiving MTA, will reject the message, generating a DSN with
	the status code 5.6.1, "Media not supported".
	12.2. Disaggregated Content Gateway
	For this example, we will examine the processing of a three-part
	message. The first part is a text annotation of the second part, an
	audio message. The third part is the sender's vCard. The sender
	marks the first and second parts REQUIRED. In addition, the sender
	marks the message for read receipt.
	For the purposes of example, the telephone user interface (TUI) does
	not perform text-to-speech conversion. A TUI is a mail user agent
	(UA) that uses DTMF touch-tone digits for input and audio for output
	(display).
	The TUI is unable to render the first part of the message, the text
	part. In addition, it is unable to render the third part of the
	message, the vCard part. Since the sender did not mark the third
	part of the message REQUIRED, the system ignores the failure of the
	TUI to render the third part of the message. However, since the
	sender did mark the first part REQUIRED, and the TUI is unable to
	render text, the message fails.
	What happens next is implementation dependent. If the TUI is part
	of a unified messaging system, a reasonable action is to hold the
	message for the user. The user can access the message at a later
	time from a terminal that can render all of the critical body parts.
	It would be reasonable for the TUI to notify the user about the
	undeliverable body part.
	If the TUI is part of a voice messaging system, or if the user does
	not subscribe to a text-to-speech service, a reasonable action is
	for the TUI to return a MDN with the disposition "failed" and the
	failure modifier "5.6.1 (Media not supported)".
	13. Security Considerations
	Receiving systems and users should not place any authentication
	value on the Handling parameter.
	Note that by design, and under the sending user's request, a content
	gateway will silently delete unimportant body parts. Critical
	content gives the sender the ability to determine the acceptable
	level integrity of the delivered message. That is, the message as
	the content gateway actually passes it on is, in fact,
	representative of the sender's intentions.
	14. IANA Considerations
	RFC 3204 already registered the Handling parameter. It is collected
	here only for reference and as a placeholder for use both for
	further expansion in the future and as the normative reference for
	other documents that need to reference the Handling parameter.
	Per section 9 of [5] here is the IANA registration for Handling.
	To: IANA@IANA.ORG
	Subject: Registration of new Content-Disposition parameter
	Content-Disposition parameter name:
	HANDLING
	Allowable values for this parameter:
	REQUIRED
	OPTIONAL
	Description:
	Marks the body part as required for delivery (REQUIRED) or can be
	silently discarded (OPTIONAL). See RFC <this document> and RFC 3204.
	Per RFC 2183, the Content-Disposition parameter name is not case
	sensitive. Per RFC <this document>, the values of the parameter are
	also not case sensitive.
	15. References
	1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
	9, RFC 2026, October 1996.
	2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.
	3 Handley, M., Schulzrinne, H., Schooler, E., and Rosenberg, J.,
	"SIP: Session Initiation Protocol", RFC 2543, March 1999.
	4 Zimmerer, E., et. al., "MIME media types for ISUP and QSIG
	Objects", RFC 3204, December 2001.
	5 Troost, R., Dorner, S., Moore, K. (ed), "Communicating
	Presentation Information in Internet Messages: The Content-
	Disposition Header Field", RFC 2183, August 1997.
	6 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
	Specifications: ABNF", RFC 2234, November 1997.
	7 Moore, K., "SMTP Service Extension for Delivery Status
	Notifications", RFC 1981, January 1996.
	8 Moore, K. and Vaudreuil, G., "An Extensible Message Format for
	Delivery Status Notifications", RFC 1894, January 1996.
	9 Fajman, R., "An Extensible Message Format for Message Disposition
	Notifications", RFC 2298, March 1998.
	10 Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893,
	January 1996.
	11 Freed, N. and Borenstein, N., "Multipurpose Internet Mail
	Extensions (MIME) Part One: Format of Internet Message Bodies",
	RFC 2045, November 1996.
	12 Freed, N. and Borenstein, N., "Multipurpose Internet Mail
	Extensions (MIME) Part Two: Media Types", RFC 2046, November
	1996.
	13 Vaudreuil, G. and Parsons, G., "Voice Profile for Internet Mail -
	version 2", RFC 2421, September 1998.
	14 Kille, S. "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
	between X.400 and RFC 822/MIME", RFC 2156, January 1998.
	15 Crocker, D., "Standard for the Format of ARPA Internet Text
	Messages", RFC 822, August 1982.
	16 Dawson, F. and Howes, T., "vCard MIME Directory Profile", RFC
	2426, September 1998.
	16. Acknowledgments
	Emily Candell of Comverse Network Systems was instrumental in
	helping work out the base issues in the û00 draft in Adelaide.
	Ned Freed pointed out that this mechanism was about criticality, not
	notification. That insight made the concept and descriptions
	infinitely more straightforward. If it's still confusing, it's my
	fault!
	Keith Moore for helped tighten-up the explanations, and he approved
	of the use of Content-Disposition.
	Dropping the IMPORTANT critical content type took away one of the
	reasons for partial non-delivery notification. That makes Jutta
	Degener very happy!
	Harald Alvestrand and Chris Newman suggested some implementation
	examples.
	Greg White asked THE key question that let us realize that critical		Title: Critical Content Multi-purpose Internet Mail
	content processing was a gateway function, and not a MTA or UA		Extensions (MIME) Parameter
	function.		Author(s): E. Burger
			Status: Standards Track
			Date: January 2003
			Mailbox: e.burger@ieee.org
			Pages: 24
			Characters: 54282
			Updates: 3204
	Jon Peterson cleared up how handling actually does work in the SIP		I-D Tag: draft-ietf-vpim-cc-08.txt
	environment.
	An enormous thank you to Michelle S. Cotton at IANA for helping me		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3459.txt
	craft the original IANA Considerations section in 2000, and for
	catching the functional overlap with RFC 3204 in January 2002.
	Any errors, omissions, or silliness are my fault.		This document describes the use of a mechanism for identifying body
			parts that a sender deems critical in a multi-part Internet mail
			message. The mechanism described is a parameter to
			Content-Disposition, as described by RFC 3204.
	17. Author's Address		By knowing what parts of a message the sender deems critical, a
			content gateway can intelligently handle multi-part messages when
			providing gateway services to systems of lesser
			capability. Critical content can help a content gateway to decide
			what parts to forward. It can indicate how hard a gateway should try
			to deliver a body part. It can help the gateway to pick body parts
			that are safe to silently delete when a system of lesser
			capability receives a message. In addition, critical content can
			help the gateway chose the notification strategy for the receiving
			system. Likewise, if the sender expects the destination to do
			some processing on a body part, critical content allows the sender
			to mark body parts that the receiver must process.
	Eric Burger		This document is a product of the Voice Profile for Internet Mail
	SnowShore Networks, Inc.		Working Group of the IETF.
	285 Billerica Rd.
	Chelmsford, MA 01824-4120
	USA
	Phone: +1 978 367 8400		This is now a Proposed Standard Protocol.
	Fax: +1 603 457 5944
	Email: e.burger@ieee.org
	Full Copyright Statement
	The IETF takes no position regarding the validity or scope of any		This document specifies an Internet standards track protocol for
	intellectual property or other rights that might be claimed to		the Internet community, and requests discussion and suggestions
	pertain to the implementation or use of the technology described in		for improvements. Please refer to the current edition of the
	this document or the extent to which any license under such rights		"Internet Official Protocol Standards" (STD 1) for the
	might or might not be available; neither does it represent that it		standardization state and status of this protocol. Distribution
	has made any effort to identify any such rights. Information on the		of this memo is unlimited.
	IETF's procedures with respect to rights in standards-track and
	standards-related documentation can be found in BCP-11. Copies of
	claims of rights made available for publication and any assurances
	of licenses to be made available, or the result of an attempt made
	to obtain a general license or permission for the use of such
	proprietary rights by implementers or users of this specification
	can be obtained from the IETF Secretariat.
	The IETF invites any interested party to bring to its attention any		This announcement is sent to the IETF list and the RFC-DIST list.
	copyrights, patents or patent applications, or other proprietary		Requests to be added to or deleted from the IETF distribution list
	rights that may cover technology that may be required to practice		should be sent to IETF-REQUEST@IETF.ORG. Requests to be
	this standard. Please address the information to the IETF Executive		added to or deleted from the RFC-DIST distribution list should
	Director.		be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	Copyright (C) 2000, 2001, 2002, The Internet Society. All Rights		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
	Reserved.		an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
			help: ways_to_get_rfcs. For example:
	This document and translations of it may be copied and furnished to		To: rfc-info@RFC-EDITOR.ORG
	others, and derivative works that comment on or otherwise explain it		Subject: getting rfcs
	or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph
	are included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than
	English.
	The limited permissions granted above are perpetual and will not be		help: ways_to_get_rfcs
	revoked by the Internet Society or its successors or assigns.
	This document and the information contained herein is provided on an		Requests for special distribution should be addressed to either the
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		specifically noted otherwise on the RFC itself, all RFCs are for
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		unlimited distribution.echo
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		Submissions for Requests for Comments should be sent to
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
			Authors, for further information.
End of changes. 15 change blocks.
	807 lines changed or deleted		49 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/