On Fri, 2008-11-14 at 13:36 +0000, Alexey Melnikov wrote:
2.3. Silent upgrade from reject to ereject
Implementations MUST NOT silently upgrade reject actions to ereject
actions, however user interfaces may change the specific action
underlying a descriptive representation, thereby effecting a silent
upgrade of sorts.
Spencer (technical): ??? I may not understand the point here, but from
the user's point of view, the requirement seems religious - protocol
implementations are prohibited from silently upgrading, but user
interfaces aren't, and the effect on the rejected e-mail, from the
user's perspective, is the same, isn't it?
It might or might not be the same from user's perspective.
Some users only care that the message is rejected, other users care that
their rejection reason get sent correctly to the other end.
Or is this talking about "silently upgrading reject actions" without
making sure that the other side is ereject-capable?
I am not sure what do you call "the other side" in this case. Sieve
engine or end user who sent the message being rejected?
Anyway I do agree that this sentence reads awkwardly. It is trying to
say 2 things:
1). Silently upgrading a Sieve script exposed to the user is a bad
thing, because it might change rejection behavior in an expected (to the
script owner) way.
2). But if the reject action is not exposed directly to the user (e.g.
if it is hidden behind some kind of filtering rule UI that never shows
Sieve script to the user, then silently upgrading might be Ok.
Based on this let me try to rephrase this sentence:
Implementations MUST NOT silently upgrade reject actions to ereject
actions in a Sieve script, because this might lead to unpleasant change of
behavior not expected by the owner of the Sieve script.
However user interfaces that hide/don't present generated Sieve scripts
from the user MAY change the specific action, as long as behavior
as far as the user is concerned hasn't changed.
Is this better?
I've rephrased it slightly, how's this:
Implementations MUST NOT silently upgrade reject actions to
ereject actions in a Sieve script, because this might lead to
unpleasant changes of behavior not expected by the script owner.
User interfaces that present a generic rejection option, and
generate Sieve script output, MAY switch from generating reject
to ereject actions, so long as doing so does not create a confusing
change for the script owner.