Subject: [draft-melnikov-sieve-external-lists] 2.2 Allow Extensions To Use List

From: Robert Burrell Donkin <[email-masked]>
Date: Thu, 30 Jul 2009 13:24:55 +0100

Proposal - Clarify Expected Behaviour For Unsupported Tests
===========================================================
Change
------
Require implementations to raise a compile time error when list
is used with an unsupported test.
Rationale
---------
Adopting a single clear rule on error handling increases interoperability.
Requiring a compile time error seems cleaner than alternatives such as
silently failing the test.

Proposal - Allow Extension Tests To Use Link
============================================
Change
------
Add explicit permission for implementations to support list for other
tests.
Rationale
---------
Extensions which find "list" useful should be encouraged to use it
as described.

Use Case: Mailing List Local Test
---------------------------------
if mailinglist :list "tag:example.org,2009-07-24:IEFT" {
   fileinto "standards";
}

--------------------------------------------------------------------------
[1] Proposal
--------------------------------------------------------------------------

2.2.  :list match type

   ABNF:

      MATCH-TYPE  =/ ":list"
           ; only valid for supported tests

   The new ":list" match type changes the interpretation of the "key-
   list" parameter to supported tests.  When the match type is ":list",
   the key-list becomes a list of names of externally stored lists.
   The external lists are queried, perhaps through a list-specific
   mechanism, and the test evaluates to "true" if any of the specified
   values matches any member of one or more of the lists.

   Implementations MUST support "address", "envelope" and "header" tests.
   Implementations MAY support other tests but MUST raise a compile
   time error when a script contains any standard test where support has
   not been explicitly specified.

--------------------------------------------------------------------------
[2] Original Text
--------------------------------------------------------------------------

2.2.  :list match type for "address", "envelope", and "header" tests

   ABNF:

      MATCH-TYPE  =/ ":list"
           ; only valid for "address", "envelope", and "header" tests

   The new ":list" match type changes the interpretation of the "key-
   list" parameter to the "address"/"envelope"/"header" test.  When the
   match type is ":list", the key-list becomes a list of names of
   externally stored lists.  The external lists are queried, perhaps
   through a list-specific mechanism, and the test evaluates to "true"
   if any of the specified values matches any member of one or more of
   the lists.

---

From: Ned Freed <[email-masked]>
Date: Thu, 30 Jul 2009 08:05:54 -0700 (PDT)

This proposal seems OK to me.

				Ned

---

From: Barry Leiba <[email-masked]>
Date: Thu, 30 Jul 2009 13:36:23 -0400

> is used with an unsupported test.

That's already what happens when there are such errors in scripts.
Why should we say it explicitly here, and not everywhere else?

>    not been explicitly specified.

Not explicitly specified by whom?  How?

How does this make scripts portable?  This seems to encourage private
extensions, which has really become a thorn in the web.

Barry

---

From: Robert Burrell Donkin <[email-masked]>
Date: Fri, 31 Jul 2009 09:58:41 +0100

> Why should we say it explicitly here, and not everywhere else?

philosophically, i believe in full and complete specifications, with
any areas of variance clearly indicated

practically, as the draft 00 stands, i feel that an implementator
might reasonably elect to test the combination of test and match-type
at compile time, at run time or not verify the condition at all. my
strong preference would be to just issue a warning with an option for
raising a runtime error.

so, though my implementation preference would be excluded by this
proposal, at least the expected behaviour would be clearly specified

> Not explicitly specified by whom?  How?

yes - i'm not happy with the wholley language either

probably better just to specify those tests which should not be supported

> How does this make scripts portable?

i'm a little confused by this

when a script contains an extension, it will only compile on engines
that support that extension. asking extensions to abide by the
description of list in this draft (if they support it) means that at
least that may be relied upon by the script writer.

> This seems to encourage private

an extremely controversial statement ATM (but i'm going to avoid
taking the bait)

happily, sieve is extensible so this philosophical question has
already been resolved in the original specification. i think that a
revision of RFC 5228 would be the right place to start for anyone who
disagrees with this fundamental design decision.

what needs to be decided by this working group is whether the group
thinks that list should work uniformly across all extensions

- robert