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

[Joseph Yee <[e-mail]>]

On 11-Sep-09, at 6:04 AM, Alexey Melnikov wrote:

> 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.

Maybe we need to reword the last paragraph at section 7.  Saying  
something like UTF8=ONLY "covers" or "is superset of " functions UTF8,  
UTF8=ALL and UTF8=APPEND.

>
>> 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.

I would prefer to keep with style defined so far for IMAP, but I don't  
mind either way.

Best,
Joseph


>
> _______________________________________________
> IMA mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ima