MBOX-Line: From mrc+imap at panda.com  Sun Apr 10 23:46:14 2011
To: imap-protocol@u.washington.edu
From: Mark Crispin <mrc+imap@panda.com>
Date: Fri Jun  8 12:34:45 2018
Subject: [Imap-protocol] Ignoring "non permanent" flags while STORE
In-Reply-To: <BANLkTi=aPML+jA_n_HTf7Szk3opvoRbdCA@mail.gmail.com>
References: <BANLkTi=aPML+jA_n_HTf7Szk3opvoRbdCA@mail.gmail.com>
Message-ID: <alpine.OSX.2.00.1104102335530.797@hsinghsing.panda.com>

You should implement all flags as permanent flags.  By doing that, you
won't have the issue at all.

If, for some reason, your mail store is deficient and can not support all
flags as permanent flags (an example being netnews with .newsrc which only
has a single flag), then the issue comes up.  In that case, you should
implement session flags since otherwise there is an inferior user
experience.  For example, if \Seen is not a permanent flag, then failure
to implement session flags will cause user-unexpected behavior with FETCH
BODY vs. FETCH BODY.PEEK.

The "ignore the change" wording was to provide an out for implementations
that did not implement session flags.  Such servers always caused bad user
experiences.

A "session" in IMAP starts at SELECT time and ends when the mailbox is
unselected (subsequent LOGOUT, SELECT, CLOSE, and/or UNSELECT command).
The term "connection" is used for what some people call a "TCP/IP
session".  As a single IMAP connection can have multiple sessions with
different mailboxes, the distinction is important.

There is no expectation that session flag state would be shared with any
other session.

On Mon, 11 Apr 2011, Norman Maurer wrote:
> Hi there,
>
> I'm currently working on our JAVA bases IMAPServer (james.apache.org)
> and try to get it 100% rfc3501 conform. For testing purposes I use
> dovecots ImapTest (http://www.imapwiki.org/ImapTest). One of the tests
> that are fails is not what I would expect, so maybe someone can tell
> me if I understood the RFC wrong.
>
> When someone try to store a "non permanent" flag implementations are
> free to ignore this. As the RFC state:
>
>
>      PERMANENTFLAGS
>
>         Followed by a parenthesized list of flags, indicates which of
>         the known flags the client can change permanently.  Any flags
>         that are in the FLAGS untagged response, but not the
>         PERMANENTFLAGS list, can not be set permanently.  If the client
>         attempts to STORE a flag that is not in the PERMANENTFLAGS
>         list, the server will either ignore the change or store the
>         state change for the remainder of the current session only.
>         The PERMANENTFLAGS list can also include the special flag \*,
>         which indicates that it is possible to create new keywords by
>         attempting to store those flags in the mailbox.
>
> The TestKit seems to expect that even if the flag is "ignored" in
> STORE to see a response which includes the flag. Is this correct ? I
> would have expected that the response would not include this flag and
> just return the other "permanent" flags. So is the TestKit wrong or my
> understanding ;) ?
>
> Some related question... If I would support "session flags", getting
> these reset when the mailbox is unselected or only when the session is
> closed ? And get the session flags shared with other session which
> have the same mailbox selected ?
>
> Thanks for your help,
> Norman
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
>

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

