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?
- IMAPFLAGS SIEVE extension Alexey Melnikov
- RE: IMAPFLAGS SIEVE extension Barry Leiba
- Re: IMAPFLAGS SIEVE extension Alexey Melnikov
- Proposed Sieve extensions Alan K. Stebbens
- RE: Proposed Sieve extensions (examples corrected) Alan K. Stebbens
- RE: Proposed Sieve extensions (replace corrected) Alan K. Stebbens
- Re: Proposed Sieve extensions Randall Gellens
- RE: IMAPFLAGS SIEVE extension Randall Gellens
- Re: IMAPFLAGS SIEVE extension Alexey Melnikov
- RE: Proposed Sieve extensions Alan K. Stebbens
- RE: Proposed Sieve extensions Randall Gellens
- Re: IMAPFLAGS SIEVE extension Randall Gellens
- Re: IMAPFLAGS SIEVE extension Alexey Melnikov
- RE: Proposed Sieve extensions Alan K. Stebbens
- Re: IMAPFLAGS SIEVE extension Randall Gellens
- Re: IMAPFLAGS SIEVE extension Matthew Wall
- Re: IMAPFLAGS SIEVE extension Ned Freed
- Re: IMAPFLAGS SIEVE extension Alexey Melnikov
- Re: IMAPFLAGS SIEVE extension Ned Freed
- Re: IMAPFLAGS SIEVE extension Alexey Melnikov