Re: [EAI] Comments on draft-ietf-eai-imap-utf8-07
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [EAI] Comments on draft-ietf-eai-imap-utf8-07
> (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.
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. 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.
Now, section 3 (now section 4) will start with this:
4. "ACCEPT" UTF8 Subcapability
The "ACCEPT" UTF8 subcapability 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.
The old section 3.1 gets this change:
string sent by the client. When the IMAP server advertises the
"ACCEPT" UTF8 subcapability, it informs the client that it supports
native UTF-8 quoted-strings with the following syntax:
...and so on, for the other instances of "UTF8 capability".
References to "the UTF8=ALL capability" would similarly change to 'the
"ALL" UTF8 subcapability', and so on.
And we add this:
The "ACCEPT" UTF8 subcapability may be specified on its own, or
with any combination of other subcapabilities. It is implied
by the "ALL" and "ONLY" subcapabilities, and MAY be omitted in
the presence of one of those.
In '5. "APPEND" UTF8 Subcapability', we add this:
The "APPEND" UTF8 subcapability may be specified on its own, or
with any combination of other subcapabilities. It is implied
by the "ONLY" subcapability, and MAY be omitted in the presence
of "ONLY".
In '6. "USER" UTF8 Subcapability', we add this:
The "USER" UTF8 subcapability may be specified on its own, or
with any combination of other subcapabilities. It is not implied
by any of the other subcapabilities.
In '7. "ALL" UTF8 Subcapability', we add this:
The "ALL" UTF8 subcapability may be specified on its own, or
with any combination of other subcapabilities. It is implied
by the "ONLY" subcapability, and MAY be omitted in the presence
of "ONLY".
The "ALL" UTF8 subcapability implies the "ACCEPT" subcapability,
and "ACCEPT" MAY be omitted in the presence of "ALL".
In '8. "ONLY" UTF8 Subcapability', we add this:
The "ONLY" UTF8 subcapability may be specified on its own, or
with any combination of other subcapabilities. It implies the
"ACCEPT", "APPEND", and "ALL" subcapabilities, and those MAY
be omitted in the presence of "ONLY".
We might add examples, such as these:
UTF8=ACCEPT,USER,APPEND
UTF8=ACCEPT,ALL
UTF8=ALL ; Note, same as above
UTF8=ACCEPT,USER,APPEND,ALL,ONLY
UTF8=USER,ONLY ; Note, same as above
---
I think this makes everything clear and easy to parse.
Comments?
Barry
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.