Subject: Re: [EAI] 5738bis

From: Alexey Melnikov <[email-masked]>
Date: Mon, 01 Oct 2012 21:51:50 +0100

On 30/09/2012 14:26, Timo Sirainen wrote:
> OK, finally feeling energetic enough today to answer this mail :)
>
> On 15.9.2012, at 23.55, Alexey Melnikov wrote:
>
>>>>>> The "UTF8=ONLY" capability permits an IMAP server to advertise that
>>>>>> it does not permit the international mailbox name convention
>>>>>> (modified UTF-7),
>>>>> This doesn't really sound like what "design rationale" section talks about UTF8=ONLY. Isn't the idea simply to behave as if client has done ENABLE UTF8=ACCEPT (which may or may not happen to work with current clients)?
>>>> No, I think the idea is to advertise that modified UTF-7 is not supported.
>>> If that's the only reason for UTF8=ONLY it seems a rather wasteful capability. A server that doesn't bother to implement mUTF7, but does bother to implement other kinds backwards compatibility seems rather unlikely to me.
>> I think the idea was that everybody would implement UTF8=ONLY and UTF8=ACCEPT goes away and can be obsoleted.
>>> The text in design rationale section talks that in future everyone would be using UTF8 capable clients and servers and all the old compatibility code could be removed. Wouldn't it make much more sense for UTF8=ONLY to mean that the server has no more such compatibility code? (Basically my idea about assuming client has done ENABLE UTF8=ACCEPT.)
>> Can you suggest some text, I am not yet sure what exactly you are suggesting.
> I'm hoping to avoid having to implement the message downgrading. Has anyone tried various IMAP clients what they do if they are already being fed UTF8 headers and LIST reply? My guess is that they will handle it pretty well. So I'm thinking that the differences between UTF8=ACCEPT vs. UTF8=ONLY are:
>
>   * APPEND: UTF8=ACCEPT requires UTF8 parameter for UTF8 headers, UTF8=ONLY doesn't.
I don't think there was a plan to not use UTF8 parameters for UTF8=ONLY. 
So I think they are still required to be supported.
I think it would be Ok for a UTF8=ONLU server to treat UTF8 parameters 
the same way as regular literals.
> Downgrading not needed, since APPEND can simply fail with NO.
>
>   * FETCH BODY[], BODY[HEADER], etc: Non-UTF8 enabled client is tricky, but with UTF8=ONLY the headers can be sent as-is always.
Right.
>   * FETCH BODY/BODYSTRUCTURE/ENVELOPE: Semi-easy to convert everything(?) for non-UTF8 enabled client. With UTF8=ONLY just send as-is.
Agreed.
>   * LIST: Trivial to convert mailbox names to mUTF7 for non-UTF8 enabled clients. With UTF8=ONLY always send as UTF8.
>
> So only mentioning that UTF8=ONLY affects LIST reply isn't enough. And if my UTF8=ONLY understanding is correct, all of those commands behave identically with UTF8=ACCEPT enabled client and non-UTF8 enabled UTF8=ONLY server. So that's why I'm suggesting simply to change this:
>
>>   The "UTF8=ONLY" capability permits an IMAP server to advertise that
>>   it does not permit the international mailbox name convention
>>   (modified UTF-7),
> to:
>
> The "UTF8=ONLY" capability permits an IMAP server to advertise that it does not support legacy clients anymore, but behaves as if the client had issued ENABLE UTF8=ONLY command immediately after connect. This also means that when a client detects the UTF8=ONLY capability, there is no need for it to even send the ENABLE UTF8=ONLY command.

I don't think your suggestion is correct: it will break clients that 
don't recognize UTF8=ONLY: IMAP servers can't send non IMAP4rev1 
compliant data to clients unless such clients signal that they support 
new capabilities. So ENABLE UTF8=ONLY would always be required.

---

From: Timo Sirainen <[email-masked]>
Date: Tue, 2 Oct 2012 17:56:17 +0300

On 1.10.2012, at 23.51, Alexey Melnikov wrote:

> I don't think there was a plan to not use UTF8 parameters for UTF8=ONLY. So I think they are still required to be supported.
> I think it would be Ok for a UTF8=ONLU server to treat UTF8 parameters the same way as regular literals.

OK, I also started wondering about this after sending the mail.

> I don't think your suggestion is correct: it will break clients that don't recognize UTF8=ONLY: IMAP servers can't send non IMAP4rev1 compliant data to clients unless such clients signal that they support new capabilities. So ENABLE UTF8=ONLY would always be required.

I think what confused me was the "design rationale" text:

   The "UTF8=ONLY" mechanism simplifies diagnosis of interoperability
   problems when legacy support goes away.  In the situation where
   backwards compatibility is broken anyway, just-send-UTF-8 IMAP has
   the advantage that it might work with some legacy clients.  However,
   the difficulty of diagnosing interoperability problems caused by a
   just-send-UTF-8 IMAP mechanism is the reason the "UTF8=ONLY"
   capability mechanism was chosen.

I understood this as UTF8=ONLY means the same as "just-send-UTF-8", but with the benefit of telling clients that it's going to do that.

So is it more correct then to say that with UTF8=ONLY server may simply not send any LIST replies and not allow any CREATE commands, unless ENABLE UTF8=ONLY is done? So basically the server will be unusable without it.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 03 Oct 2012 13:30:24 +0100

> OK, I also started wondering about this after sending the mail.

Personally I don't care about this particular part (I can live with 
either no change from UTF8=ACCEPT or no support for UTF8 parameters in 
UTF8=ONLY).

>     capability mechanism was chosen.

Right, this text is not quite right (see more below).

> I understood this as UTF8=ONLY means the same as "just-send-UTF-8", but with the benefit of telling clients that it's going to do that.
That would have been fine, but you can't do this in IMAP with an 
extension without violating IMAP architecture.  The right way to do this 
while still complying with IMAP architecture is either:
1). the client signals that it understands the extension (ENABLE is one 
mechanism)
  and/or
2). we change the base IMAP capability from IMAP4rev1 to something else.

> So is it more correct then to say that with UTF8=ONLY server may simply not send any LIST replies and not allow any CREATE commands, unless ENABLE UTF8=ONLY is done?

I think so.

> So basically the server will be unusable without it.

Nearly unusable, yes.

---

From: Timo Sirainen <[email-masked]>
Date: Wed, 3 Oct 2012 19:30:08 +0300

On 3.10.2012, at 15.30, Alexey Melnikov wrote:

> Personally I don't care about this particular part (I can live with either no change from UTF8=ACCEPT or no support for UTF8 parameters in UTF8=ONLY).

I don't care that much either :)

> That would have been fine, but you can't do this in IMAP with an extension without violating IMAP architecture.  The right way to do this while still complying with IMAP architecture is either:
> 1). the client signals that it understands the extension (ENABLE is one mechanism)
> and/or

IMAP clients don't give very informative error messages if IMAP4rev1 is missing, so I guess ENABLE is better.

>> So is it more correct then to say that with UTF8=ONLY server may simply not send any LIST replies and not allow any CREATE commands, unless ENABLE UTF8=ONLY is done?

OK, so maybe something like:

The "UTF8=ONLY" capability permits an IMAP server to advertise that it does not support IMAP clients that do not issue ENABLE UTF8=ONLY. A client that supports this extension MUST send ENABLE UTF8=ONLY command either before login or as the first command in the authenticated state. The server may otherwise reject all commands or otherwise restrict the mailboxes visible to the client.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 04 Oct 2012 16:18:05 +0100

> The "UTF8=ONLY" capability permits an IMAP server to advertise that it does not support IMAP clients that do not issue ENABLE UTF8=ONLY. A client that supports this extension MUST send ENABLE UTF8=…

RFC 5161 says:

    The ENABLE command is only valid in the authenticated state (see
    [RFC3501])

I also think that some useful information was lost during this rewrite. So how about this:

OLD:
    The "UTF8=ONLY" capability permits an IMAP server to advertise that
    it does not permit the international mailbox name convention
    (modified UTF-7), and also allows all of the capabilities that are
    allowed by "UTF8=ACCEPT" (see Section 4).  As this is an incompatible
    change to IMAP, a clear warning is necessary.  IMAP clients that find
    implementation of the "UTF8=ONLY" capability problematic are
    encouraged to at least detect the "UTF8=ONLY" capability and provide
    an informative error message to the end-user.

NEW:
    The "UTF8=ONLY" capability permits an IMAP server to advertise that
    it does not permit the international mailbox name convention
    (modified UTF-7), and also supports all of the functionality that is
    allowed by "UTF8=ACCEPT" (see Section 3 and Section 4).
    As this is an incompatible change to IMAP, the server is required
    to wait for ENABLE UTF8=ONLY command before it can start sending
    pure UTF-8 mailbox names and non-ASCII messages. In order of
    being able to talk to a server advertising "UTF8=ONLY" the client
    needs to send ENABLE UTF8=ONLY command in the authenticated state
    (as per requirements in [RFC5161]). The server may otherwise,
    in order to stay compliant with RFC 3501, reject all commands or
    otherwise restrict the mailboxes visible to the client.

    IMAP clients that find implementation of the "UTF8=ONLY" capability
    problematic are encouraged to at least detect the "UTF8=ONLY" capability
    and provide an informative error message to the end-user.

---

From: Timo Sirainen <[email-masked]>
Date: Fri, 5 Oct 2012 19:56:58 +0300

>   The ENABLE command is only valid in the authenticated state (see

Oh, somehow I remembered that it was. Wonder why I've even bothered to add a dummy ENABLE handler for non-authenticated state (just replies "ENABLE ignored in non-authenticated state.")

>   and provide an informative error message to the end-user.

I'm ok with that. (Although I think it could be done with less text, but I don't really want to suggest such changes :)

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 20 Oct 2012 13:29:00 +0100

On 15/09/2012 17:35, Timo Sirainen wrote:
> Maybe it should also have a sentence about using UTF8 in NAMESPACE reply. It could contain UTF8 prefixes, and also when LANGUAGE extension is enabled the TRANSLATION could contain UTF8.
Ok, here is a proposal to address this:

In Section 3, add to the end of the 1st paragraph:

    The "UTF8=ACCEPT" capability indicates that the server supports the
    ability to open mailboxes containing internationalized messages with
    SELECT and EXAMINE, and can provide UTF-8 responses to the LIST and
    LSUB commands.

ADD:

This capability also affects other IMAP extensions that can return 
mailbox names
or their prefixes, such as NAMESPACE [RFC2342] and ACL [RFC4314]

And add [RFC2342] and [RFC4314] to informative references.

---

From: "Jiankang YAO" <[email-masked]>
Date: Mon, 22 Oct 2012 11:30:35 +0800

it is fine to me.

Jiankang Yao

----- Original Message ----- 
From: "Alexey Melnikov" <[email-masked]>
To: "Timo Sirainen" <[email-masked]>
Cc: "IETF EAI" <[email-masked]>
Sent: Saturday, October 20, 2012 8:29 PM
Subject: Re: [EAI] 5738bis

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