Mark Crispin wrote : > (1) is the situation today. Extensions extend; they do not preserve the > status quo. Furthermore, extensions extend client behavior. > > > 1 STORE 1 +FLAGS ($Junk) > > * RECYCLEFLAGS ($Forwared $ThisFlag $AnotherOne) > > * 1 FETCH (FLAGS (\Seen $Junk)) > > 1 OK STORE completed > > If $Junk was added, a new FLAGS and PERMANENTFLAGS has to be returned. > Therefore, RECYCLEFLAGS is extraneous since that list can be derived. > > > 1 STORE 1 +FLAGS ($Junk) > > * OK [PERMANENTFLAGS (\New \Deleted $NoJunk $AndTheRest)] > > * 1 FETCH (FLAGS (\Seen $Junk)) > > 1 OK STORE completed > > \New is not a flag. > > If $Junk was added, a new FLAGS and PERMANENTFLAGS has to be returned. > > If $Junk was not added, this example issued a PERMANENTFLAGS for no > apparent reason, but in any case $Junk is not a permanent flag.
As I didn't read well my bible (the RFC :) ), if client is notified by untagged PERMANENTFLAGS response, this can be a possibility. Then, 1/ and 2/ are possible. 3/ and 4/ out. Maybe things should be clarified about PERMANENTFLAGS in IMAP specifications. (the fact that PERMANENTFLAGS responses can be sent after a STORE command). -- DINH V. Hoa, etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
