"Matthew Elvey (FM)" wrote:
Five suggestions to the draft.
[Sorry, I had problems with my laptop this week].
Way back On Tue, 2002-07-16, Tim Showalter wrote:
Cyrus Daboo wrote:
| Tim thought that in order to do this right, we need to introduce
| variables in Sieve.
| So I am waiting for either:
| 1). draft that adds Sieve variables
| 2). a desire to standardize draft-melnikov-sieve-imapflags-04.txt as is
| (with an implicit variable).
One option might be to get rid of the ':globalflags...' tagged arguments
and all the actions and instead only rely on the ':flags' tagged argument
for fileinto and keep. I believe that gets rid of the need to have any
variables during the lifetime of the script, and provides a basic
implementation that can be built on later if variables are introduced.
I agree with this. :globalflags mostly bothered me with respect to
variables.
Suggestion 1:
I suggest :globalflags not be removed at least unless a draft and
implementation adding Sieve variables is well underway.
-As Ken has said, being able to set a flag once is useful,
and with variables, something like
keep [VariableName, "\\Answered", "$MDNSent"];
would work.
This example makes a complexity of variables evident though - could
VariableName be a string-list?
Adding variables isn't trivial.
Suggestion 2, regarding 3.4, quoted below (Of course, if all implicit
variables are to done away with, 3.4 mark and unmark would need to go
too, so these changes are moot.):
3.4. Mark and Unmark Actions
Syntax: mark
Syntax: unmark
The mark action allows a message to be marked as urgent. Conformant
implementation MUST
set \Flagged [IMAP] flag, but MAY also set other [IMAP] flags as well.
Thus the mark action is
semantically equivalent to 'addflag "\\Flagged"'.
The unmark action allows the flag previously set by the Mark action to
be unset.
Unmark MUST unset the [IMAP] \Flagged flag and all other flags that could
be added with mark.
Unmark MUST NOT unset any other flags. This means that the following
script does nothing:
mark;
unmark;
The unmark action is semantically equivalent to 'removeflag "\\Flagged"'.
Several little problems: if mark sets more than one flag,
then the last sentence is false. If the message is already marked, then
mark; unmark; does SOMETHING. It Removes the flag(s) the first mark set.
Yes, unmark shouldn't remove any flags not settable by mark.
Does the \Flagged flag necessarily imply the message is "urgent",
I believe the consensus of IMAP community is that this is the case.
as the first sentence claims?
Also, why would mark want to set other flags?
Lastly, unmark cannot unset flags other than \Flagged set by other
implementations, because it cannot know what they are.
Suggested replacement text:
3.4. Mark and Unmark Actions
Syntax: mark
Syntax: unmark
The mark action allows a message to be marked. Conformant implementation
MUST
set \Flagged [IMAP] flag, but MAY also set other [IMAP] flags as well.
The unmark action allows the flag previously set by the Mark action to be
unset.
Unmark MUST unset the [IMAP] \Flagged flag and all other flags that could
be added with mark by the implementation.
Unmark MUST NOT unset any other flags.
Ok, I agree with all your comments regarding mark/unmark. However, as mentioned
earlier these two commands will be dropped
from the document.
Suggestion 3:
IMHO, the RFC would be useful if the following was added:
I would follow the sentence in 5. "The SIEVE interpreter MUST ignore these
commands when no keep (implicit or explicit) or fileinto actions will be
taken."
with "Thus, for example, scripts should set flags before fileinto, not after!"
Why: it's non-obvious to sieve script writers, who get caught by this
'gotcha'.
#A counterexample:
#The following doesn't make sense: the Seen flag isn't set in any message
store,
#because it isn't followed by a keep or fileinto which would cause it to do
so.
#If you want the copy in test1 to be marked as seen, reverse the order of the
fileinto
#and addflag commands. Perhaps an implementation SHOULD flag this as an
error.
#But perhaps not; I think an implementation couldn't catch all such errors,
#except at runtime, so trying to catch some isn't very helpful.
if header "subject" :contains "test1"
{
fileinto "test1 folder";
addflag "\\Seen";
stop;
}
Ok, I've updated my copy. But once again, as the decision was to use variables,
this will be dropped in the future
(however I keep a copy of all changes if somebody comes up with a counter
argument
Suggestion 4:
There's a typo : "If non of the 4" should read "If none of the 4"
Fixed.
Suggestion 5:
address :all :contains
["To", "Cc", "Bcc"] "me(_at_)company(_dot_)com
<mailto:me(_at_)company(_dot_)com>",
is nonsensical; it should be changed to
address :all :contains
["To", "Cc"] "me(_at_)company(_dot_)com
<mailto:me(_at_)company(_dot_)com>",
because there is no Bcc header in received email.
Changed.
Regards,
Alexey
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK
Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel
I speak for myself only, not for my employer.
__________________________________________