 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
On 11-Sep-09, at 6:04 AM, Alexey Melnikov wrote:
Barry Leiba wrote:[All my responses with either IMAP server or client implementor hat on:](As the responsible AD) After rereading various pieces of the document, Iagree 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 supportUTF8=USER (non EAI IMAP server, but which accepts UTF-8usernames/passwords), or support all other EAI functions, without supportingUTF-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 eitherway, but one way or another this needs to be stated explicitly.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.
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.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.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 IMA at ietf.org https://www.ietf.org/mailman/listinfo/ima