Subject: [Extra] I-D Action: draft-ietf-extra-imap4rev2-29.txt

From: [email-masked]
Date: Sat, 13 Feb 2021 08:41:45 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF.

        Title           : Internet Message Access Protocol (IMAP) - Version 4rev2
        Authors         : Alexey Melnikov
                          Barry Leiba
	Filename        : draft-ietf-extra-imap4rev2-29.txt
	Pages           : 174
	Date            : 2021-02-13

Abstract:
   The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2)
   allows a client to access and manipulate electronic mail messages on
   a server.  IMAP4rev2 permits manipulation of mailboxes (remote
   message folders) in a way that is functionally equivalent to local
   folders.  IMAP4rev2 also provides the capability for an offline
   client to resynchronize with the server.

   IMAP4rev2 includes operations for creating, deleting, and renaming
   mailboxes, checking for new messages, permanently removing messages,
   setting and clearing flags, RFC 5322, RFC 2045 and RFC 2231 parsing,
   searching, and selective fetching of message attributes, texts, and
   portions thereof.  Messages in IMAP4rev2 are accessed by the use of
   numbers.  These numbers are either message sequence numbers or unique
   identifiers.

   IMAP4rev2 does not specify a means of posting mail; this function is
   handled by a mail submission protocol such as the one specified in
   RFC 6409.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-29
https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-29

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap4rev2-29

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 13 Feb 2021 16:46:51 +0000

> https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap4rev2-29

This version addresses almost all remaining comments from Ben's IESG 
review. It also cleans up language about which capabilities are required 
on cleartext and which are required on implicit TLS port. And finally I 
updated a NAMESPACE related example to show use of special-use mailbox 
attributes to determine what mailbox names to create for sent and 
deleted mail.

---

From: Timo Sirainen <[email-masked]>
Date: Mon, 15 Feb 2021 14:11:21 +0100

On 13. Feb 2021, at 17.46, Alexey Melnikov <[email-masked]> wrote:
> This version addresses almost all remaining comments from Ben's IESG review. It also cleans up language about which capabilities are required on cleartext and which are required on implicit TLS port. And finally I updated a NAMESPACE related example to show use of special-use mailbox attributes to determine what mailbox names to create for sent and deleted mail.

This is a bit confusing:

>    The client is configured to save a copy of all mail sent by the user
>    into a mailbox with the \Sent attribute.  Furthermore, after a
>    message is deleted from a mailbox, the client is configured to move
>    that message to a mailbox with the \Trash attribute.  The server
>    signals specific mailbox names that should be used for these purposed
>    by returning LIST responses with \NonExistent attribute.  I.e. the
>    server is hinting to the client which mailbox names to use for sent
>    and deleted messages.

Especially the sentence "The server signals specific mailbox names that should be used for these purposed by returning LIST responses with \NonExistent attribute" was very confusing to me. It should rather say something that the \NonExistent signals that the folders don't exist yet, and that it's possible to create any one of them and then they could be used for the \Sent or \Trash purposes. After they are created the \NonExistent would drop away.

Although I've a feeling many clients won't be able to handle this kind of multiple namespaces properly anyway. And I've a feeling that even seeing (\NonExistent \Trash) LIST reply is going to confuse them.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 15 Feb 2021 13:16:34 +0000

Hi Timo,

> Especially the sentence "The server signals specific mailbox names that should be used for these purposed by returning LIST responses with \NonExistent attribute" was very confusing to me. It shoul…
Fine, I can reword as you suggest.
> Although I've a feeling many clients won't be able to handle this kind of multiple namespaces properly anyway.
This is probably true and I am not sure much can be done about that.
> And I've a feeling that even seeing (\NonExistent \Trash) LIST reply is going to confuse them.

This is not really a new problem for IMAP4rev2. I suspect clients that 
want to support this, but don't at the moment, would need to be updated.

I coded this in our client, because this is the only way to announce 
special use mailbox names, when the server doesn't support special use 
mailbox creation.

Best Regards,

Alexey

---

From: Timo Sirainen <[email-masked]>
Date: Mon, 15 Feb 2021 14:23:36 +0100

On 15. Feb 2021, at 14.16, Alexey Melnikov <[email-masked]> wrote:
> This is not really a new problem for IMAP4rev2. I suspect clients that want to support this, but don't at the moment, would need to be updated.
> 
> I coded this in our client, because this is the only way to announce special use mailbox names, when the server doesn't support special use mailbox creation.

I'm not sure what you mean by this. When server doesn't support CREATE-SPECIAL-USE? Dovecot only returns special-use for existing mailboxes. So you can configure it to e.g. use Trash folder for \Trash, but LIST returns it only when Trash actually exists. The more common configuration also sets the special-use folders to be autocreated, so LIST always returns them as if they already exist. I'm not sure what benefit there would be for having a configuration that returns them in LIST reply as \NonExistent, except for this kind of a multi-namespace setup that is likely gone with the UW-IMAP server (although Dovecot can be configured that way as well, but I don't see why anyone would).

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 15 Feb 2021 13:33:51 +0000

On 15/02/2021 13:23, Timo Sirainen wrote:

> On 15. Feb 2021, at 14.16, Alexey Melnikov <[email-masked] 
> <mailto:[email-masked]>> wrote:
>>
>> This is not really a new problem for IMAP4rev2. I suspect clients 
>> that want to support this, but don't at the moment, would need to be 
>> updated.
>>
>> special use mailbox names, when the server doesn't support special 
>> use mailbox creation.
>
> I'm not sure what you mean by this. When server doesn't support 
> CREATE-SPECIAL-USE?
Yes.
> Dovecot only returns special-use for existing mailboxes. So you can 
> configure it to e.g. use Trash folder for \Trash, but LIST returns it 
> only when Trash actually exists.
In M-Box names are globally configured, so advertised automatically for 
all users.
> The more common configuration also sets the special-use folders to be 
> autocreated, so LIST always returns them as if they already exist.
Well, that is another way of doing the same thing.
> I'm not sure what benefit there would be for having a configuration 
> that returns them in LIST reply as \NonExistent, except for this kind 
> of a multi-namespace setup that is likely gone with the UW-IMAP server 
> (although Dovecot can be configured that way as well, but I don't see 
> why anyone would).

I don't think presence of multiple namespaces actually matters for this. 
I mean special use attributes are generic useful even if a single 
namespace exists.

Best Regard,

Alexey