MBOX-Line: From norman at apache.org  Mon Apr 11 01:55:06 2011
To: imap-protocol@u.washington.edu
From: Norman Maurer <norman@apache.org>
Date: Fri Jun  8 12:34:45 2018
Subject: [Imap-protocol] Ignoring "non permanent" flags while STORE
In-Reply-To: <alpine.OSX.2.00.1104102335530.797@hsinghsing.panda.com>
References: <BANLkTi=aPML+jA_n_HTf7Szk3opvoRbdCA@mail.gmail.com>
	<alpine.OSX.2.00.1104102335530.797@hsinghsing.panda.com>
Message-ID: <BANLkTins0QOGOvrMomzZ4F6CFMLh9vRCNA@mail.gmail.com>

Hi Mark,

thanks your quick response. I want to support at least the fallback to
session flags if the storage is not able to handle permant flags, as
we have an api which allow to easily plugin other storages written by
devs.

Anyway your response answer all my questions and is exactly what I'm
looking for ;)

Thanks,
Norman



2011/4/11 Mark Crispin <mrc+imap@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.
>

