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

From: [email-masked]
Date: Tue, 09 Jul 2019 09:15:32 -0700

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 - VERSION 4rev2
        Authors         : Alexey Melnikov
                          Barry Leiba
	Filename        : draft-ietf-extra-imap4rev2-05.txt
	Pages           : 145
	Date            : 2019-07-09

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 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-05
https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-05

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

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: "Bron Gondwana" <[email-masked]>
Date: Sun, 14 Jul 2019 22:39:52 +1000

Late comment on this - based on a query that came up in info-cyrus. RFC3501 was not clear on the handling of subscription when renaming folders, or when a client uses the DELETE command itself via IMAP. It does say that the server must not unilaterally remove the subscription if the folder no longer exists (e.g. an alerts mailbox when gets deleted when empty and recreated when new email arrives), but nothing else.

It would be good to clarify expected behaviour in those two cases, and at least say the server MAY delete the subscription if the user deletes a folder, and maybe even SHOULD rename the subscription if the user renames the folder!

Cheers,

Bron.

On Wed, Jul 10, 2019, at 02:15, [email-masked] wrote:
> _______________________________________________
> Extra mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/extra
> 

--
 Bron Gondwana, CEO, Fastmail Pty Ltd
 [email-masked]

---

From: Barry Leiba <[email-masked]>
Date: Sun, 14 Jul 2019 09:12:22 -0400

This is a really dicey situation, because it’s impossible to know what the
user wants, depending upon the situation.  One can easily come up with
reasonable scenarios where the subscription is strictly to a mailbox’s
name, and it should not follow a rename.

I think the best we can do is talk about the options and use cases, and
leave it without normative statements.

Barry

On Sun, Jul 14, 2019 at 8:40 AM Bron Gondwana <[email-masked]>
wrote:

> Late comment on this - based on a query that came up in info-cyrus.
> RFC3501 was not clear on the handling of subscription when renaming
> folders, or when a client uses the DELETE command itself via IMAP.  It does
> say that the server must not unilaterally remove the subscription if the
> folder no longer exists (e.g. an alerts mailbox when gets deleted when
> empty and recreated when new email arrives), but nothing else.
>
> It would be good to clarify expected behaviour in those two cases, and at
> least say the server MAY delete the subscription if the user deletes a
> folder, and maybe even SHOULD rename the subscription if the user renames
> the folder!
>
> Cheers,
>
> Bron.
>

---

From: "Bron Gondwana" <[email-masked]>
Date: Mon, 15 Jul 2019 23:22:56 +1000

Can we give clients a reliable sequence? I expect it's probably something like:

a RENAME X Y
b SUBSCRIBE Y
c UNSUBSCRIBE X

Bron.

On Sun, Jul 14, 2019, at 23:12, Barry Leiba wrote:
> This is a really dicey situation, because it’s impossible to know what the user wants, depending upon the situation. One can easily come up with reasonable scenarios where the subscription is strictly to a mailbox’s name, and it should not follow a rename.
> 
> I think the best we can do is talk about the options and use cases, and leave it without normative statements.
> 
> Barry
> 
> On Sun, Jul 14, 2019 at 8:40 AM Bron Gondwana <[email-masked]> wrote:
>> __
>>> https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-05 <https://tools.ietf..org/html/draft-ietf-extra-imap4rev2-05>