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.

Instead of extension for 3), maybe there could be an extension for 1).
The client may not know which flags are still in use, for example if it 
does not work with all messages.

What could be interesting would be some extension for 1) :
when adding a new flag, when the server need to recycle, there can be 
such a reponse :

1 STORE 1 +FLAGS ($Junk)
* RECYCLEFLAGS ($Forwared $ThisFlag $AnotherOne)
* 1 FETCH (FLAGS (\Seen $Junk))
1 OK STORE completed

or :

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.

> 2) Allow servers to recycle keywords unilaterally, but not in a session.

I vote for 2)

> 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.

> 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.

> 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).

However, I am a client implementor.



I reissue my question :

is PERMANENTFLAGS a required response when a mailbox is selected ?
or can it be optional ?

-- 
DINH V. Hoa,

etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan

Reply via email to