Subject: [EAI] I-D Action: draft-ietf-eai-5738bis-01.txt

From: [email-masked]
Date: Mon, 11 Jul 2011 03:04:44 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF.

	Title           : IMAP Support for UTF-8
	Author(s)       : Pete Resnick
                          Chris Newman
                          Sean Shen
	Filename        : draft-ietf-eai-5738bis-01.txt
	Pages           : 16
	Date            : 2011-07-11

   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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-eai-5738bis-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-eai-5738bis-01.txt

---

From: Chris Newman <[email-masked]>
Date: Thu, 28 Jul 2011 19:39:28 -0400

> 	Filename        : draft-ietf-eai-5738bis-01.txt

I re-read this and tried putting on my somewhat dusty "IMAP implementer 
hat" rather than my "protocol designer" hat. This unfortunately resulted in 
a lot of substantive issues :-(

There is one change I feel would be most helpful to make. I have learned 
that LIST extended is quite difficult to implement in a distributed server 
deployment and I believe that requirement will be a barrier to deployment 
of this extension. I suggest the document be changed so that the UTF8 LIST 
selection and return options can be used without requiring full 
implementation of the LIST extended extension. If the working group has 
rough consensus to go this direction, then I can provide the ABNF and text 
so that capability can be provided with or without the LIST extended 
extension.

This benefits servers because servers that make simpler implementation 
choices (such as UTF-8-only mailboxes) would no longer be forced to 
implement the entire LIST extended structure to allow interoperability. It 
also removes a "conditional" from the client (the code the client uses 
presently has to be different based on the presence of the LIST-EXTENDED 
capability).

I then subsequently asked myself what features could be removed from this 
document while keeping the document sufficiently complete. There are three 
options here:

1. Remove the "UTF8=USER" capability. Since there's no password change or 
account creation command in IMAP, this information is not strictly 
necessary for clients. UTF-8 usernames and passwords will either work or 
not based on the identity subsystem. The client doesn't have to know, so 
unless there's a client that really needs to know for some reason, this 
should probably be removed just to make the protocol less cluttered. The 
same could be done for POP3, FYI.

2. Remove the up-conversion requirements. The goal was to make it simpler 
for clients by allowing clients without 2047/2231 to work sooner. But this 
might be an additional barrier to server implementers, especially now that 
down-conversion has become more prominent than in the previous model. I'm 
thinking the deployment concern may be more important now than the hope of 
a protocol-designer to get rid of the ugly encodings sooner.

3. Remove the UTF8=APPEND capability. This is a direct server-implementer 
vs. client-implementer tradeoff. Not having that capability and requiring 
servers to support this in any mailbox that supports SELECT/EXAMINE UTF8 
makes things simpler and more predictable for clients, but at the expense 
of the server implementer. In hindsight, I think this is one where the 
server implementers should suffer to make things easier for the clients and 
to make the protocol look simpler.

And yes, you can be annoyed at me proposing simplifications/changes that 
remove things I put into the original document several years ago ;-) But I 
must admit that working in the more constrained post-bubble environment has 
given me a greater respect and attention to the nuances of simplicity.

Note that I did not see any technical errors in the current document, so if 
the WG decided to ignore my guilt-in-hindsight-for-unnecessary-complexity, 
I would not object to publishing the current document. But I do think it 
could be made more deployable and that is a significant concern. I'd really 
appreciate if others spoke up on this topic.

		- Chris

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 31 Jul 2011 21:28:18 -0400

Hi Chris,

Chris Newman wrote:
> I re-read this and tried putting on my somewhat dusty "IMAP 
> implementer hat" rather than my "protocol designer" hat. This 
> unfortunately resulted in a lot of substantive issues :-(
>
> There is one change I feel would be most helpful to make. I have 
> learned that LIST extended is quite difficult to implement in a 
> distributed server deployment and I believe that requirement will be a 
> barrier to deployment of this extension. I suggest the document be 
> changed so that the UTF8 LIST selection and return options can be used 
> without requiring full implementation of the LIST extended extension. 
> If the working group has rough consensus to go this direction, then I 
> can provide the ABNF and text so that capability can be provided with 
> or without the LIST extended extension.
>
> implement the entire LIST extended structure to allow 
> interoperability. It also removes a "conditional" from the client (the 
> code the client uses presently has to be different based on the 
> presence of the LIST-EXTENDED capability).
I might be agreeable to this change, but I would like to see a bit more 
details before unconditionally supporting it. Can you suggest some 
text/show an example on how this would look like?
> I then subsequently asked myself what features could be removed from 
> this document while keeping the document sufficiently complete. There 
> are three options here:
>
> 1. Remove the "UTF8=USER" capability. Since there's no password change 
> or account creation command in IMAP, this information is not strictly 
> necessary for clients. UTF-8 usernames and passwords will either work 
> or not based on the identity subsystem.
I tend to agree.
> The client doesn't have to know, so unless there's a client that 
> really needs to know for some reason, this should probably be removed 
> just to make the protocol less cluttered. The same could be done for 
> POP3, FYI.
Base IMAP (RFC 3501) doesn't require support for non-ASCII usernames. In 
practice I suspect that many server implementations are ignoring the 
"ASCII-only" restriction and that UTF-8 usernames are just going to work.

I am undecided on whether this capability should be removed or not.  I 
think it is basically advertising whether the identity subsystem 
supports non-ASCII usernames/passwords or not, so adding advertisement 
of this capability if a particular identity subsystem is compliant 
should be easy.
If we are going to remove this capability, I would like to at least have 
a SHOULD about supporting UTF-8 username/passwords. As email addresses 
are frequently used as IMAP usernames, this can even be a MUST.
> 2. Remove the up-conversion requirements. The goal was to make it 
> simpler for clients by allowing clients without 2047/2231 to work 
> sooner. But this might be an additional barrier to server 
> implementers, especially now that down-conversion has become more 
> prominent than in the previous model. I'm thinking the deployment 
> concern may be more important now than the hope of a protocol-designer 
> to get rid of the ugly encodings sooner.
+1.
> 3. Remove the UTF8=APPEND capability. This is a direct 
> server-implementer vs. client-implementer tradeoff. Not having that 
> capability and requiring servers to support this in any mailbox that 
> supports SELECT/EXAMINE UTF8 makes things simpler and more predictable 
> for clients, but at the expense of the server implementer. In 
> hindsight, I think this is one where the server implementers should 
> suffer to make things easier for the clients and to make the protocol 
> look simpler.
Just to clarify: are you saying that this functionality should always be 
supported by compliant servers? If yes, do you also propose to remove 
the UTF-8 signaling in the APPEND command?
> And yes, you can be annoyed at me proposing simplifications/changes 
> that remove things I put into the original document several years ago 
> ;-) But I must admit that working in the more constrained post-bubble 
> environment has given me a greater respect and attention to the 
> nuances of simplicity.
>
> Note that I did not see any technical errors in the current document, 
> so if the WG decided to ignore my 
> guilt-in-hindsight-for-unnecessary-complexity, I would not object to 
> publishing the current document. But I do think it could be made more 
> deployable and that is a significant concern. I'd really appreciate if 
> others spoke up on this topic.