One document matched: draft-ietf-eai-downgraded-display-03.xml

<?xml version="1.0"?>
<!-- $Id: draft-ietf-eai-downgraded-display-03.xml,v 1.10 2009/12/01 09:50:07 fujiwara Exp $ -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY % rfc2119 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
  <!ENTITY % rfc2045 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2045.xml'>
  <!ENTITY % rfc2047 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2047.xml'>
  <!ENTITY % rfc2183 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2183.xml'>
  <!ENTITY % rfc2231 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2231.xml'>
  <!ENTITY % rfc5321 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5321.xml'>
  <!ENTITY % rfc5322 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5322.xml'>
  <!ENTITY % rfc3461 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3461.xml'>
  <!ENTITY % rfc3864 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3864.xml'>
  <!ENTITY % rfc4021 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4021.xml'>
  <!ENTITY % rfc4952 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4952.xml'>
  <!ENTITY % rfc5335 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5335.xml'>
  <!ENTITY % rfc5336 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5336.xml'>
  <!ENTITY % rfc5337 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5337.xml'>
  <!ENTITY % rfc5504 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5504.xml'>
  ]>

<?rfc compact='yes'?>
<?rfc toc='yes'?>

<!-- Validator on -->
<?rfc strict="yes" ?>

<!-- Expand crefs and put them inline -->
<?rfc comments='yes' ?>
<?rfc inline='yes' ?>  

<!-- RFC references as names, not numbers -->
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>

<rfc category="exp" ipr="trust200902" docName="draft-ietf-eai-downgraded-display-03.txt">
<!-- ipr: full2026 / noDerivativeWorks2026 / none -->

<front>
  <title abbrev="Displaying Downgraded Messages">
    Displaying Downgraded Messages for Email Address Internationalization
  </title>
  <author initials="K.F." surname="Fujiwara" fullname="Kazunori Fujiwara">
    <organization abbrev="JPRS">Japan Registry Services Co., Ltd.</organization>
    <address>
	<postal>
	<street>Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda</street>
	<city>Chiyoda-ku</city>
	<region>Tokyo</region>
	<code>101-0065</code>
	<country>Japan</country>
	</postal>
	<phone>+81-3-5215-8451</phone>
	<email>fujiwara@jprs.co.jp</email>
    </address>
  </author>
  
    <author initials='B.' surname="Leiba" fullname='Barry Leiba'>
      <organization>Huawei Technologies</organization>
      <address>
        <phone>+1 646 827 0648</phone>
        <email>barryleiba@computer.org</email>
        <uri>http://internetmessagingtechnology.org/</uri>
      </address>
    </author>
  
  <date year="2009" />
  <area>Applications</area>
  <workgroup>Email Address Internationalization (EAI)</workgroup>
  <!-- <area ...>, <workgroup ...>, <keyword ...>, <keyword ...> <note..> -->

  <abstract>
    <t>
This document describes a method for displaying downgraded messages
which originally contained internationalized E-mail addresses or
internationalized header fields.
    </t>
  </abstract>
</front>

<middle>
  <section title="Introduction" anchor="intro">
	<t>
	The Email Address Internationalization (UTF8SMTP) extension document set
	<xref target="RFC4952" />
	<xref target="RFC5336" />
	<xref target="RFC5335" />
	<xref target="RFC5337" />
	expands Email address structure, syntax and Email header format.
	To avoid rejection of internationalized Email messages,
	the downgrading mechanism <xref target="RFC5504" />
	converts an internationalized message to a traditional Email message
	when a server in the delivery path does not support the UTF8SMTP extension.
	The downgraded message is a traditional Email message,
	except the message has "Downgraded-" header fields.
	</t>
	<t>
	A perfect reverse-function of the downgrading does not exist
	because the encoding defined in <xref target="RFC2047" /> is not exactly reversible
	and Received header field downgrading may remove FOR clause information.
	The restoration of the downgrading should be done once at the final
	destination of the downgraded message such as MUAs or IMAP servers.
	This document describes the restoration methods for displaying downgraded messages
	in MUAs.
	</t>
  </section>

  <section title="Terminology">
    <t>
      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 <xref target="RFC2119" />.
    </t>
    <t>
   Specialized terms used in this specification are defined in the
   EAI overview <xref target="RFC4952" /> or in
	<xref target="RFC5321" /><xref target="RFC5322" />,
	MIME documents
		<xref target="RFC2045" />
		<xref target="RFC2047" />
		<xref target="RFC2183" />
		<xref target="RFC2231" />.
    </t>
    <t>
	This document depends on
	<xref target="RFC5335" /> and
	<xref target="RFC5504" />.
	Key words used in these document are used in this document, too.
    </t>
    <t>
	The term "MIME decode" is used for both "encoded-word" decoding defined by <xref target="RFC2047" /> and
	MIME parameter value decoding defined by <xref target="RFC2231" />.
    </t>
  </section>

  <section title="Converting downgraded message headers for display" anchor="converting">
    <section title="Considerations" anchor="considerations">
      <t>
	The order of some header fields (such as "Resent-*" fields) is
	significant.  The process of regenerating the original fields
	from the downgraded ones MUST NOT reorder the fields.
      </t>
      <t>
	In order to regenerate a field from a specific downgraded
	header field, it's necessary to find the corresponding
	replacement in the current message.  If the corresponding
	field can not be found, the downgraded header field in
	question can not be regenerated and used.
      </t>
    </section>
    <section title="The process" anchor="process">
      <t>
	A MUA MAY decode and re-generate the original header fields of
	the message (MTAs and MDAs SHOULD NOT attempt to do this; it
	SHOULD be left to the MUA).  This procedure can be used to
	approximately reverse the Downgrade process, but it will not
	always construct the original header fields exactly.
      </t>
      <t>
	Three types of Downgraded header fields are described in section 3
	of <xref target="RFC5504" />:
    <list style="numbers">
	  <t>"Envelope Information Preservation Header Fields", described in RFC5504 section 3.1 and in <xref target="envelope-preservation"/>, below.</t>
	  <t>"Address Header Fields' Preservation Header Fields", described in RFC5504 section 3.2 and in <xref target="address-preservation"/>, below.</t>
	  <t>"Unknown Header Fields' Preservation Header Fields", described in RFC5504 section 3.3 and in <xref target="unknown-preservation"/>, below.</t>
	</list>
      </t>
      <t>
	After processing Downgraded header fields, decode all header fields, as described in <xref target="RFC2047"/> and <xref target="RFC2231"/>.
      </t>
      <section title="No reconstruction of the Envelope Information Preservation Header Fields" anchor="envelope-preservation">
	<t>
	  Envelope Information Preservation Header Fields are new
	  fields that might have been added by the downgrade process.
	  Because they do not represent fields that appeared in the
	  original message, this process is not applicable to them.
        </t>
      </section>
      <section title="Reconstructing the Address Header Fields' Preservation Header Fields" anchor="address-preservation">
	<t>
	  Reconstructing Address Header Fields' Preservation Header Fields is OPTIONAL, and
	  a decision MAY be made on each field, individually.  In particular, it might be less
	  important to process the Resent-* header fields, so an implementation MAY choose to
	  skip those.
	</t>
	<t>
	  To construct a displayable copy of a header field from one
	  of these downgraded header fields, follow this procedure:
          <list style="hanging">
	    <t hangText="1. ">
	      In an edit buffer, create a new header field:"
	    </t>
	    <t hangText="1a. ">
	      For the field name, remove the "Downgraded-" prefix from
	      the downgraded field name.  For example,
	      "Downgraded-From" becomes "From", and
	      "Downgraded-Resent-To" becomes "Resent-To".
	    </t>
	    <t hangText="1b. ">
	      For the field value, decode the MIME-encoded value of
	      the downgraded field according to <xref target="RFC2047"
	      />.
	    </t>
	    <t hangText="2. ">
	      If the header field is one that can only appear once,
	      according to the table in <xref target="RFC5322" />
	      section 3.6 ("From", "Sender", "To", "CC", "BCC",
	      "Reply-To"), locate the corresponding field in the
	      message's headers, and skip to step 9.  Otherwise,
	      continue with step 3.
	    </t>
	    <t hangText="3. ">
	      Apply "Email Header Fields Downgrading", defined in
	      section 5 of <xref target="RFC5504"/>, to the field in
	      the edit buffer, but do not prepend the "Downgraded-"
	      prefix.  Put the result into comparison buffer 1.
	    </t>
	    <t hangText="4. ">
	      Canonicalize the header fields in the comparison buffer:
	      <list style="numbers">
		<t>
		  Unfold all header field continuation lines as
		  described in <xref target="RFC5322" />.
		</t>
		<t>
		  Ensure that there is one space character before and
		  one after the <mailbox-list> separator ",".
		  If a space character is missing, insert one.
		</t>
		<t>
		  Ensure that there is one space character before and
		  one after each <comment>.  If a space character is
		  missing, insert one.
		</t>
		<t>
		  Decode each <encoded-word> whose charset is "UTF-8".
		</t>
		<t>
		  Convert all sequences of one or more WSP characters
		  to a single space character.  WSP characters here
		  include those before and after a line-folding
		  boundary.
		</t>
		<t>
		  Delete all WSP characters at the end of each unfolded header
		  field value.
		</t>
		<t>
		  Delete any WSP characters remaining before and after
		  the colon separating the header field name from the
		  header field value, retaining the colon separator.
		</t>
	      </list>
	    </t>
	    <t hangText="5. ">
	      Locate the first instance of the corresponding field in
	      the message's headers.
	    </t>
	    <t hangText="6. ">
	      Canonicalize the located field as in step 4, and put the result
	      into comparison buffer 2.
	    </t>
	    <t hangText="7. ">
	      Compare the header field in comparison buffer 1 with the header
	      field in comparison buffer 2.  If they match, go to step 9.
	    </t>
	    <t hangText="8. ">
	      Locate the next instance of the corresponding field in
	      the message's headers.  If one is found, go to step 6.
	      If none is found, stop: you can not use this downgraded
	      field because you can't find its replacement in the
	      message.
	    </t>
	    <t hangText="9. ">
	      Replace the located header field with the one in the edit buffer.
	      You MUST NOT reorder the header fields when you do this; it's
	      important to replace the field in place.
	    </t>
	  </list>
	</t>
      </section>
      <section title="The Unknown Header Fields' Preservation Header Fields" anchor="unknown-preservation">
	<t>
	  The Unknown Header Fields' Preservation Header Fields SHOULD be
	  left as they are unless the MUA has special knowledge of a particular field.
	  An MUA with such knowledge MAY use the procedure in <xref target="address-preservation"/>,
	  above, for those fields that it knows about.
    </t>
      </section>
    </section>
  </section>
  <section title="Security considerations" anchor="security">
    <t>
   While information in any email header should usually be treated with
   some suspicion, current email systems commonly employ various
   mechanisms and protocols to make the information more trustworthy.
   For example, an organization's boundary MTA can modify "From:" lines
   so that messages arriving from outside the organization are easily
   distinguishable from internal emails. As a result of that rewriting,
   it might not be possible to reconstruct the "Downgraded-From" header field.
	</t>
    <t>
   A MUA MAY emphasize bogus or broken Address Header Fields' Preservation Header Fields found in step 8 of
   <xref target="address-preservation" />.
    </t>
    <t>
   Hiding the information from the actual header fields when using the
   "Downgraded-" header fields does not cause loss of information if
   generating MIME decoded header fields in step 1
   of <xref target="address-preservation" />
   and
   the comparison done in step 8
   are successful.
   To ensure that no information is lost, a MUA
   SHOULD have a function that uses the actual message that was
   received (with/without MIME decoding) to render the message.
    </t>
    <t>
See "Security considerations" section in <xref target="RFC5504" /> and <xref target="RFC4952"/> for more discussion.
    </t>
  </section>

  <section title="IANA Considerations">
    <t>
This document makes no requests for IANA action. This section can be
removed by the RFC Editor before publication.
    </t>
  </section>

  <section title="Acknowledgements">
    <t>
	This document was separated from <xref target="RFC5504" />.
	Both documents were developed in the EAI WG.  Significant
	comments and suggestions were received from
	John Klensin, Harald Alvestrand, Chris Newman, Randall Gellens,
	Charles Lindsey, Marcos Sanz, Alexey Melnikov, Pasi Eronen,
	Frank Ellermann, Edward Lewis, S. Moonesamy and JET members.
    </t>
  </section>

  <section title="Change History">
    <t>
	This section is used for tracking the update of this document.  Will be
	removed after finalize.
    </t>
    <section title="draft-fujiwara-eai-downgraded-display: Version 00">
	<t>
	<list style="symbols">
	  <t>Initial version</t>
	  <t>It is separated from Appendix A of draft-ietf-eai-downgrade-05.txt</t>
	</list>
	</t>
    </section>
    <section title="draft-ietf-eai-downgraded-display: Version 00">
	<t>
	<list style="symbols">
	  <t>Submitted as a working group draft</t>
	</list>
	</t>
    </section>
    <section title="draft-ietf-eai-downgraded-display: Version 01">
	<t>
	<list style="symbols">
	  <t>Prohibited and removed Displaying Technique 1</t>
	  <t>Added new texts to Security Considerations</t>
	</list>
	</t>
    </section>
    <section title="draft-ietf-eai-downgraded-display: Version 02">
	<t>
	<list style="symbols">
	  <t>updated by comments from Chair's review and AD's review</t>
	  <t>Fixed references</t>
	  <t>Rewrote section 4 to be more comprehensible</t>
	  <t>Added bogus or broken "Downgraded-" header fields</t>
	  <t>Added sentences in Security considerations</t>
	</list>
	</t>
    </section>
    <section title="draft-ietf-eai-downgraded-display: Version 03">
	<t>
	<list style="symbols">
	  <t>Section 3 (formerly 3 and 4) was rewritten by Barry Leiba.</t>
	</list>
	</t>
    </section>
  </section>


</middle>

<back>
  <references title="Normative References">
	&rfc4952;
	&rfc5335;
	&rfc5504;
	&rfc2045;
	&rfc2047;
	&rfc2183;
	&rfc2231;
	&rfc5322;
	&rfc2119;
  </references>

  <references title="Informative References">
	&rfc5321;
	&rfc5336;
	&rfc5337;
  </references>

  <section title="Examples">
	<t>
	This section shows a example of displaying a downgraded message.
	First, an example of the original UTF8SMTP message and its downgraded message are
	shown. The example comes from "Example 1" of <xref target="RFC5504" /> and
	three header fields, "Unknown-Field", "Resent-From", and "Resent-To", are added.
	The example UTF8SMTP message is shown in <xref target="example-originaleaismtpsession" />.
	</t>
	<t>
	<figure title="Original message" anchor="example-originaleaismtpsession">
	  <artwork>
<![CDATA[
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: NON-ASCII-SUBJECT
Unknown-Field: NON-ASCII-Unknown
From: DISPLAY-local <NON-ASCII-local@example.com
 <ASCII-local@example.com>>
To: DISPLAY-remote1 <NON-ASCII-remote1@example.net
 <ASCII-remote1@example.net>>
Cc: DISPLAY-remote2 <NON-ASCII-remote2@example.org>
Resent-From: DISPLAY-remote1 <NON-ASCII-remote1@example.net
 <ASCII-remote1@example.net>>
Resent-To: DISPLAY-reto <NON-ASCII-reto@example.net
 <ASCII-reto@example.net>>
Date: DATE

MAIL_BODY
]]>
	  </artwork>
	</figure>
	</t>

	<t>
	Delivered downgraded message is shown in <xref target="example-headerconversiondowngrading" />.
	Return-Path header will be added by the final destination MTA.
	Some of Received: header fields may be added.
	<figure title="Downgraded message" anchor="example-headerconversiondowngrading">

	  <artwork>
<![CDATA[
Return-Path: <ASCII-local@example.com>
Received: ...
Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com_?=
 =?UTF-8?Q?<ASCII-local@example.com>>?=
Downgraded-Rcpt-To: =?UTF-8?Q?<NON-ASCII-remote1@example.net_?=
 =?UTF-8?Q?<ASCII-remote1@example.net>>?=
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?=
Downgraded-Unknown-Field: =?UTF-8?Q?NON-ASCII-Unknown?=
From: =?UTF-8?Q?DISPLAY-local?= <ASCII-local@example.com>
Downgraded-From: =?UTF-8?Q?DISPLAY-local_<NON-ASCII-local@example.com_?=
 =?UTF-8?Q?<ASCII-local@example.com>>?=
To: =?UTF-8?Q?DISPLAY-remote1?= <ASCII-remote1@example.net>
Downgraded-To: =?UTF-8?Q?DISPLAY-remote1_?=
 =?UTF-8?Q?<NON-ASCII-remote1@example.net_<ASCII-remote1@example.net>>?=
Cc: =?UTF-8?Q?DISPLAY-remote2?= Internationalized address
 =?UTF-8?Q?NON-ASCII-remote2@example.org?= removed:;
Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?=
 =?UTF-8?Q?<NON-ASCII-remote2@example.org>?=
Resent-From: =?UTF-8?Q?DISPLAY-remote1?= <ASCII-remote1@example.net>
Downgraded-Resent-From: =?UTF-8?Q?DISPLAY-remote1_?=
 =?UTF-8?Q?<NON-ASCII-remote1@example.net_<ASCII-remote1@example.net>>?=
Resent-To: =?UTF-8?Q?DISPLAY-reto?= <ASCII-reto@example.net>
Downgraded-Resent-To: =?UTF-8?Q?DISPLAY-reto_?=
 =?UTF-8?Q?<NON-ASCII-reto@example.net_<ASCII-reto@example.net>>?=
Date: DATE

MAIL_BODY
]]>
	  </artwork>
	</figure>
      </t>
      <t>
	<xref target="example-mimedecoded" /> shows MIME decoded message of
	<xref target="example-headerconversiondowngrading" />.
	The recipient can read the original From, To, Cc and Unknown-Field header fields as
	Downgraded-From, Downgraded-To, Downgraded-Cc and Downgraded-Unknown-Field header fields.
	<figure title="MIME decoded message" anchor="example-mimedecoded">
	  <artwork>
<![CDATA[
Return-Path: <ASCII-local@example.com>
Received: ...
Downgraded-Mail-From: <NON-ASCII-local@example.com
 <ASCII-local@example.com>>
Downgraded-Rcpt-To: <NON-ASCII-remote1@example.net
 <ASCII-remote1@example.net>>
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: NON-ASCII-SUBJECT
Downgraded-Unknown-Field: NON-ASCII-Unknown
From: DISPLAY-local <ASCII-local@example.com>
Downgraded-From: DISPLAY-local <NON-ASCII-local@example.com
 <ASCII-local@example.com>>
To: DISPLAY-remote1 <ASCII-remote1@example.net>
Downgraded-To: DISPLAY-remote1 <NON-ASCII-remote1@example.net
 <ASCII-remote1@example.net>>
Cc: DISPLAY-remote2 Internationalized address
 NON-ASCII-remote2@example.org removed:;
Downgraded-Cc: DISPLAY-remote2 <NON-ASCII-remote2@example.org>
Resent-From: DISPLAY-remote1 <ASCII-remote1@example.net>
Downgraded-Resent-From: DISPLAY-remote1
 <NON-ASCII-remote1@example.net <ASCII-remote1@example.net>>
Resent-To: DISPLAY-reto <ASCII-reto@example.net>
Downgraded-Resent-To: DISPLAY-reto
 <NON-ASCII-reto@example.net <ASCII-reto@example.net>>
Date: DATE

MAIL_BODY
]]>
	  </artwork>
	</figure>
<vspace blankLines="100"/>
      </t>
      <section title="Displaying example">
      <t>
	This example shows how to display the message in 
	<xref target="example-headerconversiondowngrading" />, above,
	using the process defined in <xref target="converting"/>.
	For simplicity, we will show the reconstruction of all the
	applicable fields at once.
      </t>
      <t>
    Selecting all Downgraded-* fields gives this:
      </t>
    <t>
	<figure title="Downgraded header fields" anchor="all-downgraded-fields">
	  <artwork>
<![CDATA[
Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com_?=
 =?UTF-8?Q?<ASCII-local@example.com>>?=
Downgraded-Rcpt-To: =?UTF-8?Q?<NON-ASCII-remote1@example.net_?=
 =?UTF-8?Q?<ASCII-remote1@example.net>>?=
Downgraded-Unknown-Field: =?UTF-8?Q?NON-ASCII-Unknown?=
Downgraded-From: =?UTF-8?Q?DISPLAY-local_<NON-ASCII-local@example.com_?=
 =?UTF-8?Q?<ASCII-local@example.com>>?=
Downgraded-To: =?UTF-8?Q?DISPLAY-remote1_?=
 =?UTF-8?Q?<NON-ASCII-remote1@example.net_<ASCII-remote1@example.net>>?=
Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?=
 =?UTF-8?Q?<NON-ASCII-remote2@example.org>?=
Downgraded-Resent-From: =?UTF-8?Q?DISPLAY-remote1_?=
 =?UTF-8?Q?<NON-ASCII-remote1@example.net_<ASCII-remote1@example.net>>?=
Downgraded-Resent-To: =?UTF-8?Q?DISPLAY-reto_?=
 =?UTF-8?Q?<NON-ASCII-reto@example.net_<ASCII-reto@example.net>>?=
]]>
	  </artwork>
	</figure>
	</t>
      <t>
    Two of the fields, Downgraded-Mail-From and Downgraded-Rcpt-To, are
    Envelope Information Preservation Header Fields, and will not be reconstructed.
    One field, Downgraded-Unknown-Field, is an Unknown Header Fields' Preservation
    Header Field, and will also not be reconstructed.  That leaves these to be
    reconstructed, the Address Header Fields' Preservation Header Fields:
      </t>
	<t>
	<figure title="Header fields for the reconstruction" anchor="step0">
	  <artwork>
<![CDATA[
Downgraded-From: =?UTF-8?Q?DISPLAY-local_<NON-ASCII-local@example.com_?=
 =?UTF-8?Q?<ASCII-local@example.com>>?=
Downgraded-To: =?UTF-8?Q?DISPLAY-remote1_?=
 =?UTF-8?Q?<NON-ASCII-remote1@example.net_<ASCII-remote1@example.net>>?=
Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?=
 =?UTF-8?Q?<NON-ASCII-remote2@example.org>?=
Downgraded-Resent-From: =?UTF-8?Q?DISPLAY-remote1_?=
 =?UTF-8?Q?<NON-ASCII-remote1@example.net_<ASCII-remote1@example.net>>?=
Downgraded-Resent-To: =?UTF-8?Q?DISPLAY-reto_?=
 =?UTF-8?Q?<NON-ASCII-reto@example.net_<ASCII-reto@example.net>>?=
]]>
	  </artwork>
	</figure>
	</t>
      <t>
	Now, perform Step 1, creating temporary fields.
      </t>
      <t>
	<figure title="Output of Step 1" anchor="step1">
	  <artwork>
<![CDATA[
From: DISPLAY-local <NON-ASCII-local@example.com
 <ASCII-local@example.com>>
To: DISPLAY-remote1 <NON-ASCII-remote1@example.net
 <ASCII-remote1@example.net>>
Cc: DISPLAY-remote2 <NON-ASCII-remote2@example.org>
Resent-From: DISPLAY-remote1
 <NON-ASCII-remote1@example.net <ASCII-remote1@example.net>>
Resent-To: DISPLAY-reto
 <NON-ASCII-reto@example.net <ASCII-reto@example.net>>
]]>
	  </artwork>
	</figure>
      </t>
	<t>
    In step 2, we set aside the "From", "To", and "Cc" fields, and continue to step 3
    with just "Resent-From" and "Resent-To" (the fields that may appear more than once).
    The fields we set aside will be picked up again later, in step 9.
	</t>
	<t>
	Perform Steps 3 and 4. The edit buffer contains re-generated ASCII header fields,
	canonicalized.
	</t>
      <t>
	<figure title="The edit buffer (output of Step 4)" anchor="step4">
	  <artwork>
<![CDATA[
Resent-From: =?UTF-8?Q?DISPLAY-remote1?= <ASCII-remote1@example.net>
Resent-To: =?UTF-8?Q?DISPLAY-reto?= <ASCII-reto@example.net>
]]>
	  </artwork>
	</figure>
      </t>

	<t>
	  Perform Steps 5 to 7, comparison, for each header field.  Both the Resent-From and
	  Resent-To fields will match, and we will proceed to step 9.  (Step 8, iteration,
	  does not apply in this example.
	</t>
	
	<t>
	  Perform step 9, replacing all applicable fields, without changing the order.  Then
	  do MIME decoding on everything, for display.
	</t>
      <t>
	<figure title="The final result" anchor="step9">
	  <artwork>
<![CDATA[
Return-Path: <ASCII-local@example.com>
Received: ...
Downgraded-Mail-From: <NON-ASCII-local@example.com
 <ASCII-local@example.com>>
Downgraded-Rcpt-To: <NON-ASCII-remote1@example.net>
 <ASCII-remote1@example.net>
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: NON-ASCII-SUBJECT
Downgraded-Unknown-Field: NON-ASCII-Unknown
From: DISPLAY-local <NON-ASCII-local@example.com
 <ASCII-local@example.com>>
To: DISPLAY-remote1 <NON-ASCII-remote1@example.net
 <ASCII-remote1@example.net>>
Cc: DISPLAY-remote2 <NON-ASCII-remote2@example.org>
Resent-From: DISPLAY-remote1 <NON-ASCII-remote1@example.net
 <ASCII-remote1@example.net>>
Resent-To: DISPLAY-reto <NON-ASCII-reto@example.net
 <ASCII-reto@example.net>>
Date: DATE
]]>
	  </artwork>
	</figure>
      </t>

      <t>
	As a result, in this simple example, some original header fields are now displayed in their
	original form.
	Differences between <xref target="example-originaleaismtpsession" /> and <xref target="step9" /> are Return-Path, Downgraded-Mail-From, Downgraded-Rcpt-To, and Downgraded-Unknown-Field.
      </t>

      </section>
    </section>

</back>

</rfc>