rfc-editor | 4 Mar 2010 02:26
Favicon

RFC 5738 on IMAP Support for UTF-8


A new Request for Comments is now available in online RFC libraries.

        
        RFC 5738

        Title:      IMAP Support for UTF-8 
        Author:     P. Resnick, C. Newman
        Status:     Experimental
        Date:       March 2010
        Mailbox:    presnick <at> qualcomm.com, 
                    chris.newman <at> sun.com
        Pages:      15
        Characters: 32061
        Updates:    RFC3501

        I-D Tag:    draft-ietf-eai-imap-utf8-09.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5738.txt

This specification extends the Internet Message Access Protocol
version 4rev1 (IMAP4rev1) to support UTF-8 encoded international
characters in user names, mail addresses, and message headers.  
This document defines an Experimental Protocol for the Internet
community.

This document is a product of the Email Address Internationalization Working Group of the IETF.

EXPERIMENTAL: This memo defines an Experimental Protocol for the
Internet community.  It does not specify an Internet standard of any
(Continue reading)

Alexey Melnikov | 8 Mar 2010 00:17
Favicon

Design team to propose what to do with EAI Downgrade

Greetings,
This is a belated announcement that after consulting with EAI chairs 
I've formed a design team (as defined in Section 6.5 of RFC 2418) to 
propose a plan of what to do with EAI Downgrade. Several people I talked 
to thought that that decision is a prerequisite for rechartering the WG.

I am hoping that the design team is going to announce its proposal 
before Anaheim. The plan is to discuss the proposal on the mailing list 
first and see if the WG can reach an agreement on it. We will also have 
some time allocated for further discussions of the proposal during the 
face-to-face meeting in Anaheim.

Best Regards,
Alexey, as an Area Director.
Martin J. Dürst | 8 Mar 2010 08:03
Picon
Gravatar

Re: mailto: escaping

Hello Shawn,

I'm not sure I ever replied to your mail. I think your comments were 
partially directed at draft-duerst-mailto-bis and partially at 
draft-ietf-eai-mailto.

On 2009/07/14 7:27, Shawn Steele wrote:
> I didn't see any discussion of my mailto: comments.
>
> I think that it's good for the mailto: doc to provide escaping of the UTF-8 code points, however I also think
that many clients will be quite liberal in what they allow.  (Safari&  IE on Windows already seem to allow
mailto:café(at)example.org and I don't see any reason to break that)

The escaping is provided as part of the URI definition, because URIs 
don't take anything else than US-ASCII. If escaping is based on UTF-8, 
then the scheme automatically qualifies to be used with IRIs, and 
therefore you can automatically use cafe(at)éxample.org (note the 
position of the é, more on that below) under draft-duerst-mailto-bis as 
an IRI.

As for café(at)example.org or café(at)éxample.org, 
draft-duerst-mailto-bis doesn't allow that, because it addresses all the 
pre-EAI I18N stuff. But there is already some forward-compatible text in 
draft-duerst-mailto-bis:

 >>>>
    5. Percent-encoding of non-ASCII octets in the <local-part> of an
       <addr-spec> is reserved for the internationalization of the
       <local-part>. Non-ASCII characters MUST first be encoded
       according to UTF-8 , and then each octet of the corresponding
(Continue reading)

Shawn Steele | 8 Mar 2010 21:13
Picon
Favicon

Re: mailto: escaping

Somebody'd replied, at least I remember the key point: IRI vs URI :)

Thanks,

-Shawn

-----Original Message-----
From: "Martin J. Dürst" [mailto:duerst <at> it.aoyama.ac.jp] 
Sent: Lāpule, Malaki 07, 2010 11:03 PM
To: Shawn Steele
Cc: ima <at> ietf.org
Subject: Re: [EAI] mailto: escaping

Hello Shawn,

I'm not sure I ever replied to your mail. I think your comments were partially directed at
draft-duerst-mailto-bis and partially at draft-ietf-eai-mailto.

On 2009/07/14 7:27, Shawn Steele wrote:
> I didn't see any discussion of my mailto: comments.
>
> I think that it's good for the mailto: doc to provide escaping of the 
> UTF-8 code points, however I also think that many clients will be 
> quite liberal in what they allow.  (Safari&  IE on Windows already 
> seem to allow mailto:café(at)example.org and I don't see any reason to 
> break that)

The escaping is provided as part of the URI definition, because URIs don't take anything else than
US-ASCII. If escaping is based on UTF-8, then the scheme automatically qualifies to be used with IRIs, and
therefore you can automatically use cafe(at)éxample.org (note the position of the é, more on that
(Continue reading)

YAO Jiankang | 16 Mar 2010 07:45
Picon

Downgrade Design Team Discussion Results Released

Dear all,

   The design team has several jabber meetings and reached a conclusion.
With the permission from co-chairs, I send the Design Team Discussion Results to WG for review and comments.
We will discuss this result and hope to get some consensus for downgrade during our meeting in Anaheim.
any comments are welcome.

below is the Design Team Discussion Results: (or see the attachment)
------------------------------------------------------------------------------
The EAI Downgrade Design Team was created to investigate the
problems around EAI downgrade.  The Design Team's conclusion is
that downgrade should be removed from the core docs.  This
allows the EAI WG to focus on moving the core RFCs to standards
track immediately, without being blocked by downgrade.
Alternatives to downgrade have been discussed, but the Design
Team recommends any further work be restricted to a
MUA/submission protocol independent of the core transmission
documents.

For precision, the terminology used in this document is
summarized at its end. 

The goal of the EAI Downgrade Design Team was to unblock the
discussion of downgrade to enable progress on the EAI
standards.  A key factor is a strong desire to move the core
documents to standards track.  Extensive debate of downgrade
could obstruct the rest of EAI for the foreseeable future.

The EAI Downgrade Design Team reached this conclusion by
examining the results of the current downgrade experiment and
(Continue reading)

Shawn Steele | 16 Mar 2010 20:43
Picon
Favicon

Re: Downgrade Design Team Discussion Results Released

Yippee, when can we expect an updated draft of a new charter then?

-Shawn

----------------------------------------------------------------------

Message: 1
Date: Tue, 16 Mar 2010 14:45:22 +0800
From: "YAO Jiankang" <yaojk <at> cnnic.cn>
Subject: [EAI] Downgrade Design Team Discussion Results Released
To: <ima <at> ietf.org>
Message-ID: <468721920.28140 <at> cnnic.cn>
Content-Type: text/plain; charset="iso-8859-1"

Dear all,

   The design team has several jabber meetings and reached a conclusion.
With the permission from co-chairs, I send the Design Team Discussion Results to WG for review and comments.
We will discuss this result and hope to get some consensus for downgrade during our meeting in Anaheim.
any comments are welcome.

below is the Design Team Discussion Results: (or see the attachment)
------------------------------------------------------------------------------
The EAI Downgrade Design Team was created to investigate the problems around EAI downgrade.  The Design
Team's conclusion is that downgrade should be removed from the core docs.  This allows the EAI WG to focus on
moving the core RFCs to standards track immediately, without being blocked by downgrade.
Alternatives to downgrade have been discussed, but the Design Team recommends any further work be
restricted to a MUA/submission protocol independent of the core transmission documents.

For precision, the terminology used in this document is summarized at its end. 
(Continue reading)

James Rinker | 16 Mar 2010 20:56
Picon
Favicon

Re: Downgrade Design Team Discussion Results Released

And let me introduce myself, finally, by saying it's great to finally see some daylight for taking the core
docs forward. :)

James Rinker
Microsoft
Exchange Server

-----Original Message-----
From: ima-bounces <at> ietf.org [mailto:ima-bounces <at> ietf.org] On Behalf Of Shawn Steele
Sent: Tuesday, March 16, 2010 12:43 PM
To: ima <at> ietf.org
Subject: Re: [EAI] Downgrade Design Team Discussion Results Released

Yippee, when can we expect an updated draft of a new charter then?

-Shawn

----------------------------------------------------------------------

Message: 1
Date: Tue, 16 Mar 2010 14:45:22 +0800
From: "YAO Jiankang" <yaojk <at> cnnic.cn>
Subject: [EAI] Downgrade Design Team Discussion Results Released
To: <ima <at> ietf.org>
Message-ID: <468721920.28140 <at> cnnic.cn>
Content-Type: text/plain; charset="iso-8859-1"

Dear all,

   The design team has several jabber meetings and reached a conclusion.
(Continue reading)

YAO Jiankang | 17 Mar 2010 08:32
Picon

EAI Agenda for IETF 77 in Anaheim

Dear all,
 
  The EAI agenda for IETF 77 is released, pls take a look.
 
 
 
 
Jiankang Yao
------------------------------------------------------------------------------

------------------------------------------------------------------------------------
Email Address Internationalization (EAI) WG meeting in Anaheim
 
Meeting: IETF77, Monday, March 22,2010,  1740-1940
Place: Room Huntington, Hilton, Anaheim, CA, USA
Chairs: Harald Alvestrand <harald <at> alvestrand.no>, Xiaodong Lee lee <at> cnnic.cn
 
=====================================================
1740 - Scribe, blue sheet, agenda bashing
 
1750 - Documents status update
 
  draft-ietf-eai-pop                           RFC 5721
  draft-ietf-eai-imap-utf8                     RFC 5738   
  draft-ietf-eai-downgraded-display            RFC Ed Queue
  draft-ietf-eai-mailinglist                   AD Evaluation
 
1800 - Downgrade discussion 
  Downgrade Design Team (DDT) membership introduction
  DDT results introduction
  DDT results discussion
  Downgrade summary or conclusion
 
1910 - New charter discussion
 
   The proposed charter is below
 
1940 - meeting adjourn
 
 

-------------------------------------------------------
Description of Working Group:
The email address has two parts, local part and domain part. The email address internationalization
needs to deal with them. This working group's previous experimental efforts investigated the
use of UTF-8 as a general approach to email internationalization.
That approach is based on the use of an SMTP extension to enable
both the use of UTF-8 in envelope address local-parts and optionally
in domain-parts and the use of UTF-8 in mail headers -- both in
address contexts and wherever encoded-words are permitted today.
Other protocols were similarly extended.
 
This working group has finished all of its deliverables under the original charter.
Several of the WG's experimental RFCs based on UTF8SMTP extension have been proven
during the experimental phase and now need to be moved to standards
track.  The WG recommends the "no fallback" approach which will remove the alt-address and
recognizes that "no fallback" provides a very minimal transition mechanism, however we feel
 that "no fallback" is better than allowing downgrade to block further progress.
 Discoverable fallback addresses may be investigated independently of the core documents as non-standards track.
 Any such work would be an optional MUA/submission protocol, independent of the core transport documents.
Additionally there are some other areas which may require more effort to make the smooth operation of internationalized email address. 
 
 
Deliverables
 
The following deliverables are foreseen in this charter. The
WG chairs may (re)structure the deliverables into specific
documents or document sets as needed. Adding or removing
documents outside of these deliverables will require a charter
update.
*Overview and Framework for Internationalized Email(info/standard)
*UTF-8 SMTP extension specification (Standard)
* Header format specification (Standard)
* UTF-8 POP specification (Standard)
* UTF-8 IMAP specification (Standard)
 

Additional possible documents suggested:
* Advice for MUA implementors (Info)
*Advice for EAI deployment (info)
* Advice for non-ASCII and ASCII addresses for the same mailbox (Info)
* Mailinglist(info)
* Mailto(info)
 
Goals and Milestones:
Mar. 2010  Discussion of Recharter for standards track
May. 2010  New charter approval from IESG
June 2010  EAI Framework to IESG
July 2010   Headers & DSN (Standards) to IESG
July 2010   SMTP (Standard) to IESG
Aug. 2010   IMAP & POP3 (Standard) to IESG
Sep. 2010   Advice for non-ASCII & ASCII addresses (Info) to IESG
Oct. 2010   Advice for MUA implementors (Info) to IESG
Oct. 2010   Advice for EAI deployment (info) to IESG
Oct. 2010   Mailinglist (info) to IESG
Oct. 2010   Mailto(info) to IESG
_______________________________________________
IMA mailing list
IMA <at> ietf.org
https://www.ietf.org/mailman/listinfo/ima
RFC Errata System | 17 Mar 2010 10:26
Favicon

[Editorial Errata Reported] RFC5738 (2075)


The following errata report has been submitted for RFC5738,
"IMAP Support for UTF-8".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5738&eid=2075

--------------------------------------
Type: Editorial
Reported by: Alfred Hoenes <ah <at> TR-Sys.de>

Section: 4, 3rd para

Original Text
-------------
   IMAP servers that do not advertise the "UTF8=APPEND" or "UTF8=ONLY"
|  capability SHOULD reject an APPEND command that includes any 8-bit in
|  the message headers with a "NO" response.

Corrected Text
--------------
   IMAP servers that do not advertise the "UTF8=APPEND" or "UTF8=ONLY"
|  capability SHOULD reject an APPEND command that includes any 8-bit
|  character in message header fields with a "NO" response.

or:

   IMAP servers that do not advertise the "UTF8=APPEND" or "UTF8=ONLY"
|  capability SHOULD reject an APPEND command that includes any 8-bit
|  character in a message header with a "NO" response.

Notes
-----
Rationale: improved language and precise terminology

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5738 (draft-ietf-eai-imap-utf8-09)
--------------------------------------
Title               : IMAP Support for UTF-8
Publication Date    : March 2010
Author(s)           : P. Resnick, C. Newman
Category            : EXPERIMENTAL
Source              : Email Address Internationalization
Area                : Applications
Stream              : IETF
Verifying Party     : IESG
RFC Errata System | 17 Mar 2010 10:35
Favicon

[Editorial Errata Reported] RFC5738 (2076)


The following errata report has been submitted for RFC5738,
"IMAP Support for UTF-8".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5738&eid=2076

--------------------------------------
Type: Editorial
Reported by: Alfred Hoenes <ah <at> TR-Sys.de>

Section: 8, 4th para

Original Text
-------------
|  Up-conversion of MIME header encoding of the following headers MUST
   also be implemented: Subject, Date ([RFC5322] comments only),
   Comments, Keywords, and Content-Description.

Corrected Text
--------------
|  Up-conversion of MIME header encoding of the following header fields
   MUST also be implemented: Subject, Date ([RFC5322] comments only),
   Comments, Keywords, and Content-Description.

Notes
-----
Rationale: precise use of IETF standard terminology.

Note:  Further nits in this RFC (keep for update):

-  Section 5, last line

      ... Section 2.3 of SASLprep RFC 4013 [RFC4013].

   should better say: 

      ... Section 2.3 of SASLprep (RFC 4013 [RFC4013]).

-  Section 10 (2 instances):

      This adds ...

   should better say:

      This RFC adds ...

-  Section 12.1 -- unexpected line break in Ref. [RFC2231] :

   [RFC2231]  Freed, N. and K. Moore, "MIME Parameter Value and Encoded
              Word Extensions:
              Character Sets, Languages, and Continuations", RFC 2231,
              November 1997.

   should say:

   [RFC2231]  Freed, N. and K. Moore, "MIME Parameter Value and Encoded
              Word Extensions: Character Sets, Languages, and
              Continuations", RFC 2231, November 1997.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5738 (draft-ietf-eai-imap-utf8-09)
--------------------------------------
Title               : IMAP Support for UTF-8
Publication Date    : March 2010
Author(s)           : P. Resnick, C. Newman
Category            : EXPERIMENTAL
Source              : Email Address Internationalization
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

Gmane