Re: Last Call: draft-ietf-sieve-refuse-reject (Sieve Email Filtering: Reject and Extended Reject Extensions) to Proposed Standard

[Aaron Stone <aaron@xxxxxxxxxxxxxx>]

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.

Aaron