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.
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
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
provide all the demultiplexing power that is needed, and that having two
different paths (interfaces) for passing data actually adds unnecessary
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
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.
IETF mailing list