[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lemonade] draft-ietf-lemonade-imap-sieve-00
Dave Cridland wrote:
If Polymer wanted to both answer the message and forward it, however, it
now can't - the act of answering the message has destroyed it forever.
Of course, in fact, it might not have been destroyed, but Polymer cannot
know that.
Sieve scripts are meant to be user-defined things; if the user wants to
file \Answered messages away, and remove them from her inbox, I think the
user should be able to do that.
I suppose what it comes down to is that you're arguing that clients should
provide that function, and users who want it should choose clients that do.
And that the function shouldn't be available on the server, through Sieve
scripts.
That argument is fine, but for "diverse service environments", where we
might WANT some of this stuff done on the server.
When we get down to it, though, this document was written because of the
need to do notifications, so my thoughts about what else one might do with
these functions are speculative. See below.
> I also have a nasty feeling that some clients will take it upon
> themselves to make setting the \Deleted flag instantly expunge the
> message.
This certainly doesn't give them license to do that.
That's exactly what it does do. This grants full license to anyone and
everyone to provide their very own favourite semantics for mailstores.
It does not, and I can't see how you can claim that. But let's not get
into an "Is so! / Is not!" match.
Whether this is a good idea or not is something the implementer of the
script has to decide.
No, it's not. It's up to the one client author who doesn't like a two
phase delete, and sticks an innocuous checkbox marked "Delete
Immediately" somewhere.
Oh, be real: a client author who wants to do that already can, by just
putting in the checkbox and putting code in that always sends EXPUNGE
whenever it sets the \Deleted flag. The IMAP spec is quite clear about
that being a bad idea, and clients insist on implementing "Trash"
mailboxes anyway. This doesn't change anything with respect to THAT.
Okay, so it can lie about the UIDs all the time, breaking
I had thought that UIDPLUS allowed an "I don't know the UID" response;
as I look again, I see that it doesn't. OK.
So we get back to the choices in my response to Mark, extended to
the "new message" case. Again, see below.
Running a Sieve script explicitly over a set of messages would be nice,
> and would allow for all sorts of useful behaviour, commonly handled by
> clients locally:
That's a good idea, which might be good to add here: an IMAP RUNSIEVE
command, with a corresponding cause=RUNSIEVE. I like it. Do others?
Shall I add it?
Without meaning to sound arrogant, it doesn't matter a jot what anyone
thinks. Message content in IMAP is immutable. The only way to allow
EditHeader would be to allocate a new UID for the message, which in turn
destroys the cache.
Uh, we ARE assigning new UIDs, and we're NOT changing headers on existing
messages. My draft explicitly says that the EditHeader actions are only
available for NEW MESSAGES, and so only for cause=APPEND and cause=COPY.
That said, you've brought up a point that I hadn't considered: that
clients expect the messages created by APPEND and COPY to be unchanged,
and that this will hurt their message cache. It might be best, then,
to go with my original thought of banning EditHeader in all cases.
Any objections?
It's "below" now:
In my response to Mark, I suggested that we choose to change what happens
for cause=FLAG and cause=ANNOTATE in one of these ways (and we have to
decide):
1. Have the Sieve script actually behave as a client that has issued
the appropriate COPY/STORE/EXPUNGE commands (and, actually, we can
discuss whether to eliminate the EXPUNGE from there).
2. ALWAYS retain the implicit keep.
Let's expand that to the cases of cause=APPEND and cause=COPY, and say
that for the new messages created like that, we actually DO store the
message first (which gives the UIDPLUS response code), and THEN behave
as we choose, above, for existing messages.
I think this will take care of most of the concerns that Dave has raised,
though, of course, there's still the issue of wasted effort and resource
in the client if we choose option 1. I'm more and more in favour of
saying that for all of the cases described in this document, we retain
the implicit keep... EXCEPT that we allow the "reject" action, which
gives a protocol-level NO to APPEND/MULTIAPPEND/COPY, and stores nothing.
Barry
--
Barry Leiba, Pervasive Computing Technology (leiba at watson.ibm.com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
_______________________________________________
lemonade mailing list
lemonade at ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade