< draft-ietf-eai-popimap-downgrade-06.txt		draft-ietf-eai-popimap-downgrade-07.txt >
	Email Address Internationalization K. Fujiwara		Email Address Internationalization K. Fujiwara
	(EAI) JPRS		(EAI) JPRS
	Internet-Draft July 9, 2012		Internet-Draft July 31, 2012
	Intended status: Standards Track		Intended status: Standards Track
	Expires: January 10, 2013		Expires: February 1, 2013
	Post-delivery Message Downgrading for Internationalized Email Messages		Post-delivery Message Downgrading for Internationalized Email Messages
	draft-ietf-eai-popimap-downgrade-06.txt		draft-ietf-eai-popimap-downgrade-07.txt
	Abstract		Abstract
	The Email Address Internationalization (SMTPUTF8) extension allows		The Email Address Internationalization (SMTPUTF8) extension to SMTP
	UTF-8 characters in mail header fields. Upgraded POP and IMAP		allows UTF-8 characters in mail header fields. Upgraded POP and IMAP
	servers support internationalized Email messages. If a POP/IMAP		servers support internationalized Email messages. If a POP/IMAP
	client does not support Email Address Internationalization, POP/IMAP		client does not support Email Address Internationalization, POP/IMAP
	servers cannot send Internationalized Email Headers to the client and		servers cannot deliver Internationalized Email Headers to the client
	cannot remove the message. To avoid the situation, this document		and cannot remove the message. To avoid the situation, this document
	describes a conversion mechanism for internationalized Email messages		describes a conversion mechanism for internationalized Email messages
	to be in traditional message format. In the process, message		to be in traditional message format. In the process, message
	elements requiring internationalized treatment are recoded or removed		elements requiring internationalized treatment are recoded or removed
	and receivers are able to know that they received messages containing		and receivers are able to know that they received messages containing
	such elements even if they cannot treat the internationalized		such elements even if they cannot process the internationalized
	elements.		elements.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 January 10, 2013.		This Internet-Draft will expire on February 1, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 2, line 20		skipping to change at page 2, line 20
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Problem statement . . . . . . . . . . . . . . . . . . . . 4		1.1. Problem statement . . . . . . . . . . . . . . . . . . . . 4
	1.2. Possible solutions . . . . . . . . . . . . . . . . . . . . 4		1.2. Possible solutions . . . . . . . . . . . . . . . . . . . . 4
	1.3. Approach taken in this specification . . . . . . . . . . . 4		1.3. Approach taken in this specification . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. New Header Fields Definition . . . . . . . . . . . . . . . . . 6		3. Email Header Fields Downgrading . . . . . . . . . . . . . . . 6
	4. Email Header Fields Downgrading . . . . . . . . . . . . . . . 6		3.1. Downgrading Method for Each ABNF Element . . . . . . . . . 6
	4.1. Downgrading Method for Each ABNF Element . . . . . . . . . 7		3.1.1. <UNSTRUCTURED> Downgrading . . . . . . . . . . . . . . 6
	4.1.1. <UNSTRUCTURED> Downgrading . . . . . . . . . . . . . . 7		3.1.2. <WORD> Downgrading . . . . . . . . . . . . . . . . . . 6
	4.1.2. <WORD> Downgrading . . . . . . . . . . . . . . . . . . 7		3.1.3. <COMMENT> Downgrading . . . . . . . . . . . . . . . . 6
	4.1.3. <COMMENT> Downgrading . . . . . . . . . . . . . . . . 7		3.1.4. <MIME-VALUE> Downgrading . . . . . . . . . . . . . . . 6
	4.1.4. <MIME-VALUE> Downgrading . . . . . . . . . . . . . . . 7		3.1.5. <DISPLAY-NAME> Downgrading . . . . . . . . . . . . . . 7
	4.1.5. <DISPLAY-NAME> Downgrading . . . . . . . . . . . . . . 7		3.1.6. <Domain> Downgrading . . . . . . . . . . . . . . . . . 7
	4.1.6. <GROUP> Downgrading . . . . . . . . . . . . . . . . . 7		3.1.7. <GROUP> Downgrading . . . . . . . . . . . . . . . . . 7
	4.1.7. <MAILBOX> Downgrading . . . . . . . . . . . . . . . . 8		3.1.8. <MAILBOX> Downgrading . . . . . . . . . . . . . . . . 7
	4.1.8. ENCAPSULATION Downgrading . . . . . . . . . . . . . . 8		3.1.9. <TYPED-ADDRESS> Downgrading . . . . . . . . . . . . . 8
	4.1.9. <TYPED-ADDRESS> Downgrading . . . . . . . . . . . . . 8		3.2. Downgrading Method for Each Header Field . . . . . . . . . 8
	4.2. Downgrading Method for Each Header Field . . . . . . . . . 9		3.2.1. Address Header Fields That Contain <address>s . . . . 8
	4.2.1. Address Header Fields That Contain <address>s . . . . 9		3.2.2. Address Header Fields with Typed Addresses . . . . . . 9
	4.2.2. Address Header Fields with Typed Addresses . . . . . . 9		3.2.3. Downgrading Non-ASCII in Comments . . . . . . . . . . 9
	4.2.3. Downgrading Non-ASCII in Comments . . . . . . . . . . 10		3.2.4. Message-ID Header Fields . . . . . . . . . . . . . . . 10
	4.2.4. Message-ID Header Fields . . . . . . . . . . . . . . . 10		3.2.5. Received Header Field . . . . . . . . . . . . . . . . 10
	4.2.5. Received Header Field . . . . . . . . . . . . . . . . 10		3.2.6. MIME Content Header Fields . . . . . . . . . . . . . . 10
	4.2.6. MIME Content Header Fields . . . . . . . . . . . . . . 10		3.2.7. Non-ASCII in <unstructured> . . . . . . . . . . . . . 10
	4.2.7. Non-ASCII in <unstructured> . . . . . . . . . . . . . 11		3.2.8. Non-ASCII in <phrase> . . . . . . . . . . . . . . . . 10
	4.2.8. Non-ASCII in <phrase> . . . . . . . . . . . . . . . . 11		3.2.9. List- Header Fields and Other Header Fields . . . . . 11
	4.2.9. Other Header Fields . . . . . . . . . . . . . . . . . 11		4. ENCAPSULATION: A Last Resort . . . . . . . . . . . . . . . . . 11
	5. MIME Body-Part Header Field Downgrading . . . . . . . . . . . 11		5. MIME Body-Part Header Field Downgrading . . . . . . . . . . . 12
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 12		6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	7. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 13		7. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 13
	7.1. RFC 2047 Encoding . . . . . . . . . . . . . . . . . . . . 13		7.1. RFC 2047 Encoding . . . . . . . . . . . . . . . . . . . . 13
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
	10. Change History . . . . . . . . . . . . . . . . . . . . . . . . 14		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	10.1. Version 00 . . . . . . . . . . . . . . . . . . . . . . . . 15		10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
	10.2. Version 01 . . . . . . . . . . . . . . . . . . . . . . . . 15		10.2. Informative References . . . . . . . . . . . . . . . . . . 17
	10.3. Version 02 . . . . . . . . . . . . . . . . . . . . . . . . 15		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 17
	10.4. Version 03 . . . . . . . . . . . . . . . . . . . . . . . . 15		A.1. Downgrading Example . . . . . . . . . . . . . . . . . . . 17
	10.5. Version 04 . . . . . . . . . . . . . . . . . . . . . . . . 15		Appendix B. Change History . . . . . . . . . . . . . . . . . . . 19
	10.6. Version 05 . . . . . . . . . . . . . . . . . . . . . . . . 16		B.1. Version 00 . . . . . . . . . . . . . . . . . . . . . . . . 19
	10.7. Version 06 . . . . . . . . . . . . . . . . . . . . . . . . 16		B.2. Version 01 . . . . . . . . . . . . . . . . . . . . . . . . 19
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16		B.3. Version 02 . . . . . . . . . . . . . . . . . . . . . . . . 19
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 16		B.4. Version 03 . . . . . . . . . . . . . . . . . . . . . . . . 19
	11.2. Informative References . . . . . . . . . . . . . . . . . . 17		B.5. Version 04 . . . . . . . . . . . . . . . . . . . . . . . . 19
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 18		B.6. Version 05 . . . . . . . . . . . . . . . . . . . . . . . . 20
	A.1. Downgrading Example . . . . . . . . . . . . . . . . . . . 18		B.7. Version 06 . . . . . . . . . . . . . . . . . . . . . . . . 20
			B.8. Version 07 . . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	1.1. Problem statement		1.1. Problem statement
	Traditional (legacy) mail systems, which are defined by [RFC5322],		Traditional (legacy) mail systems, which are defined by [RFC5322] and
	allow only ASCII characters in mail header field values. The		other specifications, allow only ASCII characters in mail header
	SMTPUTF8 extension ([RFC6530] and [RFC6532]) allow raw UTF-8 in those		field values. The SMTPUTF8 extension ([RFC6530], [RFC6531] and
	mail header fields.		[RFC6532]) allow raw UTF-8 in those mail header fields.
	If a header field contains non-ASCII strings, POP/IMAP servers cannot		If a header field contains non-ASCII strings, POP/IMAP servers cannot
	send Internationalized Email Headers to legacy clients and, because		deliver Internationalized Email Headers to legacy clients and,
	they have no obvious or standardized way to explain what is going on		because they have no obvious or standardized way to explain what is
	to those clients, cannot even safely discard the message.		going on to those clients, cannot even safely discard the message.
	1.2. Possible solutions		1.2. Possible solutions
	There are four plausible approaches to the problem, with the		There are four plausible approaches to the problem, with the
	preferred one depending on the particular circumstances and		preferred one depending on the particular circumstances and
	relationship among the delivery SMTP server, the mail store, the POP		relationship among the delivery SMTP server, the mail store, the POP
	or IMAP server, and the users and their MUA clients:		or IMAP server, and the users and their MUA clients:
	1. If the delivery MTA has sufficient knowledge about the POP and/or		1. If the delivery MTA has sufficient knowledge about the POP and/or
	IMAP servers and clients being used, the message may be rejected		IMAP servers and clients being used, the message may be rejected
	skipping to change at page 4, line 52		skipping to change at page 4, line 52
	1.3. Approach taken in this specification		1.3. Approach taken in this specification
	This specification describes the second of those options. It is		This specification describes the second of those options. It is
	worth noticing that, at least in the general case, none of these		worth noticing that, at least in the general case, none of these
	options preserve sufficient information to guarantee that it is		options preserve sufficient information to guarantee that it is
	possible to reply to an incoming message without loss of information,		possible to reply to an incoming message without loss of information,
	so the choice may be considered to be among "least bad" options.		so the choice may be considered to be among "least bad" options.
	This message downgrading mechanism converts mail header fields to an		This message downgrading mechanism converts mail header fields to an
	all-ASCII representation. The POP/IMAP servers can use the		all-ASCII representation. The POP/IMAP servers can use the
	downgrading mechanism and send the Internationalized Email message as		downgrading mechanism and deliver the Internationalized Email message
	a traditional form. Receivers can know they received some		as a traditional form. Receivers can know they received some
	internationalized messages or some unknown/broken messages.		internationalized messages or some unknown/broken messages.
	[RFC6532] allows UTF-8 characters to be used in mail header fields		[RFC6532] allows UTF-8 characters to be used in mail header fields
	and MIME header fields. The message downgrading mechanism specified		and MIME header fields. [RFC6531] allows UTF-8 characters to be used
	here describes the conversion method from the internationalized		in some trace header fields. The message downgrading mechanism
	messages that are defined in [RFC6530], and [RFC6532] to the		specified here describes the conversion method from the
	traditional email messages defined in [RFC5322].		internationalized messages that are defined in [RFC6530], and
			[RFC6532] to the traditional email messages defined in [RFC5322].
	This document provides a precise definition of the minimum-		This document provides a precise definition of the minimum-
	information-loss message downgrading process.		information-loss message downgrading process.
	Downgrading consists of the following three parts:		Downgrading consists of the following three parts:
	o New header field definitions		o New header field definitions
	o Email header field downgrading		o Email header field downgrading
	o MIME header field downgrading		o MIME header field downgrading
	In Section 3 of this document, header fields starting with		Email header field downgrading is described in Section 3. It
			generates ASCII-only header fields.
			In Section 4 of this document, header fields starting with
	"Downgraded-" are introduced. They preserve the information that		"Downgraded-" are introduced. They preserve the information that
	appeared in the original header fields.		appeared in the original header fields.
	Email header field downgrading is described in Section 4. It
	generates ASCII-only header fields.
	The definition of MIME header fields in Internationalized Email		The definition of MIME header fields in Internationalized Email
	Messages is described in [RFC6532]. MIME header field downgrading is		Messages is described in [RFC6532]. MIME header field downgrading is
	described in Section 5. It generates ASCII-only MIME header fields.		described in Section 5. It generates ASCII-only MIME header fields.
	Displaying downgraded messages that originally contained		Displaying downgraded messages that originally contained
	internationalized header fields is out of scope of this document. A		internationalized header fields is out of scope of this document. A
	POP/IMAP client which does not support UTF8 extension does not know		POP/IMAP client which does not support UTF8 extensions as defined for
	internationalized message format described in [RFC6532].		POP3 [UTF8 command] and IMAP ["ENABLE UTF8=ACCEPT" command] does not
			know internationalized message format described in [RFC6532].
	2. Terminology		2. Terminology
	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 RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	All specialized terms used in this specification are defined in the		All specialized terms used in this specification are defined in the
	Overview and Framework for Internationalized Email [RFC6530], in the		Overview and Framework for Internationalized Email [RFC6530], in the
	mail message specifications [RFC5322], or in the MIME documents		mail message specifications [RFC5322], or in the MIME documents
	[RFC2045] [RFC2047] [RFC2183] [RFC2231]. The terms "ASCII address",
	"non-ASCII address", "SMTPUTF8", "message", "internationalized
	message" are used with the definitions from [RFC6530]. The term
	"non-ASCII string" is used with the definitions from [RFC6532].
	3. New Header Fields Definition
	New header fields are defined to preserve information that appeared
	in non-ASCII strings in header fields of the incoming message. The
	values of the new fields holds the original header field value in
	encoded form. The revised header field syntax is specified as
	follows:
	fields =/ downgraded
	downgraded = "Downgraded-Message-Id:" unstructured CRLF /
	"Downgraded-Resent-Message-Id:" unstructured CRLF /
	"Downgraded-In-Reply-To:" unstructured CRLF /
	"Downgraded-References:" unstructured CRLF /
	"Downgraded-Original-Recipient:" unstructured CRLF /
	"Downgraded-Final-Recipient:" unstructured CRLF
	To preserve a header field in a "Downgraded-" header field:
	1. Generate a new header field.
	* The field name is a concatenation of "Downgraded-" and the
	original field name.
	* The initial new field value is the original header field
	value.
	2. Treat the initial new header field value as if it were
	unstructured, and then apply [RFC2047] encoding with charset
	UTF-8 as necessary so that the resulting new header field value
	is completely in ASCII.
	3. Remove the original header field.		[RFC2045] [RFC2047] [RFC2183] [RFC2231]. The terms "U-label",
			"A-label" and "IDNA" are used with the definitions from [RFC5890].
			The terms "ASCII address", "non-ASCII address", "SMTPUTF8",
			"message", "internationalized message" are used with the definitions
			from [RFC6530]. The term "non-ASCII string" is used with the
			definitions from [RFC6532].
	4. Email Header Fields Downgrading		3. Email Header Fields Downgrading
	This section defines the conversion method to ASCII for each header		This section defines the conversion method to ASCII for each header
	field that may contain non-ASCII strings.		field that may contain non-ASCII strings. Section 3.1 describes
			rewriting methods for each ABNF element. Section 3.2 describes
	[RFC6532] expands "Received:" header fields; [RFC5322] describes ABNF		rewriting methods for each header field.
	elements <mailbox>, <word>, <comment>, <unstructured>; [RFC2045]
	describes ABNF element <value>.
	4.1. Downgrading Method for Each ABNF Element		3.1. Downgrading Method for Each ABNF Element
	Header field downgrading is defined below for each ABNF element.		Header field downgrading is defined below for each ABNF element.
	Converting the header field terminates when no non-ASCII strings		Converting the header field terminates when no non-ASCII strings
	remain in the header field.		remain in the header field.
	4.1.1. <UNSTRUCTURED> Downgrading		[RFC5322] describes ABNF elements <group>, <mailbox>, <unstructured>,
			<word>, <comment>, <display-name>. [RFC2045] describes ABNF element
			<value>. <Domain> is updated to allow non-ASCII characters in Section
			3.3 of [RFC6531] and Section 3.2 of [RFC6532].
			3.1.1. <UNSTRUCTURED> Downgrading
	If the header field has an <unstructured> field that contains non-		If the header field has an <unstructured> field that contains non-
	ASCII strings, apply [RFC2047] encoding with charset UTF-8.		ASCII strings, apply [RFC2047] encoding with charset UTF-8.
	4.1.2. <WORD> Downgrading		3.1.2. <WORD> Downgrading
	If the header field has any <word> fields that contain non-ASCII		If the header field has any <word> fields that contain non-ASCII
	strings, apply [RFC2047] encoding with charset UTF-8.		strings, apply [RFC2047] encoding with charset UTF-8.
	4.1.3. <COMMENT> Downgrading		3.1.3. <COMMENT> Downgrading
	If the header field has any <comment> fields that contain non-ASCII		If the header field has any <comment> fields that contain non-ASCII
	strings, apply [RFC2047] encoding with charset UTF-8.		strings, apply [RFC2047] encoding with charset UTF-8.
	4.1.4. <MIME-VALUE> Downgrading		3.1.4. <MIME-VALUE> Downgrading
	If the header field has any <value> elements defined by [RFC2045] and		If the header field has any <value> elements defined by [RFC2045] and
	the elements contain non-ASCII strings, encode the <value> elements		the elements contain non-ASCII strings, encode the <value> elements
	according to [RFC2231] with charset UTF-8 and leave the language		according to [RFC2231] with charset UTF-8 and leave the language
	information empty. If the <value> element is <quoted-string> and it		information empty. If the <value> element is <quoted-string> and it
	contains <CFWS> outside the DQUOTE, remove the <CFWS> before this		contains <CFWS> outside the DQUOTE, remove the <CFWS> before this
	conversion.		conversion.
	4.1.5. <DISPLAY-NAME> Downgrading		3.1.5. <DISPLAY-NAME> Downgrading
	If the header field has any <address> (<mailbox> or <group>) elements		If the header field has any <address> (<mailbox> or <group>) elements
	and they have <display-name> elements that contain non-ASCII strings,		and they have <display-name> elements that contain non-ASCII strings,
	encode the <display-name> elements according to [RFC2047] with		encode the <display-name> elements according to [RFC2047] with
	charset UTF-8. DISPLAY-NAME downgrading is the same algorithm as		charset UTF-8. DISPLAY-NAME downgrading is the same algorithm as
	WORD downgrading.		WORD downgrading.
	4.1.6. <GROUP> Downgrading		3.1.6. <Domain> Downgrading
			If the header field has any <Domain> elements that contain U-labels,
			rewrite the non-ASCII domain name into ASCII domain name using
			A-labels as specified in IDNA [RFC5891].
			3.1.7. <GROUP> Downgrading
	<group> is defined in Section 3.4 of [RFC5322]. The <group> elements		<group> is defined in Section 3.4 of [RFC5322]. The <group> elements
	may contain <mailbox>s which contain non-ASCII addresses.		may contain <mailbox>es which contain non-ASCII addresses.
	If the header field has any <group> elements that contain <mailbox>		If the header field has any <group> elements that contain <mailbox>
	elements, and those <mailbox> elements in turn contain non-ASCII		elements and one of <mailbox>es contains a non-ASCII <local-part>,
	addresses, rewrite each <group> element as		rewrite each <group> element as
	display-name ENCODED_WORD " :;"		display-name ENCODED_WORD " :;"
	where the <ENCODED_WORD> is the original <group-list> encoded		where the <ENCODED_WORD> is the original <group-list> encoded
	according to [RFC2047].		according to [RFC2047].
	4.1.7. <MAILBOX> Downgrading		Otherwise, the header field does not contain non-ASCII <local-part>.
			If the header field contain non-ASCII <mailbox>es, they contain non-
			ASCII domain names. Rewrite the non-ASCII domain names into ASCII
			domain names using A-labels as specified in IDNA [RFC5891].
			Generated <mailbox>es contain ASCII addresses only.
	The <mailbox> elements have no equivalent format for non-ASCII		3.1.8. <MAILBOX> Downgrading
	addresses. If the header field has any <mailbox> elements that
	contain non-ASCII strings in their <addr-spec> element, rewrite each		If the <local-part> of the <mailbox> element does not contain non-
	<addr-spec> element to ASCII-only format. The <addr-spec> element		ASCII characters, the <domain> element contains non-ASCII characters.
	that contains non-ASCII strings may appear in two forms as:		Rewrite the non-ASCII domain name into ASCII domain name using
			A-labels as specified in IDNA [RFC5891].
			Otherwise, the <local-part> contains non-ASCII characters. The non-
			ASCII <local-part> has no equivalent format for ASCII addresses.
			Rewrite each <addr-spec> element to ASCII-only group format following
			the model above. The <addr-spec> element that contains non-ASCII
			strings may appear in two forms as:
	"<" addr-spec ">"		"<" addr-spec ">"
	addr-spec		addr-spec
	Rewrite both as:		Rewrite both as:
	ENCODED-WORD " :;"		ENCODED-WORD " :;"
	where the <ENCODED-WORD> is the original <addr-spec> encoded		where the <ENCODED-WORD> is the original <addr-spec> encoded
	according to [RFC2047].		according to [RFC2047].
	4.1.8. ENCAPSULATION Downgrading		3.1.9. <TYPED-ADDRESS> Downgrading
	Encapsulate the header field in a "Downgraded-" header field as
	described in Section 3 as a last resort.
	Applying this procedure to "Received:" header field is prohibited.
	ENCAPSULATION Downgrading is allowed for "Message-ID",
	"In-Reply-To:", "References:", "Original-Recipient" and "Final-
	Recipient" header fields.
	4.1.9. <TYPED-ADDRESS> Downgrading
	If the header field contains <utf-8-type-addr> and the <utf-8-type-		If the header field contains <utf-8-type-addr> and the <utf-8-type-
	addr> contains raw non-ASCII strings, it is in utf-8-address form.		addr> contains raw non-ASCII strings, it is in utf-8-address form.
	Convert it to utf-8-addr-xtext form. Those forms are described in		Convert it to utf-8-addr-xtext form. Those forms are described in
	[RFC6533]. COMMENT downgrading is also performed in this case. If		[RFC6533]. COMMENT downgrading is also performed in this case. If
	the address type is unrecognized and the header field contains non-		the address type is unrecognized and the header field contains non-
	ASCII strings, then fall back to using ENCAPSULATION downgrading on		ASCII strings, then fall back to using ENCAPSULATION on the entire
	the entire header field.		header field specified in Section 4.
	4.2. Downgrading Method for Each Header Field		3.2. Downgrading Method for Each Header Field
	[RFC4021] establishes a registry of header fields. This section		[RFC4021] establishes a registry of header fields. This section
	describes the downgrading method for each header field.		describes the downgrading method for each header field.
	If the whole mail header field does not contain non-ASCII strings,		If the whole mail header field does not contain non-ASCII strings,
	email header field downgrading is not required. Each header field's		email header field downgrading is not required. Each header field's
	downgrading method is described below.		downgrading method is described below.
	4.2.1. Address Header Fields That Contain <address>s		3.2.1. Address Header Fields That Contain <address>s
	From:		From:
	Sender:		Sender:
	To:		To:
	Cc:		Cc:
	Bcc:		Bcc:
	Reply-To:		Reply-To:
	Resent-From:		Resent-From:
	Resent-Sender:		Resent-Sender:
	Resent-To:		Resent-To:
	skipping to change at page 9, line 25		skipping to change at page 9, line 4
	From:		From:
	Sender:		Sender:
	To:		To:
	Cc:		Cc:
	Bcc:		Bcc:
	Reply-To:		Reply-To:
	Resent-From:		Resent-From:
	Resent-Sender:		Resent-Sender:
	Resent-To:		Resent-To:
	Resent-Cc:		Resent-Cc:
	Resent-Bcc:		Resent-Bcc:
	Resent-Reply-To:		Resent-Reply-To:
	Return-Path:		Return-Path:
	Disposition-Notification-To:		Disposition-Notification-To:
	If the header field contains <group> elements that contain non-ASCII		If the header field contains <group> elements that contain non-ASCII
	addresses, perform <COMMENT> downgrading, <DISPLAY-NAME> downgrading,		addresses, perform <COMMENT> downgrading, <DISPLAY-NAME> downgrading,
	and <GROUP> downgrading.		and <GROUP> downgrading as described in the corresponding subsections
			of Section 3.1. Optionally add those words where appropriate to the
			next paragraph, but I think once will make it clear.
	If the header field contains <mailbox> elements that contain non-		If the header field contains <mailbox> elements that contain non-
	ASCII addresses, perform <COMMENT> downgrading, <DISPLAY-NAME>		ASCII addresses, perform <COMMENT> downgrading, <DISPLAY-NAME>
	downgrading, and <MAILBOX> downgrading.		downgrading, and <MAILBOX> downgrading.
	This procedure may generate empty <group> elements in "From:",		This procedure may generate empty <group> elements in "From:",
	"Sender:" and "Reply-To:" header fields.		"Sender:" and "Reply-To:" header fields.
	[I-D.leiba-5322upd-from-group] updates [RFC5322] to allow (empty)		[I-D.leiba-5322upd-from-group] updates [RFC5322] to allow (empty)
	<group> elements in "From:", "Sender:" and "Reply-To:" header fields.		<group> elements in "From:", "Sender:" and "Reply-To:" header fields.
	4.2.2. Address Header Fields with Typed Addresses		3.2.2. Address Header Fields with Typed Addresses
	Original-Recipient:		Original-Recipient:
	Final-Recipient:		Final-Recipient:
	If the header field contains non-ASCII strings, perform <TYPED-		If the header field contains non-ASCII strings, perform <TYPED-
	ADDRESS> downgrading.		ADDRESS> downgrading.
	4.2.3. Downgrading Non-ASCII in Comments		3.2.3. Downgrading Non-ASCII in Comments
	Date:		Date:
	Resent-Date:		Resent-Date:
	MIME-Version:		MIME-Version:
	Content-ID:		Content-ID:
	Content-Transfer-Encoding:		Content-Transfer-Encoding:
	Content-Language:		Content-Language:
	Accept-Language:		Accept-Language:
	Auto-Submitted:		Auto-Submitted:
	These header fields do not contain non-ASCII strings except in		These header fields do not contain non-ASCII strings except in
	comments. If the header field contains UTF-8 characters in comments,		comments. If the header field contains UTF-8 characters in comments,
	perform <COMMENT> downgrading.		perform <COMMENT> downgrading.
	4.2.4. Message-ID Header Fields		3.2.4. Message-ID Header Fields
	Message-ID:		Message-ID:
	Resent-Message-ID:		Resent-Message-ID:
	In-Reply-To:		In-Reply-To:
	References:		References:
	Perform ENCAPSULATION Downgrading.		Perform ENCAPSULATION as specified in Section 4.
	4.2.5. Received Header Field		3.2.5. Received Header Field
	Received:		Received:
	If the FOR clause contains a non-ASCII address, remove the FOR clause		If <Domain> elements or <Mailbox> elements contains U-labels, perform
	from the header field. Comments may contain non-ASCII strings,		<Domain> downgrading specified in Section 3.1.6. Comments may
	Perform <COMMENT> downgrading. Other parts should not contain non-		contain non-ASCII strings, perform <COMMENT> downgrading.
	ASCII strings.
			After the <Domain> downgrading and the <COMMENT> downgrading, if the
			FOR clause contains a non-ASCII <local-part>, remove the "FOR"
			clause. If the ID clause contains a non-ASCII values, remove the
			"ID" clause.
			3.2.6. MIME Content Header Fields
	4.2.6. MIME Content Header Fields
	Content-Type:		Content-Type:
	Content-Disposition:		Content-Disposition:
	Perform <MIME-VALUE> downgrading and <COMMENT> downgrading.		Perform <MIME-VALUE> downgrading and <COMMENT> downgrading.
	4.2.7. Non-ASCII in <unstructured>		3.2.7. Non-ASCII in <unstructured>
	Subject:		Subject:
	Comments:		Comments:
	Content-Description:		Content-Description:
	Perform <UNSTRUCTURED> downgrading.		Perform <UNSTRUCTURED> downgrading.
	4.2.8. Non-ASCII in <phrase>		3.2.8. Non-ASCII in <phrase>
	Keywords:		Keywords:
	Perform <WORD> downgrading.		Perform <WORD> downgrading.
	4.2.9. Other Header Fields		3.2.9. List- Header Fields and Other Header Fields
	There are other header fields that contain non-ASCII strings. They		There are other header fields that contain non-ASCII strings. They
	are user-defined and missing from this document, or future defined		are user-defined and missing from this document, or future defined
	header fields. They are treated as "Optional Fields" and their field		header fields. They are treated as "Optional Fields" and their field
	values are treated as unstructured described in Section 3.6.8 of		values are treated as unstructured described in Section 3.6.8 of
	[RFC5322].		[RFC5322].
	Perform <UNSTRUCTURED> downgrading.		Perform <UNSTRUCTURED> downgrading.
	If the software understands the header field's structure and a		If the software understands the header field's structure and a
	downgrading algorithm other than UNSTRUCTURED is applicable, that		downgrading algorithm other than UNSTRUCTURED is applicable, that
	software SHOULD use that algorithm; UNSTRUCTURED downgrading is used		software SHOULD use that algorithm; UNSTRUCTURED downgrading is used
	as a last resort.		as a last resort.
	Mailing list header fields (those that start in "List-") are part of		Mailing list header fields (those that start in "List-") are part of
	this category.		this category.
			4. ENCAPSULATION: A Last Resort
			As a last resort when header fields cannot be converted as discussed
			in the previous section, the fields are deleted and replaced by
			specialized new header fields. Those fields are defined to preserve,
			in encoded form, as much information as possible from the header
			field values of the incoming message. The syntax of these new header
			fields is:
			fields =/ downgraded
			downgraded = "Downgraded-Message-Id:" unstructured CRLF /
			"Downgraded-Resent-Message-Id:" unstructured CRLF /
			"Downgraded-In-Reply-To:" unstructured CRLF /
			"Downgraded-References:" unstructured CRLF /
			"Downgraded-Original-Recipient:" unstructured CRLF /
			"Downgraded-Final-Recipient:" unstructured CRLF
			Applying this procedure to "Received:" header field is prohibited.
			ENCAPSULATION Downgrading is allowed for "Message-ID",
			"In-Reply-To:", "References:", "Original-Recipient" and "Final-
			Recipient" header fields.
			To preserve a header field in a "Downgraded-" header field:
			1. Generate a new header field.
			* The field name is a concatenation of "Downgraded-" and the
			original field name.
			* The initial new field value is the original header field
			value.
			2. Treat the initial new header field value as if it were
			unstructured, and then apply [RFC2047] encoding with charset
			UTF-8 as necessary so that the resulting new header field value
			is completely in ASCII.
			3. Remove the original header field.
	5. MIME Body-Part Header Field Downgrading		5. MIME Body-Part Header Field Downgrading
	MIME body-part header fields may contain non-ASCII strings [RFC6532].		MIME body-part header fields may contain non-ASCII strings [RFC6532].
	This section defines the conversion method to ASCII-only header		This section defines the conversion method to ASCII-only header
	fields for each MIME header field that contains non-ASCII strings.		fields for each MIME header field that contains non-ASCII strings.
	Parse the message body's MIME structure at all levels and check each		Parse the message body's MIME structure at all levels and check each
	MIME header field to see whether it contains non-ASCII strings. If		MIME header field to see whether it contains non-ASCII strings. If
	the header field contains non-ASCII strings in the header field		the header field contains non-ASCII strings in the header field
	value, the header field is a target of the MIME body-part header		value, the header field is a target of the MIME body-part header
	field's downgrading. Each MIME header field's downgrading method is		field's downgrading. Each MIME header field's downgrading method is
	described below. COMMENT downgrading, MIME-VALUE downgrading, and		described below. COMMENT downgrading, MIME-VALUE downgrading, and
	UNSTRUCTURED downgrading are described in Section 4.		UNSTRUCTURED downgrading are described in Section 3.
	Content-ID:		Content-ID:
	The "Content-ID:" header field does not contain non-ASCII strings		The "Content-ID:" header field does not contain non-ASCII strings
	except in comments. If the header field contains UTF-8 characters		except in comments. If the header field contains UTF-8 characters
	in comments, perform <COMMENT> downgrading.		in comments, perform <COMMENT> downgrading.
	Content-Type:		Content-Type:
	Content-Disposition:		Content-Disposition:
	Perform <MIME-VALUE> downgrading and <COMMENT> downgrading.		Perform <MIME-VALUE> downgrading and <COMMENT> downgrading.
	skipping to change at page 12, line 40		skipping to change at page 13, line 16
	But they still contain MIME-encapsulated header fields that contain		But they still contain MIME-encapsulated header fields that contain
	non-ASCII strings. Furthermore, the body part may contain UTF-8		non-ASCII strings. Furthermore, the body part may contain UTF-8
	characters. Implementations parsing Internet messages need to accept		characters. Implementations parsing Internet messages need to accept
	UTF-8 body parts and UTF-8 header fields that are MIME-encoded.		UTF-8 body parts and UTF-8 header fields that are MIME-encoded.
	Thus, this document inherits the security considerations of MIME-		Thus, this document inherits the security considerations of MIME-
	encoded header fields ([RFC2047] and [RFC3629]).		encoded header fields ([RFC2047] and [RFC3629]).
	Rewriting header fields increases the opportunities for undetected		Rewriting header fields increases the opportunities for undetected
	spoofing by malicious senders. However, the rewritten header field		spoofing by malicious senders. However, the rewritten header field
	values are preserved in equivalent MIME form or in newly defined		values are preserved in equivalent MIME form or in newly defined
	header fields which traditional MUAs do not care.		header fields for which traditional MUAs have no special processing
			procedures.
	The techniques described here invalidate methods that depend on		The techniques described here invalidate methods that depend on
	digital signatures over any part of the message, which includes the		digital signatures over any part of the message, which includes the
	top-level header fields and body-part header fields. Depending on		top-level header fields and body-part header fields. Depending on
	the specific message being downgraded, at least the following		the specific message being downgraded, at least the following
	techniques are likely to break: DomainKeys Identified Mail (DKIM),		techniques are likely to break: DomainKeys Identified Mail (DKIM),
	and possibly S/MIME and Pretty Good Privacy (PGP). Receivers may		and possibly S/MIME and Pretty Good Privacy (PGP). Receivers may
	know they need to update their MUAs, or they don't care.		know they need to update their MUAs, or they don't care.
	While information in any email header field should usually be treated		While information in any email header field should usually be treated
	with some suspicion, current email systems commonly employ various		with some suspicion, current email systems commonly employ various
	mechanisms and protocols to make the information more trustworthy.		mechanisms and protocols to make the information more trustworthy.
	Information in the new Downgraded-* header fields is not inspected by		Information in the new Downgraded-* header fields is not inspected by
	MUAs, and may be even less trustworthy than the traditional header		traditional MUAs, and may be even less trustworthy than the
	fields. Note that the Downgraded-* header fields could have been		traditional header fields. Note that the Downgraded-* header fields
	inserted with malicious intent (and with content unrelated to the		could have been inserted with malicious intent (and with content
	traditional header fields), however traditional MUAs do not parse		unrelated to the traditional header fields), however traditional MUAs
	Downgraded-* header fields.		do not parse Downgraded-* header fields.
	In addition, if an Authentication-Results header field [RFC5451] is		In addition, if an Authentication-Results header field [RFC5451] is
	present, traditional MUAs may treat that the digital signatures are		present, traditional MUAs may treat that the digital signatures are
	valid.		valid.
	See the "Security Considerations" section in		See the "Security Considerations" section in
	[I-D.leiba-5322upd-from-group] and [RFC6530] for more discussion.		[I-D.leiba-5322upd-from-group] and [RFC6530] for more discussion.
	7. Implementation Notes		7. Implementation Notes
	skipping to change at page 14, line 9		skipping to change at page 14, line 30
	does not use all "Downgraded-" header fields registered by [RFC5504].		does not use all "Downgraded-" header fields registered by [RFC5504].
	The following header fields should be registered in the Permanent		The following header fields should be registered in the Permanent
	Message Header Field registry, in accordance with the procedures set		Message Header Field registry, in accordance with the procedures set
	out in [RFC3864].		out in [RFC3864].
	Header field name: Downgraded-Message-Id		Header field name: Downgraded-Message-Id
	Applicable protocol: mail		Applicable protocol: mail
	Status: standard		Status: standard
	Author/change controller: IETF		Author/change controller: IETF
	Specification document(s): This document (Section 3)		Specification document(s): This document (Section 4)
	Header field name: Downgraded-In-Reply-To		Header field name: Downgraded-In-Reply-To
	Applicable protocol: mail		Applicable protocol: mail
	Status: standard		Status: standard
	Author/change controller: IETF		Author/change controller: IETF
	Specification document(s): This document (Section 3)		Specification document(s): This document (Section 4)
	Header field name: Downgraded-References		Header field name: Downgraded-References
	Applicable protocol: mail		Applicable protocol: mail
	Status: standard		Status: standard
	Author/change controller: IETF		Author/change controller: IETF
	Specification document(s): This document (Section 3)		Specification document(s): This document (Section 4)
	Header field name: Downgraded-Original-Recipient		Header field name: Downgraded-Original-Recipient
	Applicable protocol: mail		Applicable protocol: mail
	Status: standard		Status: standard
	Author/change controller: IETF		Author/change controller: IETF
	Specification document(s): This document (Section 3)		Specification document(s): This document (Section 4)
	Header field name: Downgraded-Final-Recipient		Header field name: Downgraded-Final-Recipient
	Applicable protocol: mail		Applicable protocol: mail
	Status: standard		Status: standard
	Author/change controller: IETF		Author/change controller: IETF
	Specification document(s): This document (Section 3)		Specification document(s): This document (Section 4)
	9. Acknowledgements		9. Acknowledgements
	This document draws heavily from the experimental in-transit message		This document draws heavily from the experimental in-transit message
	downgrading procedure described in RFC 5504 [RFC5504]. The		downgrading procedure described in RFC 5504 [RFC5504]. The
	contribution of the co-author of that earlier document, Y. Yoneya,		contribution of the co-author of that earlier document, Y. Yoneya,
	are gratefully acknowledged. Significant comments and suggestions		are gratefully acknowledged. Significant comments and suggestions
	were received from John Klensin, Barry Leiba, Randall Gellens, Pete		were received from John Klensin, Barry Leiba, Randall Gellens, Pete
	Resnick, Martin J. Durst, and other WG participants.		Resnick, Martin J. Durst, and other WG participants.
	10. Change History		10. References
	[[RFC Editor: Please remove this section prior to publication.]]
	This section is used for tracking the update of this document. Will
	be removed after finalize.
	10.1. Version 00
	o Initial version
	o Imported header field downgrading from RFC 5504
	10.2. Version 01
	o same as Version 00
	10.3. Version 02
	o Added updating RFC 5322 to allow <group> syntax in From: and
	Sender
	o Added GROUP Downgrading
	10.4. Version 03
	o Replaced <utf8-addr-spec> with <addr-spec>
	o Added updating RFC 5322 to allow <group> syntax in From: and
	Sender
	o Added one sentence in Security considerations
	o Updated IANA considerations
	10.5. Version 04
	o Removed "Internationalized Address removed" from GROUP and MAILBOX
	downgrading
	o Updated "Updating RFC 5322"
	o Compacted new header field definition
	o Compacted security considerations
	o Updated IANA considerations to remove obsoleting header fields
	that are registered by RFC 5504
	o Added a discussion of alternate downgrading models for the POP and
	IMAP cases.
	o Incorporated a large number of editorial changes to improve
	clarity.
	10.6. Version 05
	o Some text corrections
	o Terminology change: only to use non-ASCII address, non-ASCII
	message, non-ASCII string and imported them from RFC 6530 and RFC
	6532
	o Replace "non-ASCII character" with "non-ASCII string"
	o Removed 5.1.1. RECEIVED Downgrading: It's
	10.7. Version 06
	o Removed "Updating RFC 5322"
	o Added reference to draft-leiba-5322upd-from-group
	11. References
	11.1. Normative References		10.1. Normative References
	[RFC2045] Freed, N. and N. Borenstein,		[RFC2045] Freed, N. and N. Borenstein,
	"Multipurpose Internet Mail		"Multipurpose Internet Mail
	Extensions (MIME) Part One: Format of		Extensions (MIME) Part One: Format of
	Internet Message Bodies", RFC 2045,		Internet Message Bodies", RFC 2045,
	November 1996.		November 1996.
	[RFC2047] Moore, K., "MIME (Multipurpose		[RFC2047] Moore, K., "MIME (Multipurpose
	Internet Mail Extensions) Part Three:		Internet Mail Extensions) Part Three:
	Message Header Extensions for Non-		Message Header Extensions for Non-
	skipping to change at page 17, line 21		skipping to change at page 16, line 21
	Message Header Fields", BCP 90,		Message Header Fields", BCP 90,
	RFC 3864, September 2004.		RFC 3864, September 2004.
	[RFC4021] Klyne, G. and J. Palme, "Registration		[RFC4021] Klyne, G. and J. Palme, "Registration
	of Mail and MIME Header Fields",		of Mail and MIME Header Fields",
	RFC 4021, March 2005.		RFC 4021, March 2005.
	[RFC5322] Resnick, P., Ed., "Internet Message		[RFC5322] Resnick, P., Ed., "Internet Message
	Format", RFC 5322, October 2008.		Format", RFC 5322, October 2008.
			[RFC5890] Klensin, J., "Internationalized
			Domain Names for Applications (IDNA):
			Definitions and Document Framework",
			RFC 5890, August 2010.
			[RFC5891] Klensin, J., "Internationalized
			Domain Names in Applications (IDNA):
			Protocol", RFC 5891, August 2010.
	[RFC6530] Klensin, J. and Y. Ko, "Overview and		[RFC6530] Klensin, J. and Y. Ko, "Overview and
	Framework for Internationalized		Framework for Internationalized
	Email", RFC 6530, February 2012.		Email", RFC 6530, February 2012.
			[RFC6531] Yao, J. and W. Mao, "SMTP Extension
			for Internationalized Email",
			RFC 6531, February 2012.
	[RFC6532] Yang, A., Steele, S., and N. Freed,		[RFC6532] Yang, A., Steele, S., and N. Freed,
	"Internationalized Email Headers",		"Internationalized Email Headers",
	RFC 6532, February 2012.		RFC 6532, February 2012.
	[RFC6533] Hansen, T., Newman, C., and A.		[RFC6533] Hansen, T., Newman, C., and A.
	Melnikov, "Internationalized Delivery		Melnikov, "Internationalized Delivery
	Status and Disposition		Status and Disposition
	Notifications", RFC 6533,		Notifications", RFC 6533,
	February 2012.		February 2012.
	[I-D.leiba-5322upd-from-group] Leiba, B., "Update to Internet		[I-D.leiba-5322upd-from-group] Leiba, B., "Update to Internet
	Message Format to Allow Group Syntax		Message Format to Allow Group Syntax
	in the 'From:' Header Field",		in the 'From:' Header Field",
	draft-leiba-5322upd-from-group-01		draft-leiba-5322upd-from-group-03
	(work in progress), July 2012.		(work in progress), July 2012.
	11.2. Informative References		10.2. Informative References
	[RFC5451] Kucherawy, M., "Message Header Field		[RFC5451] Kucherawy, M., "Message Header Field
	for Indicating Message Authentication		for Indicating Message Authentication
	Status", RFC 5451, April 2009.		Status", RFC 5451, April 2009.
	[RFC5504] Fujiwara, K. and Y. Yoneya,		[RFC5504] Fujiwara, K. and Y. Yoneya,
	"Downgrading Mechanism for Email		"Downgrading Mechanism for Email
	Address Internationalization",		Address Internationalization",
	RFC 5504, March 2009.		RFC 5504, March 2009.
	skipping to change at page 19, line 13		skipping to change at page 18, line 13
	non-ASCII strings.		non-ASCII strings.
	Return-Path: <NON-ASCII-LOCAL@example.com>		Return-Path: <NON-ASCII-LOCAL@example.com>
	Received: from ... by ... for <NON-ASCII-REMOTE1@example.net>		Received: from ... by ... for <NON-ASCII-REMOTE1@example.net>
	Received: from ... by ... for <NON-ASCII-REMOTE1@example.net>		Received: from ... by ... for <NON-ASCII-REMOTE1@example.net>
	From: DISPLAY-LOCAL <NON-ASCII-LOCAL@example.com>		From: DISPLAY-LOCAL <NON-ASCII-LOCAL@example.com>
	To: DISPLAY-REMOTE1 <NON-ASCII-REMOTE1@example.net>,		To: DISPLAY-REMOTE1 <NON-ASCII-REMOTE1@example.net>,
	DISPLAY-REMOTE2 <NON-ASCII-REMOTE2@example.com>		DISPLAY-REMOTE2 <NON-ASCII-REMOTE2@example.com>
	Cc: DISPLAY-REMOTE3 <NON-ASCII-REMOTE3@example.org>		Cc: DISPLAY-REMOTE3 <NON-ASCII-REMOTE3@example.org>
	Subject: NON-ASCII-SUBJECT		Subject: NON-ASCII-SUBJECT
	Date: DATE		Date: Mon, 30 Jul 2012 01:23:45 -0000
	Message-Id: NON-ASCII-MESSAGE_ID		Message-Id: NON-ASCII-MESSAGE_ID
	Mime-Version: 1.0		Mime-Version: 1.0
	Content-Type: text/plain; charset="UTF-8"		Content-Type: text/plain; charset="UTF-8"
	Content-Transfer-Encoding: 8bit		Content-Transfer-Encoding: 8bit
	X-Unknown-Header: NON-ASCII-CHARACTERS		X-Unknown-Header: NON-ASCII-CHARACTERS
	MAIL_BODY		MAIL_BODY
	Figure 1: Received message in a mail drop		Figure 1: Received message in a mail drop
	skipping to change at page 19, line 42		skipping to change at page 18, line 42
	Received: from ... by ...		Received: from ... by ...
	From: =?UTF-8?Q?DISPLAY-LOCAL?=		From: =?UTF-8?Q?DISPLAY-LOCAL?=
	=?UTF-8?Q?NON-ASCII-LOCAL@example.com?= :;		=?UTF-8?Q?NON-ASCII-LOCAL@example.com?= :;
	To: =?UTF-8?Q?DISPLAY-REMOTE1?=		To: =?UTF-8?Q?DISPLAY-REMOTE1?=
	=?UTF-8?Q?NON-ASCII-REMOTE1@example.net?= :;,		=?UTF-8?Q?NON-ASCII-REMOTE1@example.net?= :;,
	=?UTF-8?Q?DISPLAY-REMOTE2?=		=?UTF-8?Q?DISPLAY-REMOTE2?=
	=?UTF-8?Q?NON-ASCII-REMOTE2@example.com?= :;,		=?UTF-8?Q?NON-ASCII-REMOTE2@example.com?= :;,
	Cc: =?UTF-8?Q?DISPLAY-REMOTE3?=		Cc: =?UTF-8?Q?DISPLAY-REMOTE3?=
	=?UTF-8?Q?NON-ASCII-REMOTE3@example.org?= :;		=?UTF-8?Q?NON-ASCII-REMOTE3@example.org?= :;
	Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?=		Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?=
	Date: DATE		Date: Mon, 30 Jul 2012 01:23:45 -0000
	Downgraded-Message-Id: =?UTF-8?Q?MESSAGE_ID?=		Downgraded-Message-Id: =?UTF-8?Q?MESSAGE_ID?=
	Mime-Version: 1.0		Mime-Version: 1.0
	Content-Type: text/plain; charset="UTF-8"		Content-Type: text/plain; charset="UTF-8"
	Content-Transfer-Encoding: 8bit		Content-Transfer-Encoding: 8bit
	X-Unknown-Header: =?UTF-8?Q?NON-ASCII-CHARACTERS?=		X-Unknown-Header: =?UTF-8?Q?NON-ASCII-CHARACTERS?=
	MAIL_BODY		MAIL_BODY
	Figure 2: Downgraded message		Figure 2: Downgraded message
			Appendix B. Change History
			[[RFC Editor: Please remove this section prior to publication.]]
			This section is used for tracking the update of this document. Will
			be removed after finalize.
			B.1. Version 00
			o Initial version
			o Imported header field downgrading from RFC 5504
			B.2. Version 01
			o same as Version 00
			B.3. Version 02
			o Added updating RFC 5322 to allow <group> syntax in From: and
			Sender
			o Added GROUP Downgrading
			B.4. Version 03
			o Replaced <utf8-addr-spec> with <addr-spec>
			o Added updating RFC 5322 to allow <group> syntax in From: and
			Sender
			o Added one sentence in Security considerations
			o Updated IANA considerations
			B.5. Version 04
			o Removed "Internationalized Address removed" from GROUP and MAILBOX
			downgrading
			o Updated "Updating RFC 5322"
			o Compacted new header field definition
			o Compacted security considerations
			o Updated IANA considerations to remove obsoleting header fields
			that are registered by RFC 5504
			o Added a discussion of alternate downgrading models for the POP and
			IMAP cases.
			o Incorporated a large number of editorial changes to improve
			clarity.
			B.6. Version 05
			o Some text corrections
			o Terminology change: only to use non-ASCII address, non-ASCII
			message, non-ASCII string and imported them from RFC 6530 and RFC
			6532
			o Replace "non-ASCII character" with "non-ASCII string"
			o Removed 5.1.1. RECEIVED Downgrading
			B.7. Version 06
			o Removed "Updating RFC 5322"
			o Added reference to draft-leiba-5322upd-from-group
			B.8. Version 07
			o Updated by WGLC comments
			o Fixed Received downgrading and added to refer "RFC 6531", "RFC
			5890", "RFC 5891"
			o Added Domain downgrading for Received, Group and Mailbox
			o Swapped section 3 and 4
	Author's Address		Author's Address
	Kazunori Fujiwara		Kazunori Fujiwara
	Japan Registry Services Co., Ltd.		Japan Registry Services Co., Ltd.
	Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda		Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
	Chiyoda-ku, Tokyo 101-0065		Chiyoda-ku, Tokyo 101-0065
	Japan		Japan
	Phone: +81 3 5215 8451		Phone: +81 3 5215 8451
	EMail: fujiwara@wide.ad.jp, fujiwara@jprs.co.jp		EMail: fujiwara@wide.ad.jp, fujiwara@jprs.co.jp
End of changes. 66 change blocks.
	246 lines changed or deleted		300 lines changed or added
This html diff was produced by rfcdiff 1.39p1. The latest version is available from http://tools.ietf.org/tools/rfcdiff/