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

Dave Crocker <dhc2@dcrocker.net> Tue, 18 March 2008 18:53 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietfarch-ietf-archive@core3.amsl.com
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6312528C74F; Tue, 18 Mar 2008 11:53:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.501
X-Spam-Level:
X-Spam-Status: No, score=-100.501 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICdv9RbBGkIO; Tue, 18 Mar 2008 11:53:25 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BC9728C663; Tue, 18 Mar 2008 11:53:14 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7427028C6B5 for <ietf@core3.amsl.com>; Tue, 18 Mar 2008 11:53:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acaXaUEUZslY for <ietf@core3.amsl.com>; Tue, 18 Mar 2008 11:53:07 -0700 (PDT)
Received: from sbh17.songbird.com (unknown [IPv6:2001:470:1:76:0:ffff:4834:7146]) by core3.amsl.com (Postfix) with ESMTP id 401A228C71A for <ietf@ietf.org>; Tue, 18 Mar 2008 11:52:08 -0700 (PDT)
Received: from [192.168.0.3] (adsl-67-124-148-133.dsl.pltn13.pacbell.net [67.124.148.133]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id m2IInilO002135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 11:49:49 -0700
Message-ID: <47E00EC8.9030309@dcrocker.net>
Date: Tue, 18 Mar 2008 11:49:44 -0700
From: Dave Crocker <dhc2@dcrocker.net>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: Last Call: draft-freed-sieve-environment (Sieve Email Filtering: Environment Extension) to Proposed Standard
References: <20080314135254.ECC1628C8BB@core3.amsl.com> <tslr6e84dpd.fsf@mit.edu>
In-Reply-To: <tslr6e84dpd.fsf@mit.edu>
X-Virus-Scanned: ClamAV 0.92/6288/Tue Mar 18 03:43:22 2008 on sbh17.songbird.com
X-Virus-Status: Clean
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 18 Mar 2008 11:49:49 -0700 (PDT)
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


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