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

[John C Klensin <klensin at jck.com>]

FWIW, I agree with Barry's analysis and like this solution.

   john


--On Thursday, September 10, 2009 18:50 -0400 Barry Leiba
<barryleiba.mailing.lists at gmail.com> 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.
> 
> 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
> _______________________________________________
> IMA mailing list
> IMA at ietf.org
> https://www.ietf.org/mailman/listinfo/ima