I am now struggling to make sure that I properly understand all the implications of system-flag handling so that I can confirm that my code is indeed correct. For a start, a server must list all the system flags (except \Recent) in a FLAGS response to every successful SELECT or EXAMINE (even though that seems redundant).
RFC 3510 section 7.1 states that, "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." Now, I suppose that ignoring such a change could be deemed a reasonable strategy because one could argue that it is effectively equivalent to storing the change only to have another party immediately do a STORE that reverses it. However, if a server adopts that strategy, it is equivalent to its not handling the flag at all (except to the extent that it does not consider a STORE for the flag to be an error). So it must advertise that it supports the flag even though it really does not.
Now, what if a server stores the state change for the remainder of the current session only. Does that mean it stores it *for* the current session only? I presume so because anything else could be a nightmare. This suggests that, if the same client creates a second session and selects the same mailbox, it could see different flag states from the first. Granted, opening such a second session is probably an ill-advised venture to begin with (although I have seen it happen) so this inconsistency is hardly a big deal -- never mind that it is something that a properly functioning client should be prepared for.
By contrast to all this, my reading of the RFC is that, when the \Seen flag is set implicitly (by virtue of an appropriate FETCH), it must be indeed be set; there is no option. Now, a server could choose not to set it and hold forth the same argument as above (that the flag could be instantly reset by a third party) but that argument breaks down because, if the flag is effective only for the session involved, then in practice nothing external could sensibly change it. This all seems a bit of a mess.
What I have said may sound somewhat critical and that may be because I am rather peeved at my own misunderstanding. My prime intention in writing this message though is solely to make sure that I now do understand this well.
Pete Maclean
At 12:01 PM 8/19/2004, Larry Osterman wrote:
Ah, you're right - I forgot about \Recent. \Recent is "special" since it's not a "real" flag.
From: Pete Maclean [mailto:[EMAIL PROTECTED]]
Sent: Wed 8/18/2004 2:48 PM
To: Larry Osterman; petite_abeille; [EMAIL PROTECTED]
Subject: RE: shared mailbox permanent flags?
I think that either what you say is not quite correct or I am not
understanding it right. RFC 3501 gives an example of a FLAGS response that
does not include all the system/built-in flags:
Example: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
In this case, \Recent is missing. As I read the spec, if you do not
include a particular system flag in this response, it means that you do not
support it for the mailbox. Incidentally, some versions of my server do
not support \Recent at all.
Pete Maclean
At 05:09 PM 8/18/2004, Larry Osterman wrote:
>You MUST support ALL the built-in flags on every mailbox. You might not
>be able to persist those flag settings, but you MUST support them on a
>per-session basis.
>
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>On Behalf Of petite_abeille
>Sent: Wednesday, August 18, 2004 2:00 PM
>To: [EMAIL PROTECTED]
>Subject: Re: shared mailbox permanent flags?
>
>Hi Timo,
>
>On Aug 18, 2004, at 22:37, Timo Sirainen wrote:
>
> > FLAGS list shouldn't be empty. It should contain at least the system
> > flags.
>
>Ok. So FLAGS should always returns \Answered \Deleted \Draft \Flagged
>\Recent and \Seen? Even if they are not applicable for such mailbox?
>
> >> But this doesn't seem to help :/
> >
> > Yep. I doubt there's a way to make it work many (if any) clients.
>
>Sigh :/
>
>PA.
