draft-ietf-appsawg-rrvs-header-field-04.txt		draft-ietf-appsawg-rrvs-header-field-05.txt
	Network Working Group W. Mills		Network Working Group W. Mills
	Internet-Draft Yahoo! Inc.		Internet-Draft Yahoo! Inc.
	Intended status: Standards Track M. Kucherawy		Intended status: Standards Track M. Kucherawy
	Expires: May 23, 2014 Facebook, Inc.		Expires: June 14, 2014 Facebook, Inc.
	November 19, 2013		December 11, 2013
	The Require-Recipient-Valid-Since Header Field and SMTP Service		The Require-Recipient-Valid-Since Header Field and SMTP Service
	Extension		Extension
	draft-ietf-appsawg-rrvs-header-field-04		draft-ietf-appsawg-rrvs-header-field-05
	Abstract		Abstract
	This document defines an extension for the Simple Mail Transfer		This document defines an extension for the Simple Mail Transfer
	Protocol called RRVS, and a header field called Require-Recipient-		Protocol called RRVS, and a header field called Require-Recipient-
	Valid-Since, to provide a method for senders to indicate to receivers		Valid-Since, to provide a method for senders to indicate to receivers
	the time when the sender last confirmed the ownership of the target		the time when the sender last confirmed the ownership of the target
	mailbox. This can be used to detect changes of mailbox ownership,		mailbox. This can be used to detect changes of mailbox ownership,
	and thus prevent mail from being delivered to the wrong party.		and thus prevent mail from being delivered to the wrong party.
	skipping to change at page 1, line 41		skipping to change at page 1, line 41
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on May 23, 2014.		This Internet-Draft will expire on June 14, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 28		skipping to change at page 3, line 28
	7. Relaying Without RRVS Support . . . . . . . . . . . . . . . . 8		7. Relaying Without RRVS Support . . . . . . . . . . . . . . . . 8
	7.1. Header Field Conversion . . . . . . . . . . . . . . . . . 9		7.1. Header Field Conversion . . . . . . . . . . . . . . . . . 9
	8. Header Field with Multiple Recipients . . . . . . . . . . . . 9		8. Header Field with Multiple Recipients . . . . . . . . . . . . 9
	9. Special Use Addresses . . . . . . . . . . . . . . . . . . . . 10		9. Special Use Addresses . . . . . . . . . . . . . . . . . . . . 10
	9.1. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 10		9.1. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 10
	9.2. Single-Recipient Alaises . . . . . . . . . . . . . . . . . 10		9.2. Single-Recipient Alaises . . . . . . . . . . . . . . . . . 10
	9.3. Multiple-Recipient Aliases . . . . . . . . . . . . . . . . 11		9.3. Multiple-Recipient Aliases . . . . . . . . . . . . . . . . 11
	9.4. Confidential Forwarding Addresses . . . . . . . . . . . . 11		9.4. Confidential Forwarding Addresses . . . . . . . . . . . . 11
	9.5. Suggested Mailing List Enhancements . . . . . . . . . . . 11		9.5. Suggested Mailing List Enhancements . . . . . . . . . . . 11
	10. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 12		10. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	11. Continuous Ownership . . . . . . . . . . . . . . . . . . . . . 12		11. Continuous Ownership . . . . . . . . . . . . . . . . . . . . . 13
	12. Authentication-Results Definitions . . . . . . . . . . . . . . 13		12. Authentication-Results Definitions . . . . . . . . . . . . . . 13
	13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14		13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	13.1. SMTP Extension Example . . . . . . . . . . . . . . . . . . 14		13.1. SMTP Extension Example . . . . . . . . . . . . . . . . . . 14
	13.2. Header Field Example . . . . . . . . . . . . . . . . . . . 14		13.2. Header Field Example . . . . . . . . . . . . . . . . . . . 15
	14. Security Considerations . . . . . . . . . . . . . . . . . . . 15		14. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	14.1. Abuse Countermeasures . . . . . . . . . . . . . . . . . . 15		14.1. Abuse Countermeasures . . . . . . . . . . . . . . . . . . 15
	14.2. Suggested Use Restrictions . . . . . . . . . . . . . . . . 15		14.2. Suggested Use Restrictions . . . . . . . . . . . . . . . . 16
	15. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 15		15. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 16
	15.1. Probing Attacks . . . . . . . . . . . . . . . . . . . . . 15		15.1. Probing Attacks . . . . . . . . . . . . . . . . . . . . . 16
	15.2. Envelope Recipients . . . . . . . . . . . . . . . . . . . 16		15.2. Envelope Recipients . . . . . . . . . . . . . . . . . . . 17
	15.3. Risks with Use of Header Field . . . . . . . . . . . . . . 16		15.3. Risks with Use of Header Field . . . . . . . . . . . . . . 17
	16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	16.1. SMTP Extension Registration . . . . . . . . . . . . . . . 17		16.1. SMTP Extension Registration . . . . . . . . . . . . . . . 17
	16.2. Header Field Registration . . . . . . . . . . . . . . . . 17		16.2. Header Field Registration . . . . . . . . . . . . . . . . 17
	16.3. Enhanced Status Code Registration . . . . . . . . . . . . 17		16.3. Enhanced Status Code Registration . . . . . . . . . . . . 18
	16.4. Authentication Results Registration . . . . . . . . . . . 18		16.4. Authentication Results Registration . . . . . . . . . . . 18
	17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19		17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	17.1. Normative References . . . . . . . . . . . . . . . . . . . 19		17.1. Normative References . . . . . . . . . . . . . . . . . . . 19
	17.2. Informative References . . . . . . . . . . . . . . . . . . 19		17.2. Informative References . . . . . . . . . . . . . . . . . . 20
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 19		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	Email addresses sometimes get reassigned to a different person. For		Email addresses sometimes get reassigned to a different person. For
	example, employment changes at a company can cause an address used		example, employment changes at a company can cause an address used
	for an ex-employee to be assigned to a new employee, or a mail		for an ex-employee to be assigned to a new employee, or a mail
	service provider (MSP) might expire an account and then let someone		service provider (MSP) might expire an account and then let someone
	else register for the local-part that was previously used. Those who		else register for the local-part that was previously used. Those who
	sent mail to the previous owner of an address might not know that it		sent mail to the previous owner of an address might not know that it
	has been reassigned. This can lead to the sending of email to the		has been reassigned. This can lead to the sending of email to the
	skipping to change at page 4, line 49		skipping to change at page 4, line 49
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [KEYWORDS].		document are to be interpreted as described in [KEYWORDS].
	3. Description		3. Description
	To address the problem described above, a mail sending client needs		To address the problem described above, a mail sending client needs
	to indicate to the server to which it is connecting that there is an		to indicate to the server to which it is connecting that there is an
	expectation that the destination of the message has been under		expectation that the destination of the message has been under
	continuous ownership since some date-time, presumably the most recent		continuous ownership (see Section 11) since some date-time,
	time the message author had confirmed its understanding of who owned		presumably the most recent time the message author had confirmed its
	that mailbox. Two mechanisms are defined here: an extension to the		understanding of who owned that mailbox. Two mechanisms are defined
	Simple Mail Transfer Protocol [SMTP], for use between a client and		here: an extension to the Simple Mail Transfer Protocol [SMTP], for
	server that both implement the extension, and a header field that can		use between a client and server that both implement the extension,
	be used when passing a message to a server that appears not to		and a header field that can be used when passing a message to a
	implement this extension.		server that appears not to implement this extension.
	The SMTP extenion is called "RRVS" (Require Recipient Valid Since),		The SMTP extenion is called "RRVS" (Require Recipient Valid Since),
	and adds a parameter to the SMTP "RCPT" command that indicates the		and adds a parameter to the SMTP "RCPT" command that indicates the
	most recent date and time when the message author believed the		most recent date and time when the message author believed the
	destination mailbox to be under the continuous ownership (see		destination mailbox to be under the continuous ownership of a
	Section 11) of a specific party. Similarly, the Require-Recipient-		specific party. Similarly, the Require-Recipient-Valid-Since header
	Valid-Since header field includes an intended recipient coupled with		field includes an intended recipient coupled with a timestamp
	a timestamp indicating the same thing. Presumably there has been		indicating the same thing.
	some confirmation process applied to establish this ownership;
	however, the method of making such determinations is a local matter
	and outside the scope of this document.
	3.1. The 'RRVS' SMTP Extension		3.1. The 'RRVS' SMTP Extension
	Extensions to SMTP are described in Section 2.2 of [SMTP].		Extensions to SMTP are described in Section 2.2 of [SMTP].
	The name of the extension is "RRVS", an abbreviation of "Require		The name of the extension is "RRVS", an abbreviation of "Require
	Recipient Valid Since". Servers implementing the SMTP extension		Recipient Valid Since". Servers implementing the SMTP extension
	advertise an additional EHLO keyword of "RRVS", which has no		advertise an additional EHLO keyword of "RRVS", which has no
	associated parameters, introduces no new SMTP verbs, and does not		associated parameters, introduces no new SMTP verbs, and does not
	alter the MAIL verb.		alter the MAIL verb.
	skipping to change at page 5, line 46		skipping to change at page 5, line 43
	The meaning of this extension, when used, is described in		The meaning of this extension, when used, is described in
	Section 5.1.		Section 5.1.
	3.2. The 'Require-Recipient-Valid-Since' Header Field		3.2. The 'Require-Recipient-Valid-Since' Header Field
	The general constraints on syntax and placement of header fields in a		The general constraints on syntax and placement of header fields in a
	message are defined in Internet Message Format [MAIL].		message are defined in Internet Message Format [MAIL].
	Using Augmented Backus-Naur Form [ABNF], the syntax for the field is:		Using Augmented Backus-Naur Form [ABNF], the syntax for the field is:
	rrvs = "Require-Recipient-Valid-Since:" addr-spec; date-time CRLF		rrvs = "Require-Recipient-Valid-Since:" addr-spec ";" date-time
			CRLF
	"CFWS" is defined in Section 3.2.2, "date-time" is defined in Section		"date-time" is defined in Section 3.3, and "addr-spec" is defined in
	3.3, and "addr-spec" is defined in Section 3.4.1, of [MAIL].		Section 3.4.1, of [MAIL].
	4. Use By Generators		4. Use By Generators
	When a message is generated whose content is sufficiently sensitive		When a message is generated whose content is sufficiently sensitive
	that an author or author's Administrative Management Domain (ADMD;		that an author or author's Administrative Management Domain (ADMD;
	see [EMAIL-ARCH]) wishes to protect against misdelivery using this		see [EMAIL-ARCH]) wishes to protect against misdelivery using this
	protocol, it determines for each recipient mailbox on the message a		protocol, it determines for each recipient mailbox on the message a
	timestamp at which it last confirmed ownership of that mailbox. It		timestamp at which it last confirmed ownership of that mailbox. It
	then applies either the SMTP extension or the header field defined		then applies either the SMTP extension or the header field defined
	above when sending the message to its destination.		above when sending the message to its destination.
	skipping to change at page 7, line 6		skipping to change at page 7, line 6
	the current owner of the destination mailbox has held it		the current owner of the destination mailbox has held it
	continuously, far enough back to inclue the given date-time, and		continuously, far enough back to inclue the given date-time, and
	delivers it unless that check returns in the negative. Expressed as		delivers it unless that check returns in the negative. Expressed as
	a sequence of steps:		a sequence of steps:
	1. Ignore the parameter if the named mailbox is a role account as		1. Ignore the parameter if the named mailbox is a role account as
	listed in Mailbox Names For Common Services, Roles And Functions		listed in Mailbox Names For Common Services, Roles And Functions
	[ROLES]. (See Section 6.)		[ROLES]. (See Section 6.)
	2. Determine if the named address is serviced for local delivery.		2. Determine if the named address is serviced for local delivery.
	If so, and if that address, has not been under continuous		If so, and if that address has not been under continuous
	ownership since the specified timestamp, return a 550 error to		ownership since the specified timestamp, return a 550 error to
	the RCPT command. (See also Section 16.3.)		the RCPT command. (See also Section 16.3.)
	3. RECOMMENDED: If any Require-Recipient-Valid-Since header fields		3. RECOMMENDED: If any Require-Recipient-Valid-Since header fields
	are present and refer to the named address, remove them prior to		are present and refer to the named address, remove them prior to
	delivery or relaying. (See Section 5.2 for discussion.)		delivery or relaying. (See Section 5.2 for discussion.)
			Where a message arrives using the SMTP extension that also contains
			the Require-Recipient-Valid-Since header field in its header, the
			header field SHOULD be removed. (See Section 7.1 for further
			discussion about removal of the header field.)
	5.1.1. Relays		5.1.1. Relays
	An MTA that does not make mailbox ownership checks, such as an MTA		An MTA that does not make mailbox ownership checks, such as an MTA
	positioned to do SMTP ingress at an organizational boundary, SHOULD		positioned to do SMTP ingress at an organizational boundary, SHOULD
	relay the RRVS extension parameter to the next MTA so that it can be		relay the RRVS extension parameter to the next MTA so that it can be
	processed there.		processed there.
	See Section 9.2 for additional discussion.		See Section 9.2 for additional discussion.
	5.2. Header Field Used		5.2. Header Field Used
	skipping to change at page 9, line 30		skipping to change at page 9, line 35
	corresponding message on to another server ("C") (thereby becoming a		corresponding message on to another server ("C") (thereby becoming a
	client), but "C" does not advertise the SMTP extension and "B" elects		client), but "C" does not advertise the SMTP extension and "B" elects
	not to reject the message, "B" SHOULD add Require-Recipient-Valid-		not to reject the message, "B" SHOULD add Require-Recipient-Valid-
	Since header fields matching each mailbox to which relaying is being		Since header fields matching each mailbox to which relaying is being
	done, and the corresponding valid-since timestamp for each.		done, and the corresponding valid-since timestamp for each.
	Similarly, if "B" receives a message bearing one or more Require-		Similarly, if "B" receives a message bearing one or more Require-
	Recipient-Valid-Since header fields from "A" for which it must now		Recipient-Valid-Since header fields from "A" for which it must now
	relay the message, and "C" advertises support for the SMTP extension,		relay the message, and "C" advertises support for the SMTP extension,
	"B" SHOULD delete the header field(s) and instead relay this		"B" SHOULD delete the header field(s) and instead relay this
	information by making use of the SMTP extension.		information by making use of the SMTP extension. Note that such
			modification of the header might affect later validation of the
			header upon delivery; for example, a hash of the header would produce
			a different result. This might be a valid cause for some operators
			to skip this delete operation.
	8. Header Field with Multiple Recipients		8. Header Field with Multiple Recipients
	Numerous issues arise when using the header field form of this		Numerous issues arise when using the header field form of this
	extension, particularly when multiple recipients are specified for a		extension, particularly when multiple recipients are specified for a
	single message resulting in one multiple fields each with a distinct		single message resulting in one multiple fields each with a distinct
	address and timestamp.		address and timestamp.
	Because of the nature of SMTP, a message bearing a multiplicity of		Because of the nature of SMTP, a message bearing a multiplicity of
	Require-Recipient-Valid-Since header fields could result in a single		Require-Recipient-Valid-Since header fields could result in a single
	skipping to change at page 10, line 49		skipping to change at page 11, line 10
	place of a mailbox) that results in relaying of the message to a		place of a mailbox) that results in relaying of the message to a
	single other destination, the usual RRVS check is performed. The		single other destination, the usual RRVS check is performed. The
	continuous ownership test here might succeed if a conventional user		continuous ownership test here might succeed if a conventional user
	inbox was replaced with an alias on behalf of that same user, and		inbox was replaced with an alias on behalf of that same user, and
	this information is recorded someplace. If the message is thus		this information is recorded someplace. If the message is thus
	accepted, the relaying MTA can choose to do one of the following:		accepted, the relaying MTA can choose to do one of the following:
	1. Do not include an RRVS parameter or header field when relaying to		1. Do not include an RRVS parameter or header field when relaying to
	the new address. (RECOMMENDED)		the new address. (RECOMMENDED)
	2. If, however, the relaying system knows the time when the alias		2. If the relaying system records the time when the alias was
	was established, it MAY add an RRVS parameter for the new target		established, independent of confirming the validity of the new
	address that includes that time.		destination address, it MAY add an RRVS parameter for the new
			target address that includes that time.
	3. If a confirmation of the new destination was done, it MAY add an		3. If an explicit confirmation of the new destination was done, it
	RRVS parameter for the new target address that includes that		MAY add an RRVS parameter for the new target address that
	time.		includes that time.
	There is risk and additional administrative burden associated with		There is risk and additional administrative burden associated with
	all but the first option in that list which are believed to make them		all but the first option in that list which are believed to make them
	not worth pursuing.		not worth pursuing.
	9.3. Multiple-Recipient Aliases		9.3. Multiple-Recipient Aliases
	Upon delivery of an RRVS-protected message to an alias (acting in		Upon delivery of an RRVS-protected message to an alias (acting in
	place of a mailbox) that results in relaying of the message to		place of a mailbox) that results in relaying of the message to
	multiple other destinations, the usual RRVS check is performed as in		multiple other destinations, the usual RRVS check is performed as in
	skipping to change at page 12, line 46		skipping to change at page 13, line 7
	the header field does not refer to a current envelope recipient,		the header field does not refer to a current envelope recipient,
	and in either case delivers the message.		and in either case delivers the message.
	SMTP has never required any correspondence between addresses in the		SMTP has never required any correspondence between addresses in the
	RFC5321.MailFrom and RFC5321.RcptTo parameters and header fields of a		RFC5321.MailFrom and RFC5321.RcptTo parameters and header fields of a
	message, which is why the header field defined here contains the		message, which is why the header field defined here contains the
	recipient address to which the timestamp applies.		recipient address to which the timestamp applies.
	11. Continuous Ownership		11. Continuous Ownership
			For the purposes of this specification, an address is defined as
			having been under continuous ownership since a given date-time if a
			message sent to the address at any point since the given date would
			not go to anyone except the owner at that given date-time. That is,
			while an address may have been suspended or otherwise disabled for
			some period, any mail actually delivered would have been delivered
			exclusively to the same owner. It is is presumed that some sort of
			relationship exists between the message sender and the intended
			recipient. Presumably there has been some confirmation process
			applied to establish this ownership of the receiver's mailbox;
			however, the method of making such determinations is a local matter
			and outside the scope of this document.
			Evaluating the notion of continuous ownership is accomplished by
			doing any query that establishes whether the above condition holds
			for a given mailbox.
	Determining continuous ownership of a mailbox is a local matter at		Determining continuous ownership of a mailbox is a local matter at
	the receiving site. In particular, the only possible answers to the		the receiving site. The only possible answers to the continuous-
	continuous-ownership-since question are "yes", "no", and "unknown";		ownership-since question are "yes", "no", and "unknown"; the action
	the action to be taken in the "unknown" case is a matter of local		to be taken in the "unknown" case is a matter of local policy.
	policy.
	For example, when control of a domain name is transferred, the new		For example, when control of a domain name is transferred, the new
	domain owner might be unable to determine whether the owner of the		domain owner might be unable to determine whether the owner of the
	subject address has been under continuous ownership since the stated		subject address has been under continuous ownership since the stated
	date if the mailbox history is not also transferred (or was not		date if the mailbox history is not also transferred (or was not
	previously maintained).		previously maintained). It will also be "unknown" if whatever
			database contains mailbox ownership data is temporarily unavailable
	It will also be "unknown" if whatever database contains mailbox		at the time a message arrives for delivery. In this latter case,
	ownership data is temporarily unavailable at the time a message		typical SMTP temporary failure handling is appropriate.
	arrives for delivery. In this case, typical SMTP temporary failure
	handling is appropriate.
	12. Authentication-Results Definitions		12. Authentication-Results Definitions
	[AUTHRES] defines a mechanism for indicating, via a header field, the		[AUTHRES] defines a mechanism for indicating, via a header field, the
	results of message authentication checks. Section 16 registers RRVS		results of message authentication checks. Section 16 registers RRVS
	as a new method that can be reported in this way, and corresponding		as a new method that can be reported in this way, and corresponding
	result names. The possible result names and their meanings are as		result names. The possible result names and their meanings are as
	follows:		follows:
	none: The message had no recipient mailbox timestamp associated with		none: The message had no recipient mailbox timestamp associated with
	skipping to change at page 15, line 44		skipping to change at page 16, line 23
	A message author using this specification might restrict inclusion of		A message author using this specification might restrict inclusion of
	the header field such that it is only done for recipients known also		the header field such that it is only done for recipients known also
	to implement this specification, in order to reduce the possibility		to implement this specification, in order to reduce the possibility
	of revealing information about the relationship between the author		of revealing information about the relationship between the author
	and the mailbox.		and the mailbox.
	If ownership of an entire domain is transferred, the new owner may		If ownership of an entire domain is transferred, the new owner may
	not know what addresses were assigned in the past by the prior owner.		not know what addresses were assigned in the past by the prior owner.
	Hence, no address can be known not to have had a single owner, or to		Hence, no address can be known not to have had a single owner, or to
	have existed (or not) at all.		have existed (or not) at all. In this case, the "unknown" result is
			likely appropriate.
	15. Privacy Considerations		15. Privacy Considerations
	15.1. Probing Attacks		15.1. Probing Attacks
	As described above, use of this extension or header field in probing		As described above, use of this extension or header field in probing
	attacks can disclose information about the history of the mailbox.		attacks can disclose information about the history of the mailbox.
	The harm that can be done by leaking any kind of private information		The harm that can be done by leaking any kind of private information
	is difficult to predict, so it is prudent to be sensitive to this		is difficult to predict, so it is prudent to be sensitive to this
	sort of disclosure, either inadvertently or in response to probing by		sort of disclosure, either inadvertently or in response to probing by
End of changes. 21 change blocks.
	51 lines changed or deleted		74 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/