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?