Randall Gellens wrote:
At 10:02 PM -0600 9/16/00, Alexey Melnikov wrote:
So you like the idea, but you don't like the wording (more precisely the
explanation).
Yes, I like very much being able to set IMAP flags with Sieve.
I just think the draft should specify what happens when the new
commands are used, and leave the underlying implementation alone. I
realize you were introducing the global variable concept to help make
your point,
In fact I was trying to explain the concept in mathematical terms (set
operations), but it might be to academic for the purpose.
Sorry, my brains just work this way :-).
but I personally think it's better so simply say that
this command adds a flag, this command takes away an added flag, etc.
Add/take away flags to/from what?
If you don't say "internal variable" you will use "message", thus you assume
there
is some internal "storage" for the current list of flags, i.e. "variable".
If the message is kept, the flags (if any) are also kept. If the
message is discarded, the flags have no effect.
Also, I think the descriptions of 'mark' and 'unmark' are unclear. They
should specify exactly what is to happen, and not have so many MAY do this
or that statements.
Barry originally said that draft is too tied to IMAP. mark/unmark
allows to specify importance of the message without enforcing the way how it
is implemented.
I think it makes it harder to interoperate, especially since this
affects the email client. Perhaps what we need instead is to give up
using IMAP flags for this, and use Annotations instead. Sounds like
the message/priority is needed here.
Are you proposing to bound mark/unmark to IMAP Annotation or drop it?
I think the draft should make it clear that this is an open issue: to
have separate commands, bundle with keep/fileinto, or both.
Ok
Alexey