Re: [EAI] Comments on draft-ietf-eai-imap-utf8-07

[Alexey Melnikov <[e-mail]>]

Barry Leiba wrote:

>>(As the responsible AD) After rereading various pieces of the document, I
>>agree this is not clear.
>>
>>
>>(As a WG participant) Here is my understanding how things should work:
>>
>>UTF8=USER is useful by itself, so I think it should be independent of all
>>other UTF8* capabilities. For example it should be possible to only support
>>UTF8=USER (non EAI IMAP server, but which accepts UTF-8
>>usernames/passwords), or support all other EAI functions, without supporting
>>UTF-8 username/password (e.g. a legacy authentication database).
>>
>>I think UTF8=APPEND should be independent of other UTF8* capabilities.
>>Allowing for EAI APPEND might require quite a bit of extra work.
>>
>>Both UTF8=ALL and UTF8=ONLY are related to UTF8 capability. We can either
>>define them as implying UTF8, or say that if one of them is advertised, then
>>UTF8 MUST also be advertised. Moreover, I think UTF8=ONLY implies UTF8=ALL.
>>One can also argue that UTF8=ONLY implies UTF8=APPEND. I would be Ok either
>>way, but one way or another this needs to be stated explicitly.
>>
[All my responses with either IMAP server or client implementor hat on:]

>The more I think about it, the more I think that having a "UTF8"
>capability string as well as "UTF8=xxx" strings creates a confusing
>situation, particularly when one or more of the others implies the
>former.
>
Agreed.
In fact, I think implied IMAP capabilities should be avoided.

>Here's what I suggest:
>
>Define the capability as "UTF8=x,y,z", where the bit after the "="
>(let's call them "UTF8 subcapabilities") can be some combination of
>ACCEPT, APPEND, USER, ALL, and ONLY.  Put this definition into a
>section that goes between the current sections 2 and 3, and say that
>the UTF8 subcapabilities are defined in the sections below, and that
>some of them may imply others.
>
>Note, too, that this does not extend the grammar for capability
>strings.  RFC 3501 defines "capability" to be "atom", and the ","
>character is permitted in an atom.  it may require a small tweak to
>the registry, though.
>  
>
This concerns me a bit. Existing IMAP capabilities are just single 
tokens (with the exception of RIGHTS= defined in RFC 4314), so they can 
be used for hash table lookups or direct string comparison. What you are 
suggesting is that we change that.

Note that the rest of your proposal seems sensible to me.