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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf