RE: Proposed Sieve extensions

Randall Gellens <randy@Qualcomm.Com> Thu, 12 November 1998 23:52 UTC

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA17926 for ietf-mta-filters-bks; Thu, 12 Nov 1998 15:52:12 -0800 (PST)
Received: from adept.qualcomm.com (adept.qualcomm.com [129.46.2.41]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA17922 for <ietf-mta-filters@imc.org>; Thu, 12 Nov 1998 15:52:11 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by adept.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id PAA13808; Thu, 12 Nov 1998 15:55:05 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Message-Id: <v04102e85b271235244ac@129.46.219.133>
In-Reply-To: <003301be0e94$02c4e780$2c05020a@jeep.software.com>
References: <v04102e7fb27116573767@129.46.219.133>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Thu, 12 Nov 1998 15:51:14 -0800
To: alan.stebbens@Software.com, ietf-mta-filters@imc.org
From: Randall Gellens <randy@Qualcomm.Com>
Subject: RE: Proposed Sieve extensions
Sender: owner-ietf-mta-filters@imc.org
Precedence: bulk

At 3:27 PM -0800 11/12/98, Alan K. Stebbens wrote:

> | If I've misunderstood you, and you want these to be considered as
> | extensions, in their own document, that's a different matter.
>
> This sounds like a better approach than stopping forward progress on a
> nearly drafted spec.  Is there an existing template for suggesting
> extensions?

The draft now says only that new extensions must define a keyword, so 
the presence of the extension can be tested.  We should add an 
extension registry mechanism to the draft, along the lines of what is 
in ACAP or perhaps POP Extensions.  That is, add an "IANA 
Considerations" section, spell out the requirements (for example, 
published in an IESG-approved experimental or standards-track RFC) and 
specify what information must be in the extension spec.  Given the fact 
that extensions could modify all sorts of Sieve behavior, we can't be 
too explicit. 

> Given that, I would still like to suggest that the tests "and" and "or" be
> defined in the draft spec. as synonyms, if not the primary names, for
> "allof" and "anyof", respectively.  The former are almost universally
> intuitively understood everywhere, whereas the latter are, let's say, unique
> to this draft.

This conflicts with one of the prime goals of Sieve, which is ease of 
implementation.  It was also discussed very early in Sieve development. 
Can you elaborate on why you feel the alternate syntax is required?