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

[Alexey Melnikov <[e-mail]>]

Hi Joseph,

Joseph Yee wrote:

> Inline
>
> On 2009-09-10, at 5:11 PM, Alexey Melnikov 
> <[e-mail]>  wrote:
>
>> Barry Leiba wrote:
>>
>>> Hi, Pete.
>>
>> Hi Barry,
>>
>>>>> OLD
>>>>> The UTF8=ONLY capability implies the UTF8 base capability, the
>>>>> UTF8=ALL capability and the UTF8=APPEND capability.  A server which
>>>>> advertises UTF8=ONLY need not advertise the three implicit
>>>>> capabilities.
>>>>>
>>>>> Oy.  This makes parsing the capability string complicated, and  
>>>>> should
>>>>> be earlier in the document.  It'd be good to make this clear at the
>>>>> beginning, when the UTF8 capability is first mentioned.
>>>>
>>>> I'm not sure what you want here. Something in the "UTF8" section  
>>>> that says,
>>>> "See below"? Left as is for now. Fix in an RFC Editor Note if need  
>>>> be.
>>>
>>> When one starts reading the document, one gets to this:
>>>
>>> ---------------------------------------------
>>> 3.  UTF8 IMAP Capability
>>>
>>>  The basic "UTF8" capability indicates the server supports UTF-8
>>>  quoted strings, the "UTF8" parameter to SELECT and EXAMINE, and  UTF-8
>>>  responses from the LIST and LSUB commands.
>>> ---------------------------------------------
>>>
>>> It's only later, when one gets to section 7, which I quote above,  that
>>> one finds that it's not sufficient to look for "UTF8": one also has  to
>>> look for "UTF8=ONLY".  And we don't say that UTF8=ALL, UTF8=APPEND,  or
>>> UTF8=USER imply the base UTF8.  So if UTF8=ONLY is special, I think  we
>>> need to say that right up there at the start of section 3, so it's
>>> clear.  Or else we say that the presence of *any* "UTF8=" capability
>>> implies the base UTF8, and say *that* in section 3, so it's clear
>>> right up front as to what capability string(s) need to be checked  for.
>>>
>>> D'you see what I'm getting at?
>>
>> (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 agree with the second part and that's my understanding of the doc.   
> Not sure of the first part.  Allowing UTF8 login/password but not 
> UTF8- IMAP capable?  I don't think we need special capa for it, it can 
> be  done today...

The base IMAP spec (RFC 3501) doesn't explicitly allow for UTF-8 
username/passwords. So a server supporting UTF-8 usernames/passwords 
needs to advertise it to the client.

I will double check this with the author of RFC 3501 though. RFC 5255 
states that in section 5.1, but I don't see any text in RFC 3501 on this.
If I am wrong on this, then the UTF-8=USER capability would need to be 
removed altogether.

>> I think UTF8=APPEND should be independent of other UTF8*  
>> capabilities. Allowing for EAI APPEND might require quite a bit of  
>> extra work.
>
> I personally think it can imply UTF8 but not any other UTF8-*.

I suppose that would be Ok as well. It is very unlikely that a server 
will only want to implement EAI APPEND, without wanting to implement the 
rest of EAI in IMAP.

> Not  sure if you mean the same from UTF8*
>
>> 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.
>
> Section 7 of the doc makes it clear that UTF8-ONLY implies both ALL  
> and APPEND.  I have not fully read -08 yet, is it not there anymore?

No, you are correct. I've missed the following paragraph which is quite 
clear on this:

   The UTF8=ONLY capability implies the UTF8 base capability, the
   UTF8=ALL capability and the UTF8=APPEND capability.  A server that
   advertises UTF8=ONLY need not advertise the three implicit
   capabilities.