Re: Last Call: draft-freed-sieve-environment (Sieve Email Filtering: Environment Extension) to Proposed Standard

[Sam Hartman <hartmans-ietf at mit.edu>]

This extension appears to conflate two unrelated things: information
about the interpreter context and information about the message.

I don't think these two sets of information are similar enough that the same interface should be used to get to both of them.

In particular I believe that the remote-host and remote-ip variables
are inappropriate and should not be standardized.

I believe an applicability statement should be added to the extension
making it clear that this extension is only for interpreter state and
that another extension should be designed for examining information
about the message.


I find the string "MUA" meaning anything that happens after delivery
confusing.  I'd suggest another string--possibly "POST-MDA" and
reserve "MUA" for sieve scripts actually executed inside a MUA.
Alternatively perhaps "MUA" could mean the script is executed at the
direction of the MUA.  That's not quite the same thing as
post-delivery.



Section 4.3.3 claims that experimental RFCs are an appropriate
mechanism to register non-standards-track variables intended for wide
use.  That seems wrong.  I recommend revisiting the registration
policy.


In conclusion, I object quite strongly combining message and
interpreter context information.  The other comments I'm making are
less serous.  However based on the number of comments I think this
document needs significant positive review before it is ready to be
published.

_______________________________________________
IETF mailing list
IETF at ietf.org
https://www.ietf.org/mailman/listinfo/ietf