Stuart,
The SELECT response that you quote strikes me as unusual, perhaps even a bit anomalous, but not unreasonable. The user might, for example, have permissions that, in principle, give him write access to the mailbox but have specific prohibitions for storing each message flag. (That's a fanciful explanation -- I have never come across a server with per-flag permissions -- but a possible one.)
By my reading of the RFC, I must agree with you that, if a server stores a flag in a persistent manner that it has not advertised in a SELECT or EXAMINE response as a PERMANENTFLAG, then it is in violation. If you can confirm that the server involved in this particular case is doing that then, I believe, you should complain strongly.
I have experience with transitorily connected wireless clients. However, while that mode of operation is very likely to influence such considerations as what and how much data is downloaded and in what size pieces, I cannot see why it should affect the handling of flags in any way beyond that. And it is not at all clear what you mean by "honouring" PERMANENTFLAGS.
Pete Maclean
At 02:56 PM 8/6/2004, Stuart Nicholson wrote: Nicely put and I see your point. I'm dealing with a wireless client that isn't using the normal IMAP 'connected' model. Our sessions typically last less than 5 minutes which has obviously influenced our design. However I would expect folders that can't be modified to have the READ-ONLY property surely? We see things like this (taken from a user log):
0003 SELECT "INBOX"[0x0D][0x0A] * 40 EXISTS * 0 RECENT * OK [UIDVALIDITY 1012731894] UID validity status * OK [UIDNEXT 7880] Predicted next UID * FLAGS (\Answered \Flagged \Deleted \Draft \Seen) * OK [PERMANENTFLAGS ()] Permanent flags * OK [UNSEEN 8] first unseen message in INBOX 0003 OK [READ-WRITE] SELECT completed
And the user complains that other clients allow FLAGS to be set and they are set permanently (over sessions) which seems to violate the RFC, at least as I understood it.
I'm beginning to think given our short session times and rigid session model (i.e. we always sync the message flags at start of session), there's really little point in us honouring PERMANENTFLAGS at all.
Thanks,
Stuart Nicholson www.snappermail.com
----- Original Message ----- From: "Larry Osterman" <[EMAIL PROTECTED]> To: "Stuart Nicholson" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, August 05, 2004 4:32 PM Subject: RE: FLAGS vs PERMANENTFLAGS
That behavior (empty permanentflags but flags) is explicitly allowed. And if you read the spec VERY carefully you'll find it's REQUIRED if the user can't modify the folder. The server maintains flags, but they aren't persisted.
Think of it this way: FLAGS is the set of flags supported by the server. PERMENANTFLAGS is the set of flags that will be persisted in the server's database. FLAGS is necessarily a superset of PERMENANTFLAGS, but they are different and have different meanings.
Larry Osterman
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stuart Nicholson Sent: Friday, August 06, 2004 11:16 AM To: [EMAIL PROTECTED] Subject: FLAGS vs PERMANENTFLAGS
Greetings, my first post here so an brief intro: I'm the developer building IMAP client support for SnapperFish. We're responsible for 'SnapperMail' (www.snappermail.com) a wireless email client for PalmOS based devices.
Question: How well honoured are FLAGS vs PERMANENTFLAGS in the IMAP community? Is PERMANENTFLAGS overdesign that actually isn't used in the wild that often? Do other clients actually only honour FLAGS and disregard PERMANENTFLAGS?
Is ask beause our IMAP client is currently coded closely to RFC3501 in this respect however we've received a number of reports from users of servers that persistently return empty (i.e. "PERMANENTFLAGS ()") responses while still allowing the flags in FLAGS to be permanently set on messages in the mailbox. This seems in direct violation to the RFC however other IMAP clients happily set flags on these particular servers.
Is it worth just relaxing our client on this point hence disregarding PERMANENTFLAGS and simply relying on FLAGS and the READ-WRITE/READ-ONLY folder property?
Thanks,
Stuart Nicholson www.snappermail.com
-- ----------------------------------------------------------------- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html -----------------------------------------------------------------
-- ----------------------------------------------------------------- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html -----------------------------------------------------------------
--
-----------------------------------------------------------------
For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html
-----------------------------------------------------------------
