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

From: Barry Leiba <[email-masked]>
Date: Tue, 1 Sep 2009 10:25:28 -0400

I have a few comments in addition to SM's -- they're all editorial,
but I think most of them are important.  On the other hand, the
document's technically sound, and ready to go in that regard.

----------------------------

Throughout:
It's customary to use "that", rather than "which", to introduce
restrictive clauses.  It's not *wrong* to use "which", but it reads
badly to this editor's eye, and it invites confusion with
non-restrictive clauses, which must use "which" (like this one).

Examples:
pg 4
OLD
   MUST reject octet sequences with the high bit set which fail to
NEW
   MUST reject octet sequences with the high bit set that fail to

OLD
   All IMAP servers SHOULD accept UTF-8 in mailbox names and IMAP
   servers which support the "Mailbox International Naming Convention"
NEW
   All IMAP servers SHOULD accept UTF-8 in mailbox names and IMAP
   servers that support the "Mailbox International Naming Convention"

Etc.

----------------------------

pg 4

OLD
   If the UTF8 capability is advertised, then utf8-quoted syntax MAY be
   used with any IMAP argument that permits a string or an astring.
NEW
   If the server advertises the UTF8 capability, the client MAY use
   utf8-quoted syntax with any IMAP argument that permits a string.

The old text isn't clear about who advertises and who uses, and that
should be made clear.  Also, "string" is the operative part of the
definition of "astring", so the latter doesn't need to be specified
here.  If it is, we also need to list "nstring".  Better to leave them
both off.  Alternatively, "...permits a string (including astring and
nstring)" would be OK.

----------------------------

pg 4

OLD
   All IMAP servers SHOULD accept UTF-8 in mailbox names and IMAP
   servers which support the "Mailbox International Naming Convention"
   described in RFC 3501 section 5.1.3 MUST accept utf8-quoted mailbox
   names and convert them to the appropriate internal format.
NEW
   All IMAP servers that advertise the UTF8 capability SHOULD accept
   UTF-8 in mailbox names, and those that also support the "Mailbox
   International Naming Convention" described in RFC 3501 section 5.1.3
   MUST accept utf8-quoted mailbox names and convert them to the
   appropriate internal format.

If this change isn't correct, that means that I don't understand what
this paragraph is trying to say, and so it should be made clearer
anyway.

----------------------------

pg 4

OLD
   Mailbox
   names must comply with the Net-Unicode Definition (section 2 of
   [RFC5198]) with the specific exception that they may not contain
   control characters (0000-001F, 0080-009F), delete (007F), line
   separator (2028) or paragraph separator (2029).
NEW
   Mailbox
   names MUST comply with the Net-Unicode Definition (section 2 of
   [RFC5198]) with the specific exception that they MAY NOT contain
   control characters (0000-001F, 0080-009F), delete (007F), line
   separator (2028) or paragraph separator (2029).

It looks like we should be using RFC 2119 words here.

----------------------------

pg 4

OLD
   If an IMAP client issues a SEARCH command which uses a mixture of
   utf8-quoted syntax and a SEARCH CHARSET other than UTF-8, then the
   IMAP server SHOULD reject the command with a BAD response (due to the
   conflicting charset labels).
NEW
   An IMAP client MUST NOT issue a SEARCH command that uses a mixture of
   utf8-quoted syntax and a SEARCH CHARSET other than UTF-8.  If an IMAP
   server receives such a SEARCH command, it SHOULD reject the command
   with a BAD response (due to the conflicting charset labels).

Make it clear whose fault this is, and actively tell the client what
it mayn't do.

----------------------------

pg 5

OLD
     utf8-select-param = "UTF8"
                                           ;; Conforms to
<select-param> from RFC 4466
NEW
     utf8-select-param = "UTF8"
        ;; Conforms to <select-param> from RFC 4466

(Scrunch it up a bit...)

----------------------------

pg 7

OLD
   Specifically, SELECT and EXAMINE with the UTF8 parameter will never
   fail with a [NOT-UTF-8] response token.
NEW
   Specifically, SELECT and EXAMINE with the UTF8 parameter will never
   fail with a [NOT-UTF-8] response code.

----------------------------

pg 8

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.

----------------------------

pg 8/9

There seems to be a conflict between these two paragraphs:

   Server implementations also SHOULD up-convert all MIME body headers,
   SHOULD up-convert or remove the deprecated (and misused) name
   parameter [RFC1341] on Content-Type and MUST up-convert the Content-
   Disposition filename parameter.  These parameters can be encoded
   using the standard MIME parameter encoding [RFC2231] mechanism, or
   via non-standard use of MIME header encoding [RFC2047] in quoted
   strings.

   The IMAP server MUST NOT perform up-conversion of headers and content
   of multipart/signed, as well as Original-Recipient and Return-Path.

Isn't it possible to have a subpart of a multipart/signed message that
has a Content-Disposition header with a "filename" parameter?  If so,
the first graph says you MUST up-convert it, and the second says you
MUST NOT.

Also, I'd prefer putting the parameter names in quotes: "name"
parameter ... "filename" parameter.

----------------------------

pg 9

OLD
   7-bit downgrading to help comply with the standards are discussed in
   Downgrading mechanism for Internationalized eMail Address (IMA)
   [RFC5504].
NEW
   7-bit downgrading to help comply with the standards are discussed in
   "Downgrading Mechanism for Email Address Internationalization"
   [RFC5504].

----------------------------

I note for the record that the reference to the obsolete RFC 1341 is
intentional.  I wonder, though, whether it really ought to be
normative.  Hm.

----------------------------

That's it...
Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 01 Sep 2009 22:56:08 +0100

Hi Barry,
Thank you for your review.

My comments with my individual participant hat on:

>document's technically sound, and ready to go in that regard.
I would leave this to RFC Editors. They always fix that.

Agreed.

I agree with you.

Yes. David Black (GenArt) already spotted this.

Agree.

Indeed, "response code" is the proper RFC 3501 term.

Agreed.

[...]

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 02 Sep 2009 22:46:26 +0100

Hi Barry,

>the first graph says you MUST up-convert it, and the second says you
Right. I think the intent is for the second quoted paragraph to override 
the first.
So I think the first sentence of the first quoted paragraph should end 
with something like:

 ... and MUST up-convert the Content- Disposition filename parameter,
unless it is located inside a multipart/signed body part (see below).

>parameter ... "filename" parameter.
Yes, this would be better.
  [...]

It sounds normative. But I don't know if such parameters can be found in 
the wild in sufficient quantities to worry about anyway.

---

From: Pete Resnick <[email-masked]>
Date: Thu, 3 Sep 2009 15:28:15 -0500

On 8/30/09 at 10:46 PM -0700, SM wrote:

>The Abstract section mentions that "this is an early draft and 
>intended as a framework for discussion.  Please do not deploy 
>implementations of this draft."

Removed.

>In Section 3.3:
>
>   "Instead, the server MUST return any mailbox names with characters
>    outside the US-ASCII repertorie using utf8-quoted syntax."
>
>There is a typo for "repertoire".

Fixed.

Thanks SM.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Pete Resnick <[email-masked]>
Date: Thu, 3 Sep 2009 15:29:29 -0500

>I would leave this to RFC Editors. They always fix that.

It turned out easy to fix, so I did so, except for the last 
occurrence of "which", which did not need to be fixed.

Fixed.

>>this paragraph is trying to say, and so it should be made clearer

Changed as suggested.

>Yes. David Black (GenArt) already spotted this.

Changed to MUST NOT.

>>Make it clear whose fault this is, and actively tell the client what

Changed as suggested.

Fixed.

Fixed.

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

>Right. I think the intent is for the second quoted paragraph to 
>override the first.
>So I think the first sentence of the first quoted paragraph should 
>end with something like:
>

Fixed accordingly.

>Yes, this would be better.

Done.

>>    "Downgrading Mechanism for Email Address Internationalization"

Done.

>It sounds normative. But I don't know if such parameters can be 
>found in the wild in sufficient quantities to worry about anyway.

No change unless someone says otherwise.

Thanks Barry (and Alexey).

pr

---

From: Barry Leiba <[email-masked]>
Date: Thu, 3 Sep 2009 18:18:36 -0400

Hi, Pete.

> 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?

Barry

---

From: Joseph Yee <[email-masked]>
Date: Fri, 4 Sep 2009 17:55:43 -0400

Let me try...

I think it's down to whether ENABLE UTF8 enables everything in section  
4,5,6.7, or we need to write ENABLE UTF8=APPEND, ENABLE UTF8=ALL, etc.

And from my own understanding, UTF8=ALL is superset of UTF8, so it is
UTF8=ONLY implies {UTF8=ALL, UTF8=APPEND}
UTF8=ALL implies UTF8
UTF8=APPEND is not clear on UTF8, but can be
UTF8=USER is info on SASL, but can imply UTF8

I think specifying the following should do..

UTF8=ONLY -->  {UTF8=ALL, UTF8=APPEND, No m-UTF7}    [This is clear  
from the doc]
UTF8=ALL --> {UTF8}    [This is clear]
UTF8=APPEND --> {UTF8}
UTF8=USER --> {UTF8}  [USER is not something client can enable anyway]

Joseph

On 3-Sep-09, at 6:18 PM, Barry Leiba wrote:

> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 10 Sep 2009 22:11:44 +0100

Hi Barry,

>When one starts reading the document, one gets to this:
(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.

Comments?

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 10 Sep 2009 22:20:08 +0100

Hi Joseph,
Your message and the message from Barry prompted me to review this in 
more details. See my reply to Barry's message.

I will just comment on your statement about the ENABLE command:

Joseph Yee wrote:

> Let me try...
>
> I think it's down to whether ENABLE UTF8 enables everything in 
> section  4,5,6.7, or we need to write ENABLE UTF8=APPEND, ENABLE 
> UTF8=ALL, etc.

Well, there is no need for the client to call ENABLE for every extension 
it uses, although doing so wouldn't be an error. See RFC 5161 for more 
details.

---

From: Joseph Yee <[email-masked]>
Date: Thu, 10 Sep 2009 17:30:51 -0400

Inline

On 2009-09-10, at 5:11 PM, Alexey Melnikov <[email-masked]>  
wrote:

> (As the responsible AD) After rereading various pieces of the  
> document, I agree this is not clear.
>
>
> 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...

>
> 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-*. Not  
sure if you mean the same from UTF8*

> 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?

Thanks
Joseph

---

From: Joseph Yee <[email-masked]>
Date: Thu, 10 Sep 2009 17:37:15 -0400

Which I think is better, thanks Alexey

best,
Joseph

Sent from my iPhone

On 2009-09-10, at 5:20 PM, Alexey Melnikov <[email-masked]>  
wrote:

> Hi Joseph,
> Your message and the message from Barry prompted me to review this  
> in more details. See my reply to Barry's message.
>
> Well, there is no need for the client to call ENABLE for every  
> extension it uses, although doing so wouldn't be an error. See RFC  
> 5161 for more details.
>

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 10 Sep 2009 22:55:05 +0100

Hi Joseph,

Joseph Yee wrote:

> Inline
>
> On 2009-09-10, at 5:11 PM, Alexey Melnikov 
> <[email-masked]>  wrote:
>
>> Barry Leiba wrote:
>>
>>> Hi, Pete.
>>
>> Hi Barry,
>>
>>>>> OLD
> 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 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*
>

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.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 10 Sep 2009 18:50:09 -0400

> (As the responsible AD) After rereading various pieces of the document, I
> agree this is not clear.
>
>
> 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).
>
> 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

---

From: John C Klensin <[email-masked]>
Date: Thu, 10 Sep 2009 20:33:57 -0400

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

   john

--On Thursday, September 10, 2009 18:50 -0400 Barry Leiba
<[email-masked]> wrote:

>> 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).
>> 
>> 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
> 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.
> 
> 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.
> 
>    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.
> 
>    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:
> 
> 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.
> 
> 
>    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".
> 
>    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.
> 
>    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".
> 
>    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".
>

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 11 Sep 2009 11:04:45 +0100

>>way, but one way or another this needs to be stated explicitly.
[All my responses with either IMAP server or client implementor hat on:]

>former.
Agreed.
In fact, I think implied IMAP capabilities should be avoided.

>Here's what I suggest:
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.

Note that the rest of your proposal seems sensible to me.

---

From: Joseph Yee <[email-masked]>
Date: Thu, 17 Sep 2009 09:24:11 -0400

On 11-Sep-09, at 6:04 AM, Alexey Melnikov wrote:

>>> of all
>>> supporting
>>> either

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.

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

I would prefer to keep with style defined so far for IMAP, but I don't  
mind either way.

Best,
Joseph

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 20 Sep 2009 20:55:08 +0200

My sense of the WG is that the WG doesn't feel that being creative in 
how IMAP options are specified is something this WG wants.

Let's stay with UTF8=keyword tokens, and make sure we have documented 
what implies what.

                  Harald, with his WG chair hat on.

---

From: Barry Leiba <[email-masked]>
Date: Sun, 20 Sep 2009 17:09:38 -0400

> My sense of the WG is that the WG doesn't feel that being creative in how
> IMAP options are specified is something this WG wants.

Hm.  I don't read that at all, from the few responses we have.  That
said, I'm happy to accommodate:
I propose that we take my previous note, with all the changes
suggested in it, but we modify the way the capabilities are specified.
 Instead of "UTF8=x,y,z", we have "UTF8=x UTF8=y UTF8=z".  In
particular, that means that there is no "UTF8" capability, and that is
instead called "UTF8=ACCEPT".

That should satisfy me, John, and Dave, as well as making Alexey and
Joseph feel better.

Is that cool?

Barry

---

From: Pete Resnick <[email-masked]>
Date: Sun, 20 Sep 2009 16:46:25 -0500

The document editor remains agnostic on these issues and waits for a 
consensus call from the chair.

pr

On 9/20/09 at 5:09 PM -0400, Barry Leiba wrote:

>>My sense of the WG is that the WG doesn't feel that being creative 
>>in how IMAP options are specified is something this WG wants.
>
>particular, that means that there is no "UTF8" capability, and that 
>is instead called "UTF8=ACCEPT".
>

---

From: Joseph Yee <[email-masked]>
Date: Mon, 21 Sep 2009 14:00:26 -0400

On 20-Sep-09, at 5:09 PM, Barry Leiba wrote:

>> in how
Barry,

I feel good either way :)

I guess what's left is to document (or not to document) all  
implications.

Joseph

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 21 Sep 2009 23:12:35 +0400

> That should satisfy me, John, and Dave, as well as making Alexey and

Works for me.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 22 Sep 2009 19:26:03 +0200

>> That should satisfy me, John, and Dave, as well as making Alexey and

I seem to detect a growing consensus.... as a contributor, "works for me 
too".