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?