[EAI] example fix for draft-ietf-eai-downgrade-04

To: ima at ietf.org
Subject: [EAI] example fix for draft-ietf-eai-downgrade-04
From: fujiwara at jprs.co.jp
Date: Wed, 11 Jul 2007 13:47:35 +0900 (JST)
List-archive: <http://www1.ietf.org/pipermail/ima>
List-help: <mailto:ima-request@ietf.org?subject=help>
List-id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-post: <mailto:ima@ietf.org>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>

I missed updating exaples on downgrade-04 document.
Please check attached example fix for downgrade-04.

I'm working on text for the next version to respond to the list
discussion about trivial downgrading with a clarification.

changes from 04 to 05 will be:
  - fixed examples
    - ALT-ADDRESS parameter mistake
    - RFC2047(x) notation was changed to =?UTF-8?Q?x?=
  - Add "Trivial downgrading" inside "Implementation notes" section.

Regards,

--
Kazunori Fujiwara, JPRS

----------------------------------------------------------------------------
Appendix B.  Examples

B.1.  Downgrading example 1

   This section shows an SMTP Downgrading example.  Consider a
   downgradable mail message.
   o  The sender address is "NON-ASCII-FROM" which is non-ASCII address.
      Its ASCII alternative is "ASCII-FROM".
   o  The "To" address is "NON-ASCII-TO" which is non-ASCII address.
      Its ASCII alternative is "ASCII-TO".
   o  The "CC" address is non-ASCII address "NON-ASCII-CC" without
      alternative US-ASCII address.
   o  The Subject header is "NON-ASCII-SUBJECT" which contains non-ASCII
      characters.
   The example SMTP envelope/message is showin in Figure 3.


   MAIL From: <NON-ASCII-FROM> ALT-ADDRESS=ASCII-FROM
   RCPT TO: <NON-ASCII-TO> ALT-ADDRESS=ASCII-TO
   RCPT TO: <NON-ASCII-CC>
   -------------------------------------------------------------
   Message-Id: MESSAGE_ID
   Mime-Version: 1.0
   Content-Type: text/plain; charset="UTF-8"
   Content-Transfer-Encoding: 8bit
   Subject: NON-ASCII-SUBJECT
   From: <NON-ASCII-FROM <ASCII-FROM>>
   To: <NON-ASCII-TO <ASCII-TO>>
   CC: <NON-ASCII-CC>
   Date: DATE

   MAIL_BODY


              Figure 3: Original envelope/message (example 1)

   In this example, there are two SMTP recipients, one is To:, the other
   is CC:.  In this example, assume the Cc: recipient's MTA supports
   UTF8SMTP and the To: recipient's MTA does not support UTF8SMTP.  The
   SMTP downgrading treats To: session downgrading.  Figure 4 shows SMTP
   downgraded example.



MAIL From: <ASCII-FROM>
RCPT TO: <ASCII-TO>
-------------------------------------------------------------
Envelope-Downgraded: From: =?UTF-8?Q?=3CNON-ASCII-FROM=3E?= <ASCII-FROM>
Envelope-Downgraded: To: =?UTF-8?Q?=3CNON-ASCII-TO=3E?= <ASCII-TO>
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: NON-ASCII-SUBJECT
From: <NON-ASCII-FROM <ASCII-FROM>>
To: <NON-ASCII-TO <ASCII-TO>>
CC: <NON-ASCII-CC>
Date: DATE

MAIL_BODY


          Figure 4: SMTP Downgraded envelope/message (example 1)

   After SMTP downgrading, header fields downgrading is performed.

   Final downgraded message is shown in Figure 5.  Return-Path header
   will be added by the final destination MTA.


Return-Path: <ASCII-FROM>
Envelope-Downgraded: From: =?UTF-8?Q?=3CNON-ASCII-FROM=3E?= <ASCII-FROM>
Envelope-Downgraded: To: =?UTF-8?Q?=3CNON-ASCII-TO=3E?= <ASCII-TO>
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: From: =?UTF-8?Q?=3CNON-ASCII-FROM?= <ASCII-FROM>>
From: <ASCII-FROM>
Downgraded: To: =?UTF-8?Q?=3CNON-ASCII-TO?= <ASCII-TO>>
To: <ASCII-TO>
Downgraded: CC: =?UTF-8?Q?=3CNON-ASCII-CC=3E?=
CC: Internationalized address =?UTF-8?Q?NON-ASCII-CC?= removed:;
Date: DATE

MAIL_BODY


                 Figure 5: Downgraded message (example 1)

B.2.  Displaying example

   Figure 6 shows MIME decoded message of Figure 5.


   Return-Path: <ASCII-FROM>
   Envelope-Downgraded: From: <NON-ASCII-FROM> <ASCII-FROM>
   Envelope-Downgraded: To: <NON-ASCII-TO> <ASCII-TO>
   Message-Id: MESSAGE_ID
   Mime-Version: 1.0
   Content-Type: text/plain; charset="UTF-8"
   Content-Transfer-Encoding: 8bit
   Subject: NON-ASCII-SUBJECT
   Downgraded: From: <NON-ASCII-FROM <ASCII-FROM>>
   From: <ASCII-FROM>
   Downgraded: To: <NON-ASCII-TO <ASCII-TO>>
   To: <ASCII-TO>
   Downgraded: CC: <NON-ASCII-CC>
   CC: Internationalized address NON-ASCII-CC removed:;
   Date: DATE

   MAIL_BODY

                      Figure 6: MIME decoded message

B.2.1.  Displaying technique 1 example

   After removing 'Downgraded:' from decoded 'Downgraded:' header fields

   Return-Path: <ASCII-FROM>
   Envelope-Downgraded: From: <NON-ASCII-FROM> <ASCII-FROM>
   Envelope-Downgraded: To: <NON-ASCII-TO> <ASCII-TO>
   Message-Id: MESSAGE_ID
   Mime-Version: 1.0
   Content-Type: text/plain; charset="UTF-8"
   Content-Transfer-Encoding: 8bit
   Subject: NON-ASCII-SUBJECT
   From: <NON-ASCII-FROM <ASCII-FROM>>
   From: <ASCII-FROM>
   To: <NON-ASCII-TO <ASCII-TO>>
   To: <ASCII-TO>
   CC: <NON-ASCII-CC>
   CC: Internationalized address NON-ASCII-CC removed:;
   Date: DATE

   MAIL_BODY

                     Figure 7: Displaying technique 1

B.2.2.  Displaying technique 2 example

   This example shows displaying process of Appendix A.2 for Figure 5.

   First, check 'Downgraded:' header existence.

   Downgraded: From: <NON-ASCII-FROM <ASCII-FROM>>
   Downgraded: To: <NON-ASCII-TO <ASCII-TO>>
   Downgraded: CC: <NON-ASCII-CC>

   Figure 8: Displaying technique 2: selecting Downgraded header fields

   Apply header fields downgrading to the decoded header without re-
   generating Downgraded: header.

   From: <ASCII-FROM>
   To: <ASCII-TO>
   CC: Internationalized address =?UTF-8?Q?NON-ASCII-CC?= removed:;

    Figure 9: Displaying technique 2: downgraded decoded 'Downgraded:'

   Remove the header line which is the same with the downgraded line.
   If the headers contain [RFC2047] encoded part, decode it before
   comparison.

Return-Path: <ASCII-FROM>
Envelope-Downgraded: From: =?UTF-8?Q?=3CNON-ASCII-FROM=3E?= <ASCII-FROM>
Envelope-Downgraded: To: =?UTF-8?Q?=3CNON-ASCII-TO=3E?= <ASCII-TO>
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: From: <NON-ASCII-FROM <ASCII-FROM>>
Downgraded: To: <NON-ASCII-TO <ASCII-TO>>
Downgraded: CC: <NON-ASCII-CC <ASCII-CC>>
Date: DATE

MAIL_BODY

      Figure 10: Displaying technique 2: Removing duplicated headers


   Decode each 'Downgraded' header and replace it with its decoded
   header.  If each mail header has [RFC2047] encoded part and which
   encoding is "UTF-8", it is a downgraded header, so decode it.


   Return-Path: <ASCII-FROM>
   Envelope-Downgraded: From: <NON-ASCII-FROM> <ASCII-FROM>
   Envelope-Downgraded: To: <NON-ASCII-TO> <ASCII-TO>
   Message-Id: MESSAGE_ID
   Mime-Version: 1.0
   Content-Type: text/plain; charset="UTF-8"
   Content-Transfer-Encoding: 8bit
   Subject: UTF-8_SUBJECT
   From: <NON-ASCII-FROM <ASCII-FROM>>
   To: <NON-ASCII-TO <ASCII-TO>>
   CC: <NON-ASCII-CC <ASCII-CC>>
   Date: DATE

   MAIL_BODY


              Figure 11: Display technique 2: decoded message

   As a result, in this simple example, all original header fields are
   displayed in the original form.

B.3.  Downgrading example 2

   In many cases, the sender wants to use non-ASCII address, the
   recipient does not support UTF8SMTP and does not have non-ASCII
   address.
   o  The sender address is "NON-ASCII-FROM" which is non-ASCII address.
      Its ASCII alternative is "ASCII-FROM".
   o  The "To" address is "ASCII-TO" which is ASCII only.
   o  The Subject header is "NON-ASCII-SUBJECT" which contains non-ASCII
      characters.
   The second example envelope/message is shown in Figure 12.


   MAIL From: <NON-ASCII-FROM> ALT-ADDRESS=ASCII-FROM
   RCPT TO: <ASCII-TO>
   -------------------------------------------------------------
   Message-Id: MESSAGE_ID
   Mime-Version: 1.0
   Content-Type: text/plain; charset="UTF-8"
   Content-Transfer-Encoding: 8bit
   Subject: NON-ASCII-SUBJECT
   From: <NON-ASCII-FROM <ASCII-FROM>>
   To: <ASCII-TO>
   Date: DATE

   MAIL_BODY


                  Figure 12: Original message (example 2)

   In this example, SMTP session is downgradable.  Figure 13 shows SMTP
   downgraded envelope/message.



MAIL From: <ASCII-FROM>
RCPT TO: <ASCII-TO>
-------------------------------------------------------------
Envelope-Downgraded: From: =?UTF-8?Q?=3CNON-ASCII-FROM=3E?= <ASCII-FROM>
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: NON-ASCII-SUBJECT
From: <NON-ASCII-FROM <ASCII-FROM>>
To: <ASCII-TO>
Date: DATE

MAIL_BODY


          Figure 13: SMTP Downgraded envelope/message (example 2)

   After SMTP downgrading, header fields downgrading is performed.  The
   downgraded example is shown in Figure 14.


Return-Path: <ASCII-FROM>
Envelope-Downgraded: From: =?UTF-8?Q?=3CNON-ASCII-FROM=3E?= <ASCII-FROM>
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: From: =?UTF-8?Q?=3CNON-ASCII-FROM?= <ASCII-FROM>>
From: <ASCII-FROM>
To: <ASCII-TO>
Date: DATE

MAIL_BODY

                 Figure 14: Downgraded message (example 2)



_______________________________________________
IMA mailing list
IMA at ietf.org
https://www1.ietf.org/mailman/listinfo/ima

Prev by Date: [EAI] I-D ACTION:draft-ietf-eai-mailinglist-02.txt
Next by Date: Re: [EAI] FINAL POLL RESULTS on the "what MIME type" question
Previous by thread: [EAI] I-D ACTION:draft-ietf-eai-mailinglist-02.txt
Next by thread: [EAI] MIME type selection - finishing the process
Index(es):
- Date
- Thread

[EAI] example fix for draft-ietf-eai-downgrade-04

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.