On Mon, 27 Jan 2003, Mark Crispin wrote: >On Mon, 27 Jan 2003 20:04:14 +0100 (CET), Andreas Aardal Hanssen wrote: >> The "updated flags" yes - so the unupdated flags need not be returned, no? >If an external entity changed flags (which is what is being discussed), then >there is always an update. The question is therefore meaningless.
Spare me the hostility - the question was not "should flag updates from external entities be shown" but "is this correct IMAP". If I do this: 1 FETCH 1 FLAGS * 1 FETCH (FLAGS (\Seen)) 2 STORE 1 +FLAGS () * 1 FETCH (FLAGS (\Seen)) If the IMAP server knows, in this example, that the client is perfectly aware of the state of flags in message #1, why should it then send the untagged FETCH? Andy >> 3 store 1 +flags () >> * 1 FETCH (FLAGS (\Seen)) >> 3 OK STORE completed. > >This is correct behavior. This was not the ".SILENT" form of storing flags, >therefore the update must always be returned even if nothing changed. > >> This is another IMAP server (identifies as IMAP4rev1 v11.241): > >Gack, is anyone still running that version? It has known security bugs! > >> 4 store 1 +flags () >> * 1 FETCH (FLAGS (\Recent)) >> 4 OK STORE completed > >This is also correct behavior. \Recent has special semantics, and can not be >altered by STORE. > >This is also a good example of why STORE returns flags unless you use >".SILENT". In the case of > 4 store 1 +flags.silent () > 4 OK STORE completed >without a preceeding "fetch 1 flags" a client migh falsely presume that the >flags of message 1 are now all unset. The client would be wrong, since if it >never fetched the flags for message 1 it doesn't know the status of \Recent. > > -- Andreas Aardal Hanssen - Binc IMAP http://www.bincimap.andreas.hanssen.name/
