Subject: Re: [draft-melnikov-sieve-external-lists] 2.2 Allow Extensions To Use List
From: Robert Burrell Donkin <[email-masked]>
To: [email-masked]
Cc: MTA filtering mailing list <[email-masked]>
Date: Fri, 31 Jul 2009 09:58:41 +0100
List-Id: <ietf-mta-filters.imc.org>

On Thu, Jul 30, 2009 at 6:36 PM, Barry
Leiba<[email-masked]> wrote:
>> Require implementations to raise a compile time error when list
>> 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?

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

>>    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.
>
> 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
> extensions, which has really become a thorn in the web.

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