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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Sam Hartman wrote:
> 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.

Sam,

In looking over your initial post and the responses, I think that a core 
component of your comment that is missing is the underlying technical basis that 
makes the split compelling.

So far, the only reason you provided in your original note was that the data 
were not "similar enough".  At the least, it will help to hear why that is 
important, from a technical standpoint.

We all have design preferences, and we are entitled to them.  Absent a 
compelling technical reason for choosing one, such as performance, reliability, 
code complexity, etc., etc., the preference is merely that.  Preference.

For example, I could imagine the claim that having separate interfaces for 
interpretor (control) and message (payload) would make independent handling of 
the different types of data easier.

Alas, I could imagine a response to this concern that environment variable names 
provide all the demultiplexing power that is needed, and that having two 
different paths (interfaces) for passing data actually adds unnecessary complexity.


> 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.

The values in the draft cite architectural modules.  Your proposed change mixes 
nomenclature and perspectives within a single term.

If your proposed change were adopted, the other two values would have to be 
something like "TRANSIT" and "PRE-DELIVERY" and "POST-DELIVERY".  Pretty 
baroque, but at least it would be consistent with what you seem to be proposing.

Better still is that "POST-MDA" leaves ambiguous the choice between an active 
message store (MS) versus the MUA.  Ned's terminology is explicit. His 
document's citing pre-vs.post- delivery is merely some pedagogical assistance.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]