DINH Viet Hoa said: > Mark Crispin wrote : > >> In summary, I believe that the choices are: >> >> 1) Do nothing. IMAP client implementors are put on notice that servers >> which unilaterally recycle keywords (including in a session) may >> happen >> someday, and that client code which doesn't handle this is broken. >
<snip> > > 1 STORE 1 +FLAGS ($Junk) > * OK [PERMANENTFLAGS (\New \Deleted $NoJunk $AndTheRest)] > * 1 FETCH (FLAGS (\Seen $Junk)) > 1 OK STORE completed > > then, the permanentflags will be updated by the client. I vote for this approach. > >> 2) Allow servers to recycle keywords unilaterally, but not in a session. > > I vote for 2) If there is a max on the number of keywords then this also requires an untagged OK reponse with the PERMANENTFLAGS without the \* entry. >From client point of view this is not ideal because the client doesn't know if reinitiating the session cleans up the unused keywords and returns a mailbox with the possibility to set new keywords. But I might be misunderstanding the issue. > >> 3) Allow keyword recycling, but only by client command (and define an >> extension to do this). > > I am not happy with that one. I don't think that the client need to care > about that. That's the server's matter. Agreed. > >> 4) Forbid any form of keyword recycling. Once created, keywords are >> forever (this is the status quo in my implementation). > > I am not happy with that. Agreed. Non used keywords in a mailbox are nothing more then noise in the permanentflags reponse. The \* part is enough for a client. > >> Are any of these four choices *unacceptable* to anyone? I think that >> perhaps some people may want to veto choices 1 and 4, and then focus on >> choices 2 or 3 (or perhaps a hybrid). > Nothing is unacceptable. BTW, It would be nice if the client can be informed about the max number of keywords in a mailbox. something like: * OK [MAXKEYWORDS 30] that can returned on a select. Regards, Marc Groot Koerkamp.
