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