draft-ietf-eai-downgrade-02.txt   draft-ietf-eai-downgrade-03.txt 
Email Address Internationalization Y. YONEYA, Ed. Email Address Internationalization Y. YONEYA, Ed.
(EAI) K. Fujiwara, Ed. (EAI) K. Fujiwara, Ed.
Internet-Draft JPRS Internet-Draft JPRS
Intended status: Experimental Aug 16, 2006 Intended status: Experimental Mar 5, 2007
Expires: February 17, 2007 Expires: September 6, 2007
Downgrading mechanism for Email Address Internationalization (EAI) Downgrading mechanism for Email Address Internationalization
draft-ietf-eai-downgrade-02.txt draft-ietf-eai-downgrade-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 17, 2007. This Internet-Draft will expire on September 6, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
Traditional mail systems handle only US-ASCII characters in SMTP Traditional mail systems handle only US-ASCII characters in SMTP
envelope and mail headers. The Email Address Internationalization envelope and mail header fields. The Email Address
(EAI) is implemented by allowing UTF-8 characters in SMTP envelope Internationalization is implemented by allowing UTF-8 characters in
and mail headers. To deliver Non-ASCII mail address through EAI SMTP envelope and mail header fields (UTF8SMTP). To deliver Non-
incompliant environment, some sort of converting mechanism (i.e. ASCII mail address via UTF8SMTP non-compliant environment, some sort
downgrading) is required. This document describes requirements for of converting mechanism (i.e. downgrading) is required. This
downgrading, SMTP Downgrading, SMTP DATA/Header Downgrading and document describes requirements for downgrading, SMTP downgrading,
implementation consideration. Email header downgrading and implementation consideration.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Downgrade Requirements . . . . . . . . . . . . . . . . . . . . 3 3. Downgrade Requirements . . . . . . . . . . . . . . . . . . . . 3
3.1. Timing and conditions of downgrading . . . . . . . . . . . 3 3.1. Timing and conditions of downgrading . . . . . . . . . . . 3
3.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
4. SMTP Downgrading . . . . . . . . . . . . . . . . . . . . . . . 4 4. Downgraded header . . . . . . . . . . . . . . . . . . . . . . 4
5. SMTP DATA/Header Downgrading . . . . . . . . . . . . . . . . . 5 5. SMTP Downgrading . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Header conversion . . . . . . . . . . . . . . . . . . . . 6 6. Email header Downgrading . . . . . . . . . . . . . . . . . . . 6
5.1.1. Downgrading address headers . . . . . . . . . . . . . 7 6.1. Downgrading address headers . . . . . . . . . . . . . . . 7
6. Implementation consideration . . . . . . . . . . . . . . . . . 8 7. Upgrading downgraded header . . . . . . . . . . . . . . . . . 7
6.1. MUA . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Implementation consideration . . . . . . . . . . . . . . . . . 8
7. Security considerations . . . . . . . . . . . . . . . . . . . 8 9. Security considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
10. Change History . . . . . . . . . . . . . . . . . . . . . . . . 8 12. Change History . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. draft-yoneya-ima-downgrade: Version 00 . . . . . . . . . . 8 12.1. draft-yoneya-ima-downgrade: Version 00 . . . . . . . . . . 9
10.2. draft-yoneya-ima-downgrade: Version 01 . . . . . . . . . . 9 12.2. draft-yoneya-ima-downgrade: Version 01 . . . . . . . . . . 9
10.3. draft-ietf-eai-downgrade: Version 00 . . . . . . . . . . . 9 12.3. draft-ietf-eai-downgrade: Version 00 . . . . . . . . . . . 9
10.4. draft-ietf-eai-downgrade: Version 01 . . . . . . . . . . . 9 12.4. draft-ietf-eai-downgrade: Version 01 . . . . . . . . . . . 9
10.5. draft-ietf-eai-downgrade: Version 02 . . . . . . . . . . . 9 12.5. draft-ietf-eai-downgrade: Version 02 . . . . . . . . . . . 9
11. Normative References . . . . . . . . . . . . . . . . . . . . . 9 12.6. draft-ietf-eai-downgrade: Version 03 . . . . . . . . . . . 9
13. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 10 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 10
A.1. SMTP Downgrading Example . . . . . . . . . . . . . . . . . 10 A.1. Downgrading example 1 . . . . . . . . . . . . . . . . . . 10
A.2. Header conversion downgrading example . . . . . . . . . . 12 A.2. Upgrading example . . . . . . . . . . . . . . . . . . . . 13
A.3. Header conversion upgrading example . . . . . . . . . . . 13 A.3. Downgrading example 2 . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18
1. Introduction 1. Introduction
Traditional mail systems which are defined by [RFC2821] and [RFC2822] Traditional mail systems which are defined by [RFC2821] and [RFC2822]
allow US-ASCII characters in SMTP envelope and mail headers in body allow US-ASCII characters in SMTP envelope and mail header field
part. The EAI proposal [I-D.ietf-eai-framework], bodies. The UTF8SMTP proposal [I-D.ietf-eai-framework],
[I-D.ietf-eai-utf8headers] and [I-D.ietf-eai-smtpext] allows UTF-8 [I-D.ietf-eai-utf8headers] and [I-D.ietf-eai-smtpext] allows UTF-8
characters in SMTP envelope and mail headers in body part. characters in SMTP envelope and mail header field bodies.
Carrying Non-ASCII mail address from sender to recipients requires Carrying Non-ASCII mail address from sender to recipients requires
all components on the mail delivery route are EAI compliant. all components on the mail delivery route are UTF8SMTP compliant.
Otherwise Non-ASCII mail address can't be delivered. To solve the Otherwise Non-ASCII mail address can't be delivered. To solve the
problem, this document describes downgrading mechanism that enables problem, this document describes downgrading mechanism that enables
delivering Non-ASCII mail address by converting it to corresponding delivering Non-ASCII mail address by converting it to corresponding
US-ASCII representation on current mail delivery system. Not only US-ASCII representation on current mail delivery system. Not only
SMTP envelope, but also UTF-8 characters in mail headers MUST be SMTP envelope, but also Non-ASCII characters in mail header fields
converted to US-ASCII. MUST be converted to US-ASCII.
Downgrading in EAI consists from following two parts: Downgrading in UTF8SMTP consists from following two parts:
o SMTP Downgrading o SMTP Downgrading
o SMTP DATA/Header Downgrading o Email header Downgrading
Decoding downgraded envelope/message is called 'Upgrading' in this Decoding downgraded envelope/message is called 'Upgrading' in this
document. Each downgrading mechanism has corresponding upgrading document. Each downgrading mechanism has corresponding upgrading
mechanism. mechanism.
In this document, requirements for downgrading is described in In this document, requirements for downgrading are described in
section Section 3, SMTP Downgrading is described in Section 4, and Section 3, SMTP Downgrading is described in Section 5, and Email
SMTP DATA/Header Downgrading is described in Section 5. header Downgrading is described in Section 6.
This document assumes that MIME headers are not extended to use UTF-8
characters because it is not clearly defined in
[I-D.ietf-eai-utf8headers].
2. Terminology 2. Terminology
Terminology for this document is defined in [I-D.ietf-eai-framework]. Terminology for this document is defined in [I-D.ietf-eai-framework].
3. Downgrade Requirements 3. Downgrade Requirements
3.1. Timing and conditions of downgrading 3.1. Timing and conditions of downgrading
Followings are timing and conditions of downgrading. Followings are timing and conditions of downgrading.
Timing: SMTP client detects that SMTP server doesn't support Timing: SMTP client detects that SMTP server doesn't support
"UTF8SMTP" option at EHLO. [I-D.ietf-eai-smtpext] "UTF8SMTP" option at EHLO. [I-D.ietf-eai-smtpext]
Conditions: SMTP client detects that UTF-8 is included in the SMTP Conditions: SMTP client detects that non-ASCII characters are
envelope or mail headers in the SMTP DATA. included in the SMTP envelope or mail header fields in the SMTP
DATA.
Note: If the UTF8SMTP header exists, downgrading will be performed.
If UTF-8 characters exist in mail headers without the UTF8SMTP
header, this is a protocol error, and handling of this situation is
outside the scope of this specification.
3.2. Requirements 3.2. Requirements
Followings are requirements of downgrading. Followings are requirements of downgrading.
1. Downgrading must be performed only once. 1. Downgrading should be performed only once.
2. Upgrading must be performed at minimized place such as final 2. "Upgrading MUST be performed (if at all) when it is known that a
destination like recipient MUA. subsequent downgrade will not be needed. This could mean that
the upgrading is delayed until the recipient MUA processes the
message."
3. Downgrading and upgrading must be automated. 3. Downgrading and upgrading must be automated.
4. Downgrading and upgrading should be easy and lightweight as it is 4. Downgrading and upgrading should be easy and lightweight as it is
possible to do with MTA like 8BITMIME encapsulation. possible to do with MTA like 8BITMIME encapsulation.
5. Downgrade and upgrade method must be defined clearly. 5. Downgrade and upgrade method must be defined clearly.
6. Downgrading and upgrading should preserve all header information. 6. Downgrading and upgrading should preserve all header information.
7. Downgrading must support SPF and DKIM. 7. Downgrading should support SPF and DKIM.
8. Downgrading occurrence must be recorded. 8. Downgrading occurrence should be recorded.
4. SMTP Downgrading 4. Downgraded header
Downgrading MUST be performed in each SMTP session. Target of To preserve all header information, new generic encapsulation header
downgrading elements in SMTP envelope are below: is required. The new header is required, and it is specified as
"Downgraded". It has two fields. The first field is the
encapsulated header name. The second field contains the encapsulated
header value which is encoded by [RFC2047] with UTF-8 tag. The
header field syntax is specified as follows:
fields =/ downgraded
downgraded = "Downgraded:" [CFWS] field-name ":" dvalue CRLF
field-name = 1*ftext
ftext = %d33-57 / %d59-126 ; printable ASCII except ":"
dvalue = 1*any-ascii
any-ascii = %d32-126
Any headers can be preserved in Downgraded: header. The "dvalue"
field is encoded by [RFC2047]. "Downgraded header decoding" means
that generating new header whose header name is "field-name" field
that retrieving preserved field-name and dvalue decoded by [RFC2047].
To preserve SMTP envelope downgraded information, another new header
is required, and it is specified as "Envelope-Downgraded". Details
are described in Section 5. The header field syntax is specified as
follows:
fields =/ edowngraded
edowngraded = "Envelope-Downgraded:" [CFWS] field-name ":" value CRLF
field-name = "From" / "To"
value = CFWS "<" uPath ">" CFWS "<" Mailbox ">" CFWS
; Mailbox is defined in RFC 2821, section 4.1.2
; uPath is defined in [I-D.ietf-eai-smtpext]
5. SMTP Downgrading
Downgrading MUST be performed for each SMTP recipient address.
Target of downgrading elements in SMTP envelope are below:
o MAIL FROM: o MAIL FROM:
o RCPT TO: o RCPT TO:
Downgrading in SMTP envelope uses ALT-ADDRESS parameter proposed in Downgrading in SMTP envelope uses ALT-ADDRESS parameter proposed in
[I-D.ietf-eai-smtpext]. An address is downgradable if the address is [I-D.ietf-eai-smtpext]. An address is downgradable if the address is
all-ASCII address or the address has all-ASCII address specified by US-ASCII address or the address has US-ASCII address specified by
ALT-ADDRESS parameter. ALT-ADDRESS parameter.
If the return address in the envelope ("MAIL FROM:") is not If the return address in the envelope ("MAIL FROM:") is not
downgradable, downgrading fails. downgradable, downgrading fails.
One SMTP session may contain multiple recipients. Downgrading SHOULD One SMTP session may contain multiple recipients. Downgrading SHOULD
be performed for each SMTP recipient address. First, split a be performed for each SMTP recipient address individually. First,
multiple recipients session to each sessions. If the recipient split a multiple recipients session to each sessions. If the
address is downgradable, the SMTP session to the recipient is recipient address is downgradable, the SMTP session to the recipient
downgradable. is downgradable.
When MUA/MTA is transferring mail and finding its envelope contains When MUA/MTA is transferring mail and finding its envelope contains
Non-ASCII addresses, it MUST decide to bounce or downgrade if Non-ASCII addresses, it MUST decide to bounce or downgrade if
receiving MTA is EAI incompliant. receiving MTA is UTF8SMTP non-compliant.
Even if no downgrading is performed for envelope from/to, MUA/MTA Even if no downgrading is performed for envelope from/to, MUA/MTA
MUST downgrade mail headers including UTF-8 or bounce. This is MUST downgrade mail header fields including non-ASCII characters or
described in next section. bounce. This is described in Section 6.
MTA replaces Non-ASCII mail address with specified alternative US- Downgrading MTA replaces Non-ASCII mail address with specified
ASCII address. Then appends replaced information with EAI- alternative US-ASCII address. Also MTA preserves original
Downgraded-From: and EAI-Downgraded-To: header in mail header information using "Envelope-Downgraded" header defined in Section 4
(outgoing SMTP DATA). with From or To field name.
EAI-Downgraded-From: <Non-ASCII {US-ASCII}> <US-ASCII> Envelope-Downgraded: From: <Non-ASCII-FROM> <US-ASCII-FROM>
EAI-Downgraded-To: <Non-ASCII {US-ASCII}> <US-ASCII> Envelope-Downgraded: To: <Non-ASCII-TO> <US-ASCII-TO>
Note that when downgrading, not to disclose whole recipient address, Note that when downgrading, not to disclose whole recipient address,
MUA/MTA SHOULD make SMTP connection per each recipient address. MUA/MTA SHOULD make SMTP connection per each recipient address.
Also note that by appending EAI-Downgraded-From/To: headers, MUA/MTA Also note that by appending "Envelope-Downgraded:" headers, MUA/MTA
MUST perform SMTP DATA/Header Downgrading. This is described in next MUST perform Email header Downgrading described in Section 6.
section.
Case study: SPF check
SPF checks domainname of the envelope from and SMTP connection IP
address. If ALT-ADDRESS domainname is Punycode/IDNA form of Non-
ASCII domainname, it will be compatible with current SPF. In this
case, SPF check will be performed correctly. Otherwise, more
detailed consideration is required.
NOTE: ORCPT NOTE: ORCPT
ESMTP ORCPT parameter is used for Delivery Status Notifications ESMTP ORCPT parameter is used for Delivery Status Notifications
(DSNs) [RFC3461]. ORCPT parameters contain mail addresses. After (DSNs) [RFC3461]. ORCPT parameters contain mail addresses. After
extending ORCPT parameter to support Non-ASCII mail addresses, ORCPT extending ORCPT parameter to support Non-ASCII mail addresses, ORCPT
parameter downgrading should be defined here. parameter downgrading should be defined here.
5. SMTP DATA/Header Downgrading Case study: SPF check
Target and non-target of downgrading elements in mail headers (SMTP
data) are below:
Originator address(es): Non-ASCII mail addresses in From:,
Reply-To:, Sender: and their Resent- headers MUST be target of
downgrading.
Destination address(es): Non-ASCII mail addresses in To:, CC:, Bcc:
and their Resent- headers MUST be target of downgrading.
IDs: IDs such as Message-ID:, Date:, In-Reply-To: and References:
MUST NOT be target of downgrading.
Trace headers: Received: headers MUST NOT be target of downgrading
because they do not contain Non-ASCII mail addresses.
other headers: UTF-8 in other headers MUST be target of downgrading. SPF checks domain name of the envelope from and SMTP connection IP
UTF8SMTP header: Identification of internationalized email header address. If ALT-ADDRESS domain name is Punycode/IDNA form of Non-
requires special consideration. ASCII domainname, it will be compatible with current SPF. In this
case, SPF check will be performed correctly. Otherwise, more
detailed consideration is required.
5.1. Header conversion 6. Email header Downgrading
This section defines conversion method to US-ASCII for each header This section defines conversion method to US-ASCII for each header
which may contain Non-ASCII characters. Each header has its own which may contain Non-ASCII characters. If the whole mail header
downgrading method. does not contain Non-ASCII characters, email header downgrading is
not required. Otherwise, email header downgrading checks each header
To preserve all header information, define generic encapsulation whether it contains UTF-8 characters or not. If the header contains
header: "Downgraded: HeaderName: HeaderValue". The header value is UTF-8 characters, convert the header in a suitable method for of each
encoded by [RFC2047] with UTF-8 tag. header. Each header's downgrading method is described below:
From, To, CC, Reply-To, Return-Path:
Downgrading: The header field body is composed of single or multiple angle-
* Check if the mail has 'UTF8SMTP' header and its value is addr/addr-spec fields defined in [I-D.ietf-eai-utf8headers].
"UTF8". Otherwise, downgrading is not required. If the header has no 'angle-addr' or 'utf8-addr-spec' which
* Check each header whether it contains UTF-8 characters or not. contains UTF-8 characters, only "display-name" part contains UTF-8
If the header contains UTF-8 characters, characters, encode the header by [RFC2047] with UTF-8 tag and
+ If the header is an address header which is described in replace it.
Section 5.1.1, Otherwise, preserve the header in "Downgraded:" header and
- Preserve the header in 'Downgraded' header. generate US-ASCII only header defined in Section 6.1, replace the
- Downgrade the header defined in Section 5.1.1. original header with the generated US-ASCII only header. When
+ The other header case, encode the header by [RFC2047] with this address header downgrading fails, this downgrading fails and
UTF-8 tag. the mail MUST be bounced.
* Change 'UTF8SMTP' header value to "Downgraded".
Upgrading:
* Check if the mail has 'UTF8SMTP' header and its value is
"Downgraded". Otherwise, upgrading is not required.
* Decode all 'Downgraded' headers.
+ Decode header value field string which is [RFC2047] encoded.
+ If the header is address header described in Section 5.1.1,
- Apply address header downgrading to the decoded header.
- Remove the header line which is the same with the
downgraded line.
+ Remove the 'Downgraded' header.
+ Add decoded header to mail header.
* If each mail header has [RFC2047] encoded part and which
encoding is "UTF-8", it is a downgraded header, so decode it.
* Change 'UTF8SMTP' header value to "UTF8".
Followings are pros and cons of this method.
Pros:
* EAI incompliant MUA displays the downgraded mail body except
original Non-ASCII mail addresses.
* EAI incompliant MUA displays and handles the sender specified Subject:
alternative address (ALT-ADDRESS). Encode the header by [RFC2047] with UTF-8 tag and replace it.
* EAI compliant MUA displays and handles original headers. Message-ID:, Date:, In-Reply-To:
Cons: "ID"s and "Date"s does not contain UTF-8 characters.
* Implementation and processing cost is not so easy and Received:
lightweight because MUA/MTA must parse each header and encode If the FOR clause contains UTF-8 addresses, the header must be
it by defined method. downgraded. In this case, preserve the header in "Downgraded:"
* Hard to preserve whole information AS IS. The address headers header and remove the FOR clause in the header.
are preserved but the other headers which is [RFC2047] encoded other headers:
with UTF-8 tag are not distinguished that it is downgraded or All other headers which contains UTF-8 characters are preserved in
it is encoded by sender's MUA. Also, restoration order of the Downgraded: header and removed.
downgraded headers is not guaranteed. Therefore, to check DKIM
requires special consideration.
[[Reference to [I-D.ietf-eai-scenarios] and evaluation of each case Downgraded headers should be inserted or replaced at the same
should be described here.]] position of the original header.
5.1.1. Downgrading address headers 6.1. Downgrading address headers
This section targets From:, Sender:, Reply-To:, To:, CC:, Bcc:, This procedure targets "From:", "To:", "CC:", "Reply-To:", "Return-
Resent-From:, Resent-To:, Resent-CC:, Resent-Bcc:, Resent-sender: Path:" headers which contains Originator/Destination address(es).
headers which contains Originator/Destination address(es). 1. Extract every field and downgrade each 'mailbox'/'angle-
addr'/'utf8-addr-spec'.
The header value is composed of single or multiple mailbox/angle-addr If the Non-ASCII address is in utf8-addr-spec form, then the
fields defined in [I-D.ietf-eai-utf8headers]. header downgrading fails because the form has no alt-address.
If the header contains UTF-8 characters, downgrading method is "mailbox" is defined as "DISPLAY NAME angle-addr" in
follows. [I-D.ietf-eai-utf8headers]. The "DISPLAY NAME" field should be
1. Extract every field and downgrade mailbox/angle-addr described encoded by [RFC2047] with UTF-8 tag, if necessary.
below.
2. By mailbox/angle-addr downgrading, if the field became empty, the
field should be removed.
3. If all header field is removed, remove the header.
4. If From header is removed, generate new From: header from
envelope-from address.
EAI angle-addr defined in [I-D.ietf-eai-utf8headers] consists of 3 UTF8SMTP angle-addr defined in [I-D.ietf-eai-utf8headers]
forms. Downgrading method is defined for each form. consists of 3 forms. Downgrading method is defined for each
form.
1. <US-ASCII> 1. <US-ASCII>
US-ASCII mail address case, preserve it. US-ASCII is used as is.
2. <Non-ASCII> 2. <Non-ASCII>
Non-ASCII mail address without ALT-ADDRESS parameter case, This email header downgrading fails because this header is
remove this angle-addr. not downgradable.
3. <Non-ASCII {US-ASCII}> 3. <Non-ASCII<US-ASCII>>
Non-ASCII mail address with sender-specified US-ASCII address Non-ASCII mail address with sender-specified US-ASCII address
case, replace it as <US-ASCII>. is replaced as <US-ASCII>.
"mailbox" is defined as "DISPLAY NAME angle-addr" in 7. Upgrading downgraded header
[I-D.ietf-eai-utf8headers]. The "DISPLAY NAME" field should be
encoded by [RFC2047] with UTF-8 tag, if necessary. If the angle-addr
is removed, remove the field including "DISPLAY NAME".
6. Implementation consideration Upgrading downgraded header is described below:
o Check if the mail header contains 'Downgraded:' headers.
Otherwise, upgrading is not required.
6.1. MUA o Perform "Downgraded header decoding" for each "Downgraded:"
headers and replace the 'Downgraded:' header with its decoded
header.
* If the decoded header is an address header described in
Section 6.1,
+ Generate ASCII only header described in Section 6.1 from the
decoded header.
+ Remove the header line which is the same with the generated
ASCII only header. (REQUIRE HEADER NORMALIZATION)
* If the decoded header is a "Received:" header,
+ Removing the 'FOR' clause from the decoded header generates
ASCII only header.
+ Remove the header line which is the same with the generated
header. (REQUIRE HEADER NORMALIZATION)
o If each mail header has [RFC2047] encoded part and which encoding
is "UTF-8", it may be a downgraded header, so decode it.
EAI compliant MUA MUST implement downgrading mechanism for sending. 8. Implementation consideration
UTF8SMTP compliant MUA MUST implement downgrading mechanism for
sending.
MUA MAY encode UTF-8 in Subject header with the same encoding of body MUA MAY encode UTF-8 in Subject header with the same encoding of body
part while downgrading. part while downgrading.
EAI compliant MUA MUST upgrade downgraded mail and MUST show Non- UTF8SMTP compliant MUA MUST upgrade downgraded mail and MUST show
ASCII mail addresses on display. Non-ASCII mail addresses on display.
7. Security considerations 9. Security considerations
See the extended security considerations discussion in See "Security considerations" section in [I-D.ietf-eai-framework] for
[I-D.ietf-eai-framework] more discussion.
8. IANA Considerations 10. IANA Considerations
IANA is requested to add the "EAI-Downgraded-From:", IANA is requested to add the "Envelope-Downgraded:", and
"EAI-Downgraded-To:" and "Downgraded:" new headers to the registry "Downgraded:" new headers to the registry with the entries pointing
with the entries pointing to this specification for its definition. to this specification for its definition.
9. Acknowledgements 11. Acknowledgements
John Klensin, Harald Alvestrand, Chris Newman, Charles Lindsey, John Klensin, Harald Alvestrand, Chris Newman, Charles Lindsey,
Marcos Sanz, Alexey Melnikov and JET members. Marcos Sanz, Alexey Melnikov and JET members.
10. Change History 12. Change History
This section is used for tracking the update of this document. Will This section is used for tracking the update of this document. Will
be removed after finalize. be removed after finalize.
10.1. draft-yoneya-ima-downgrade: Version 00 12.1. draft-yoneya-ima-downgrade: Version 00
o Initial version o Initial version
o Fllowed draft-yeh-ima-utf8headers-00 and draft-yao-smtpext-00 o Followed draft-yeh-ima-utf8headers-00 and draft-yao-smtpext-00
10.2. draft-yoneya-ima-downgrade: Version 01 12.2. draft-yoneya-ima-downgrade: Version 01
o Document structure was changed o Document structure was changed
o Fllowed draft-yeh-ima-utf8headers-01 and draft-yao-smtpext-02 o Followed draft-yeh-ima-utf8headers-01 and draft-yao-smtpext-02
o Downgrading requirements were added o Downgrading requirements were added
o SMTP DATA encapsulation method was proposed o SMTP DATA encapsulation method was proposed
o Downgrading examples was provided o Downgrading examples was provided
10.3. draft-ietf-eai-downgrade: Version 00 12.3. draft-ietf-eai-downgrade: Version 00
o Fllowed draft-yeh-ima-utf8headers-01 and draft-ietf-eai-smtpext-00 o Followed draft-yeh-ima-utf8headers-01 and
draft-ietf-eai-smtpext-00
o No header downgrading method was proposed o No header downgrading method was proposed
o Header encapsulation method was proposed o Header encapsulation method was proposed
10.4. draft-ietf-eai-downgrade: Version 01 12.4. draft-ietf-eai-downgrade: Version 01
o Followed draft-ietf-eai-utf8headers-00 o Followed draft-ietf-eai-utf8headers-00
o Header conversion and encapsulation method was merged o Header conversion and encapsulation method was merged
o Header conversion method was defined in detail o Header conversion method was defined in detail
10.5. draft-ietf-eai-downgrade: Version 02 12.5. draft-ietf-eai-downgrade: Version 02
o Followed draft-ietf-eai-utf8headers-01 and o Followed draft-ietf-eai-utf8headers-01 and
draft-ietf-eai-smtpext-01 draft-ietf-eai-smtpext-01
o Specification about algorithmic generated address is removed o Specification about algorithmic generated address is removed
o No header downgrading method was removed o No header downgrading method was removed
o SMTP DATA encapsulation method was removed o SMTP DATA encapsulation method was removed
11. Normative References 12.6. draft-ietf-eai-downgrade: Version 03
o Followed draft-ietf-eai-utf8headers-03 and
draft-ietf-eai-smtpext-03
o Downgraded: and Envelope-Downgraded: headers definition was added
o Mail header downgrading method was refined
o Examples in Appendix A were refined
13. Normative References
[I-D.ietf-eai-dsn]
Newman, C., "International Delivery and Disposition
Notifications", draft-ietf-eai-dsn-00 (work in progress),
January 2007.
[I-D.ietf-eai-framework] [I-D.ietf-eai-framework]
Klensin, J. and Y. Ko, "Overview and Framework for Klensin, J. and Y. Ko, "Overview and Framework for
Internationalized Email", draft-ietf-eai-framework-01 Internationalized Email", draft-ietf-eai-framework-05
(work in progress), June 2006. (work in progress), February 2007.
[I-D.ietf-eai-scenarios] [I-D.ietf-eai-scenarios]
Alvestrand, H., "UTF-8 Mail: Scenarios", Alvestrand, H., "UTF-8 Mail: Scenarios",
draft-ietf-eai-scenarios-01 (work in progress), June 2006. draft-ietf-eai-scenarios-01 (work in progress), June 2006.
[I-D.ietf-eai-smtpext] [I-D.ietf-eai-smtpext]
Yao, J. and W. Mao, "SMTP extension for internationalized Yao, J. and W. Mao, "SMTP extension for internationalized
email address", draft-ietf-eai-smtpext-01 (work in email address", draft-ietf-eai-smtpext-03 (work in
progress), July 2006. progress), February 2007.
[I-D.ietf-eai-utf8headers] [I-D.ietf-eai-utf8headers]
Yeh, J., "Internationalized Email Headers", Yeh, J., "Internationalized Email Headers",
draft-ietf-eai-utf8headers-01 (work in progress), draft-ietf-eai-utf8headers-03 (work in progress),
August 2006. March 2007.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text", Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996. RFC 2047, November 1996.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001. April 2001.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001. April 2001.
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
Extension for Delivery Status Notifications (DSNs)", Extension for Delivery Status Notifications (DSNs)",
RFC 3461, January 2003. RFC 3461, January 2003.
Appendix A. Examples Appendix A. Examples
A.1. SMTP Downgrading Example A.1. Downgrading example 1
This section shows a SMTP Downgrading example. Consider a This section shows a SMTP Downgrading example. Consider a
downgradable mail message. downgradable mail message.
o The sender address is "NON-ASCII-FROM" which is Non-ASCII address. o The sender address is "NON-ASCII-FROM" which is Non-ASCII address.
Its ASCII alternative is "ASCII-FROM". Its ASCII alternative is "ASCII-FROM".
o The "To" address is "NON-ASCII-TO" which is Non-ASCII address. o The "To" address is "NON-ASCII-TO" which is Non-ASCII address.
Its ASCII alternative is "ASCII-TO". Its ASCII alternative is "ASCII-TO".
o The "CC" address is "NON-ASCII-CC" which is Non-ASCII address. It o The "CC" address is "NON-ASCII-CC" which is Non-ASCII address.
has no ASCII alternative address. Its ASCII alternative address is "ASCII-CC".
o The Subject header is "UTF8-Subject" which contains Non-ASCII o The Subject header is "UTF8-SUBJECT" which contains Non-ASCII
characters. characters.
Original EAI message SMTP session Original UTF8SMTP message SMTP session
MAIL From: <NON-ASCII-FROM> ALT-ADDRESS <ASCII-FROM> MAIL From: <NON-ASCII-FROM> ALT-ADDRESS <ASCII-FROM>
RCPT TO: <NON-ASCII-TO> ALT-ADDRESS <ASCII-TO> RCPT TO: <NON-ASCII-TO> ALT-ADDRESS <ASCII-TO>
RCPT TO: <NON-ASCII-CC> RCPT TO: <NON-ASCII-CC> ALT-ADDRESS <ASCII-CC>
------------------------------------------------------------- -------------------------------------------------------------
UTF8SMTP: UTF8
Message-Id: MESSAGE_ID Message-Id: 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
Subject: UTF8-SUBJECT Subject: UTF8-SUBJECT
From: <NON-ASCII-FROM {ASCII-FROM}> From: <NON-ASCII-FROM<ASCII-FROM>>
To: <NON-ASCII-TO {ASCII-TO}> To: <NON-ASCII-TO<ASCII-TO>>
CC: <NON-ASCII-CC> CC: <NON-ASCII-CC<ASCII-CC>>
Date: DATE Date: DATE
MAIL_BODY MAIL_BODY
Figure 1: Original EAI message Figure 3: Original UTF8SMTP message
In this example, there are two sessions, one is To:, the other is In this example, there are two sessions, one is To:, the other is
CC:. The CC: session does not contain ASCII alternative address, it CC:. Both sessions are downgradable. Figure 4 shows To: session
is not downgradable and bounced. The To: session can be downgraded downgrading.
to the next example Figure 2.
After SMTP Downgrading After SMTP Downgrading
MAIL From: <ASCII-FROM> MAIL From: <ASCII-FROM>
RCPT TO: <ASCII-TO> RCPT TO: <ASCII-TO>
------------------------------------------------------------- -------------------------------------------------------------
EAI-Downgraded-From: <NON-ASCII-FROM {ASCII-FROM}> <ASCII-FROM> Envelope-Downgraded: From: <NON-ASCII-FROM> <ASCII-FROM>
EAI-Downgraded-To: <NON-ASCII-TO {ASCII-TO}> <ASCII-TO> Envelope-Downgraded: To: <NON-ASCII-TO> <ASCII-TO>
UTF8SMTP: UTF8
Message-Id: MESSAGE_ID Message-Id: 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
Subject: UTF8-SUBJECT Subject: UTF8-SUBJECT
From: <NON-ASCII-FROM {ASCII-FROM}> From: <NON-ASCII-FROM<ASCII-FROM>>
To: <NON-ASCII-TO {ASCII-TO}> To: <NON-ASCII-TO<ASCII-TO>>
CC: <NON-ASCII-CC> CC: <NON-ASCII-CC<ASCII-CC>>
Date: DATE
MAIL_BODY
Figure 2: SMTP Downgraded EAI message
A.2. Header conversion downgrading example
Original EAI message
UTF8SMTP: UTF8
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>
Date: DATE Date: DATE
MAIL_BODY MAIL_BODY
Figure 3: Original EAI message Figure 4: SMTP Downgraded UTF8SMTP message
SMTP Downgrading adds EAI-Downgraded-From: and EAI-Downgraded-To:
headers.
EAI-Downgraded-From: <Non-ASCII {DOWNGRADED_FROM}> <DOWNGRADED_FROM>
EAI-Downgraded-To: <Non-ASCII {DOWNGRADED_TO}> <DOWNGRADED_TO>
Figure 4: Headers added by SMTP Downgrading After SMTP downgrading, header downgrading is performed. Final
downgraded messages are shown in Figure 5.
Result of the header conversion downgrading. Result of the header downgrading.
EAI-Downgraded-From: Downgraded: Envelope-Downgraded: From:
MIME(<Non-ASCII {DOWNGRADED_FROM}) <DOWNGRADED_FROM> MIME(<NON-ASCII-FROM>) <ASCII-FROM>
EAI-Downgraded-To: Downgraded: Envelope-Downgraded: To:
MIME(<Non-ASCII {DOWNGRADED_TO}) <DOWNGRADED_TO> MIME(<NON-ASCII-TO>) <ASCII-TO>
UTF8SMTP: Downgraded
Message-Id: MESSAGE_ID Message-Id: 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
Subject: MIME(UTF-8_SUBJECT) Subject: MIME(UTF-8_SUBJECT)
Downgraded: From: MIME(<NON-ASCII-FROM {ASCII-FROM}>) Downgraded: From: MIME(<NON-ASCII-FROM<ASCII-FROM>>)
From: <ASCII-FROM> From: <ASCII-FROM>
Downgraded: To: MIME(<NON-ASCII-TO {ASCII-TO}>) Downgraded: To: MIME(<NON-ASCII-TO<ASCII-TO>>)
To: <ASCII-TO> To: <ASCII-TO>
Downgraded: CC: MIME(<NON-ASCII-CC>) Downgraded: CC: MIME(<NON-ASCII-CC<ASCII-CC>>)
To: <ASCII-CC>
Date: DATE Date: DATE
MAIL_BODY MAIL_BODY
Figure 5: Header downgraded message
Figure 5: Header conversion downgraded message
MIME() stands for [RFC2047] encoding. MIME() stands for [RFC2047] encoding.
A.3. Header conversion upgrading example A.2. Upgrading example
This example shows upgrading process of Figure 5. This example shows upgrading process of Figure 5.
First, check 'UTF8SMTP:' header. Its value is "Downgraded", it is First, check 'Downgraded:' header existence. The UTF8SMTP downgraded
EAI downgraded message. message has 'Downgraded:' headers.
Decode all 'Downgraded:' headers. Select 'Downgraded:' headers.
Downgraded: From: MIME(<NON-ASCII-FROM {ASCII-FROM}>) Downgraded: Envelope-Downgraded: From:
Downgraded: To: MIME(<NON-ASCII-TO {ASCII-TO}>) MIME(<NON-ASCII-FROM>) <ASCII-FROM>
Downgraded: CC: MIME(<NON-ASCII-CC>) Downgraded: Envelope-Downgraded: To:
MIME(<NON-ASCII-TO>) <ASCII-TO>
Downgraded: From: MIME(<NON-ASCII-FROM<ASCII-FROM>>)
Downgraded: To: MIME(<NON-ASCII-TO<ASCII-TO>>)
Downgraded: CC: MIME(<NON-ASCII-CC<ASCII-CC>>)
Figure 6: Upgrading: selecting Downgraded headers Figure 6: Upgrading: selecting Downgraded headers
Decode header value field string which is [RFC2047] encoded. This example has five Downgraded headers.
From: <NON-ASCII-FROM {ASCII-FROM}> Decode 'Downgraded:' headers.
To: <NON-ASCII-TO {ASCII-TO}>
CC: <NON-ASCII-CC> Envelope-Downgraded: From: <NON-ASCII-FROM> <ASCII-FROM>
Envelope-Downgraded: To: <NON-ASCII-TO> <ASCII-TO>
From: <NON-ASCII-FROM<ASCII-FROM>>
To: <NON-ASCII-TO<ASCII-TO>>
CC: <NON-ASCII-CC<ASCII-CC>>
Figure 7: Upgrading: upgraded Downgraded headers Figure 7: Upgrading: upgraded Downgraded headers
Apply address header downgrading to the decoded header. Apply address header downgrading to the decoded header.
From: <ASCII-FROM> From: <ASCII-FROM>
To: <ASCII-TO> To: <ASCII-TO>
CC: <ASCII-CC>
Figure 8: Upgrading: downgraded upgraded Downgraded headers Figure 8: Upgrading: downgraded upgraded Downgraded headers
Remove the header line which is the same with the downgraded line. Remove the header line which is the same with the downgraded line.
EAI-Downgraded-From: Downgraded: Envelope-Downgraded: From:
MIME(<Non-ASCII {DOWNGRADED_FROM}) <DOWNGRADED_FROM> MIME(<NON-ASCII-FROM>) <ASCII-FROM>
EAI-Downgraded-To: Downgraded: Envelope-Downgraded: To:
MIME(<Non-ASCII {DOWNGRADED_TO}) <DOWNGRADED_TO> MIME(<NON-ASCII-TO>) <ASCII-TO>
UTF8SMTP: Downgraded
Message-Id: MESSAGE_ID Message-Id: 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
Subject: MIME(UTF-8_SUBJECT) Subject: MIME(UTF-8_SUBJECT)
Downgraded: From: MIME(<NON-ASCII-FROM {ASCII-FROM}>) Downgraded: From: MIME(<NON-ASCII-FROM<ASCII-FROM>>)
Downgraded: To: MIME(<NON-ASCII-TO {ASCII-TO}>) Downgraded: To: MIME(<NON-ASCII-TO<ASCII-TO>>)
Downgraded: CC: MIME(<NON-ASCII-CC>) Downgraded: CC: MIME(<NON-ASCII-CC<ASCII-CC>>)
Date: DATE Date: DATE
MAIL_BODY MAIL_BODY
Figure 9: Upgrading: Removing duplicated headers Figure 9: Upgrading: Removing duplicated headers
Remove the 'Downgraded' header and add decoded Downgraded headers If Decode each 'Downgraded' header and replace it with its decoded
each mail header has [RFC2047] encoded part and which encoding is header. If each mail header has [RFC2047] encoded part and which
"UTF-8", it is a downgraded header, so decode it. Change 'UTF8SMTP' encoding is "UTF-8", it is a downgraded header, so decode it.
header value to "UTF8".
EAI-Downgraded-From: <Non-ASCII {DOWNGRADED_FROM}> <DOWNGRADED_FROM> Envelope-Downgraded: From: <NON-ASCII-FROM> <ASCII-FROM>
EAI-Downgraded-To: <Non-ASCII {DOWNGRADED_TO}> <DOWNGRADED_TO> Envelope-Downgraded: To: <NON-ASCII-TO> <ASCII-TO>
UTF8SMTP: UTF8
Message-Id: MESSAGE_ID Message-Id: 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
Subject: UTF-8_SUBJECT Subject: UTF-8_SUBJECT
From: <NON-ASCII-FROM {ASCII-FROM}> From: <NON-ASCII-FROM<ASCII-FROM>>
To: MIME(<NON-ASCII-TO {ASCII-TO}> To: <NON-ASCII-TO<ASCII-TO>>
CC: MIME(<NON-ASCII-CC> CC: <NON-ASCII-CC<ASCII-CC>>
Date: DATE Date: DATE
MAIL_BODY MAIL_BODY
Figure 10: Header conversion upgraded message Figure 10: Downgraded header upgraded message
As a result, in this example, all headers are preserved. As a result, in this simple example, all headers are preserved.
A.3. Downgrading example 2
In many cases, the sender wants to use Non-ASCII address and 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 "UTF8-SUBJECT" which contains Non-ASCII
characters.
Original UTF8SMTP message SMTP session
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: UTF8-SUBJECT
From: <NON-ASCII-FROM<ASCII-FROM>>
To: <ASCII-TO>
Date: DATE
MAIL_BODY
Figure 11: Original UTF8SMTP message 2
In this example, SMTP session is downgradable. Figure 12 shows SMTP
downgrading.
After SMTP Downgrading
MAIL From: <ASCII-FROM>
RCPT TO: <ASCII-TO>
-------------------------------------------------------------
Envelope-Downgraded: From: <NON-ASCII-FROM> <ASCII-FROM>
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: UTF8-SUBJECT
From: <NON-ASCII-FROM<ASCII-FROM>>
To: <ASCII-TO>
Date: DATE
MAIL_BODY
Figure 12: SMTP Downgraded UTF8SMTP message 2
After SMTP downgrading, header downgrading is performed. Final
downgraded messages are shown in Figure 13.
Result of the header downgrading.
Downgraded: Envelope-Downgraded: From:
MIME(<NON-ASCII-FROM>) <ASCII-FROM>
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: MIME(UTF-8_SUBJECT)
Downgraded: From: MIME(<NON-ASCII-FROM<ASCII-FROM>>)
From: <ASCII-FROM>
To: <ASCII-TO>
Date: DATE
MAIL_BODY
Figure 13: Header downgraded message 2
This downgraded message's header part contains ASCII characters only.
But it still contains MIME encapsulated subject header which contains
UTF-8 characters. And more, the body part contains UTF-8 message.
"ascii user" needs to accept UTF-8 mail body and UTF-8 subject which
is MIME encoded.
Authors' Addresses Authors' Addresses
Yoshiro YONEYA (editor) Yoshiro YONEYA (editor)
JPRS JPRS
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
skipping to change at page 17, line 7 skipping to change at page 18, line 7
JPRS JPRS
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@jprs.co.jp Email: fujiwara@jprs.co.jp
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 98 change blocks. 
305 lines changed or deleted 384 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/