Re: [sieve] Question about draft-ietf-sieve-external-lists-02

Jeffrey Hutzelman <jhutz@cmu.edu> Tue, 03 August 2010 16:55 UTC

Return-Path: <jhutz@cmu.edu>
X-Original-To: sieve@core3.amsl.com
Delivered-To: sieve@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D43343A6998 for <sieve@core3.amsl.com>; Tue, 3 Aug 2010 09:55:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.67
X-Spam-Level:
X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4]
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 iH7iTUdjNzLq for <sieve@core3.amsl.com>; Tue, 3 Aug 2010 09:55:34 -0700 (PDT)
Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id E31E63A69EF for <sieve@ietf.org>; Tue, 3 Aug 2010 09:55:33 -0700 (PDT)
Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o73Gu0fx004237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Aug 2010 12:56:01 -0400 (EDT)
Date: Tue, 03 Aug 2010 12:56:00 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Stephan Bosch <stephan@rename-it.nl>, Ned Freed <ned.freed@mrochek.com>
Message-ID: <E6ACF2B10BCC81BCB369A119@minbar.fac.cs.cmu.edu>
In-Reply-To: <18437_1280824505_o738Z4AF020978_4C57D4A6.1080902@rename-it.nl>
References: <4C500AB3.7040808@rename-it.nl> <01NQ4OHCU1HE00004A@mauve.mrochek.com> <18437_1280824505_o738Z4AF020978_4C57D4A6.1080902@rename-it.nl>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.217.197
Cc: sieve@ietf.org
Subject: Re: [sieve] Question about draft-ietf-sieve-external-lists-02
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIEVE Working Group <sieve.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sieve>, <mailto:sieve-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sieve>
List-Post: <mailto:sieve@ietf.org>
List-Help: <mailto:sieve-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sieve>, <mailto:sieve-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Aug 2010 16:55:34 -0000

--On Tuesday, August 03, 2010 10:34:46 AM +0200 Stephan Bosch 
<stephan@rename-it.nl> wrote:

>> There's also the possibility of doing something akin to how the
>> current regex
>> draft uses comparators - as a means of identifying a canonicalization
>> and what
>> constitutes a unit of comparison. Do we want to allow that sort of use
>> with
>> :list?
>
> Hmm, well.... why not? I suggest we make it an error only when the list
> has no explicit use for it, meaning that implementors MAY accept
> comparators for an external list, but MUST trigger an error when the list
> does not use the specified comparator or the comparator is incompatible
> somehow.
>
> I guess the main question is: what would be the disadvantage of providing
> more flexibility to the implementor for the interaction of :list with
> comparators?

This sounds like an interoperability nightmare.  You describe a situation 
where a SIEVE implementation has the option to accept comparators or not, 
but if not, then providing them is an error, and there is no way for the 
producer of the sieve script to know in advance what will happen.

This is _not_ analogous to comparators that work with :is but not with 
:matches or :contains, because you can know from the specifications which 
combinations are acceptable and which will produce errors.

-- Jeff