Subject: issues list for SIEVE BOF

From: Tim Showalter <[email-masked]>
Date: 10 Mar 1999 14:29:39 -0500

Here's my unabridged issues list for the SIEVE BOF meeting.  Please send 
corrections, additions, arguments and flames to the list.

** sieve

Clarifications:

 * Site limits on actions: 

   actions encountered in scripts first are the ones executed?  (Scripts
   guaranteed to execute left-to-right, top-to-bottom.)

   - But what happens if limits on numbers of actions are exceeded?  Which
     ones are executed?  (Likely resolution: Clarify that the answer is the
     ones that are encountered first.)

 * Action interaction:

   What actions are legal with other actions?  Larry Greenfield and I tried to
   come up with a clean way of describing this, but failed; actions are just
   very different, and every new action we came up with suggested a different
   set of semantics.

   Proposal:
     - Discard is compatible with *everything* and is defined solely as
       cancelling the implicit keep.  (keep; discard; ==> keep;)
     - Reject is incompatible with everything except discard.

     Notes: 
       - Keep === fileinto "inbox".
       - Randy's demand for limitations are handled solely by the site limits
         on actions stuff; he just has a really low limit on stuff he can do.

 * Implicit keep

   We'd like to have some relation between action interactions and implicit
   keep, but couldn't come up with anything.  All basic actions and extensions 
   have to define what they do with the implicit keep.

   - Actions that cancel the implicit keep: reject, discard, fileinto, keep.
   - Actions that don't: vacation, redirect.
   - stop and require aren't considered actions.

 * Spec'ed minimums:
   - no more than one reject.
   - at least one fileinto or keep (if fileinto is supported)
   - at least one redirect must be allowed.

 * When is aborting out of a require that fails done, before or during
   execution?  (Likely resolution: whatever)

 * charset.  We are requiring decoding charsets to Unicode, but what about
   messages that are sent out (reject, vacation)?

   Proposal: Allow degrading to well-known character sets at the
   implementation's whim (if it's just an ASCII message, send ASCII; if it's
   not, implementations are permitted to degrade to ISO-8859 charsets if they
   so desire).

   Language tagging is handled for the Unicode case, which is really the
   interesting case.

 * Errors: what to say?

 * Move vacation into base spec?

 * Editorial:
   - stop and require moved to control actions section.

** sieve-vacation

 * Action interaction: vacation compatible with everything except reject.
 * Vacation DOES NOT cancel the implicit keep.

Vacation response monitoring: Not just per user (being responded to), but per
user, per message supplied in the script.  If message in the script changes,
delay is reset.

 * Is this okay?  (It could be rather expensive.)
 * Implementations MAY forget all about previous responses if the script
   containing the vacation call is changed?

 * Add requirement for implementation-dependant list of addresses that
   vacation never replies to, which MUST contain the address POSTMASTER (case
   insensitive) and may have other addresses?