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

[Chris Newman <[e-mail]>]

--On July 11, 2011 3:04:44 -0700 [e-mail] wrote:
> 	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

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