Comments on draft-ietf-eai-imap-utf8-07

[sm-7]

Hello,

The following comments are for draft-ietf-eai-imap-utf8-07.

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."  That isn't noted in the Introduction section.

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

Regards,
-sm

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

[Barry Leiba-3]

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
_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

[Alexey Melnikov]

Hi Barry,
Thank you for your review.

My comments with my individual participant hat on:

Barry Leiba wrote:

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

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

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

Agreed.

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

I agree with you.

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

Yes. David Black (GenArt) already spotted this.

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

Agree.

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

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

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

Agreed.

[...]

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

[Alexey Melnikov]

Hi Barry,

Barry Leiba wrote:

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

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

>Also, I'd prefer putting the parameter names in quotes: "name"
>parameter ... "filename" parameter.
>
Yes, this would be better.
  [...]

>----------------------------
>
>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.
>  
>
It sounds normative. But I don't know if such parameters can be found in
the wild in sufficient quantities to worry about anyway.

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

[Pete Resnick]

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: [phone], Fax: [phone]
_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

[Pete Resnick]

On 9/1/09 at 10:56 PM +0100, Alexey Melnikov wrote:

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

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

Fixed.

>>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.
>
>I agree with you.

Changed as suggested.

>>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.
>
>Yes. David Black (GenArt) already spotted this.

Changed to MUST NOT.

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

Changed as suggested.

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

Fixed.

>>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.
>
>Indeed, "response code" is the proper RFC 3501 term.

Fixed.

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

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.

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

Fixed accordingly.

>>Also, I'd prefer putting the parameter names in quotes: "name"
>>parameter ... "filename" parameter.
>
>Yes, this would be better.

Done.

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

Done.

>>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.
>
>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
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: [phone], Fax: [phone]
_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

[Barry Leiba-3]

Hi, Pete.

>> 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.
>
> 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
_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

[Joseph Yee]

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:

> Hi, Pete.
>
>>> 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.
>>
>> 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
> _______________________________________________
> IMA mailing list
> IMA@...
> https://www.ietf.org/mailman/listinfo/ima

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

[Alexey Melnikov]

Barry Leiba wrote:

>Hi, Pete.
>
Hi Barry,

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

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

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

[Alexey Melnikov]

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.

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

[Joseph Yee-2]

Inline


On 2009-09-10, at 5:11 PM, Alexey Melnikov <alexey.melnikov@...>  
wrote:

> Barry Leiba wrote:
>
>> Hi, Pete.
>>
> Hi Barry,
>
>>>> 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.
>>> 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?
>>
> (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 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*

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

>
> Comments?
>
> _______________________________________________
> IMA mailing list
> IMA@...
> https://www.ietf.org/mailman/listinfo/ima
_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

[Joseph Yee-2]

Which I think is better, thanks Alexey

best,
Joseph

Sent from my iPhone

On 2009-09-10, at 5:20 PM, Alexey Melnikov <alexey.melnikov@...>  
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.
>
> 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.
>
> _______________________________________________
> IMA mailing list
> IMA@...
> https://www.ietf.org/mailman/listinfo/ima

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

[Alexey Melnikov]

Hi Joseph,

Joseph Yee wrote:

> Inline
>
> On 2009-09-10, at 5:11 PM, Alexey Melnikov
> <alexey.melnikov@...>  wrote:
>
>> Barry Leiba wrote:
>>
>>> Hi, Pete.
>>
>> Hi Barry,
>>
>>>>> 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.
>>>>
>>>> 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?
>>
>> (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 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...

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

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

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.

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

[Barry Leiba-3]

> (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@...
https://www.ietf.org/mailman/listinfo/ima

[John C Klensin-3]

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@...> 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@...
> https://www.ietf.org/mailman/listinfo/ima

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

[Alexey Melnikov]

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

[All my responses with either IMAP server or client implementor hat on:]

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

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

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.

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

[Joseph Yee]

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

> Barry Leiba 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.
>>>
> [All my responses with either IMAP server or client implementor hat  
> on:]
>
>> 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.

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

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@...
> https://www.ietf.org/mailman/listinfo/ima

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

[Harald Alvestrand]

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.

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

[Barry Leiba-3]

> 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
_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

[Pete Resnick]

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

--
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: [phone], Fax: [phone]
_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima