Subject: Are option extensions exclusive?

From: Michael Haardt <[email-masked]>
Date: Thu, 12 Aug 2004 14:05:14 +0200

Hello,

there has been talk recently if commands have been extended with new
options, which is the case, although rare (:copy, the suggestion to
rework refuse into reject options).

IMHO, such extensions may be very useful, but so far I miss a
specification if multiple option extensions may be used together or not.

I can imagine three answers:

o  Option extensions are exclusive.  This makes it easy for the
   author to define the semantics, but some possibly useful
   combinations would be forbidden.
o  Option extensions can be used together.  Extensions are supposed
   to address completely different issues, thus not interacting
   badly.  I could imagine that existing implementations work that way
   and I prefer it.
o  The extension specifies if it is exclusive or not.  Do we need
   this freedom and does it make sense?

Anyway, it should be specified somewhere.  If it is, please just
point me to the relevant document.

Michael

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Thu, 12 Aug 2004 14:33:20 +0200

> specification if multiple option extensions may be used together or not.

I'd say: _obviously_ extensions which are registered with IANA can be
combined, no matter their mechanisms.  any exceptions to this must be
explicitly listed in the new extension.

>    this freedom and does it make sense?

yes.

> point me to the relevant document.

I don't see a great need, but I guess an update of RFC 3028 could
generalise this paragraph to include tests and options:

   Extension actions MUST state how they interact with actions defined
   in this specification.

e.g.

   Extensions MUST state how they interact with mechanisms defined
   in this specification.

-- 
Kjetil T.

---

From: [email-masked]
Date: Thu, 12 Aug 2004 07:03:22 -0700 (PDT)

> specification if multiple option extensions may be used together or not.

This is covered in the base sieve specification. Each extension has
a capability name associated with it. The name of each extension used
has to be listed in a require clause at the beginning of the script
before the extension can be used. An implementation that doesn't
support a given capability will refuse to run the script, and compliant
implementations are supposed to refused to run scripts that fail to list
all the capabilities they use.

It is possible, although certainly not encouraged, for two extensions hto
conflict with each other. (The most likely reason for this: An extension gets
specified, deployed, and then revised in an incompatible way. The capability
string would need to change if this happens. The one example we have of this so
far is the imapflags extension.) In this case an implementation can support
both but forbid both from being listed in the require clause at the same time.

Now, nothing about this is in any way specific to extensions that add
tests or actions; it also applies to extensions that add options to existing
commands.

>    combinations would be forbidden.

Extensions can be mutually exclusive, but normally won't be.

>    badly.  I could imagine that existing implementations work that way

This is the normal case.

>    this freedom and does it make sense?

I think it is fairly obvious that an extension that conflicts with another
extension would need to make that clear in its specification.

				Ned