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

[Barry Leiba <[e-mail]>]

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 <[e-mail]>
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.
>
> On Wed, Jul 10, 2019, at 02:15, [e-mail] wrote:
>
>
> 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/
>
> _______________________________________________
> Extra mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/extra
>
>
> --
>   Bron Gondwana, CEO, Fastmail Pty Ltd
>   [e-mail]
>
>
>