This is one of the most subtle parts of IMAP IMHO. READ-ONLY deals with the messages in the folder, not necessarily the flags on those messages.
The flags on a messages can always be modified, but they might not be persisted. I'm not sure I understand what "honoring" permanentflags means. The server's telling you that you can change the flags but they won't have changed the next time you connect. You don't have control over this behavior. Larry Osterman -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stuart Nicholson Sent: Friday, August 06, 2004 11:57 AM To: [EMAIL PROTECTED] Subject: Re: FLAGS vs PERMANENTFLAGS 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 -----------------------------------------------------------------
