Proposal
========
Use relative URIs to represent resources managed transparently by the
Sieve Engine.
Rationale
=========
A little syntactic sugar to simplify scripts.
For example, the following forms might be functionally equivalent:
redirect :list "tag:example.com,2009-05-28:mylist"
redirect :list "MyList"
but the relative URI form is more concise.
Disadvantages
=============
* It is not obvious that the list name is an URI. Some users may therefore
be surprised to learn that URI naming rules apply.
Sample Use Cases
================
Shared Blacklist Maintained By The System Administrator
-------------------------------------------------------
if address :list "/blacklist" {
discard;
}
Shared Distribution List Maintained By The System Administrator
---------------------------------------------------------------
redirect :list "/staff"
Private Whitelist Maintained By The System For The User
-------------------------------------------------------
if header :list "from" "MyFriends" {
keep;
}
--------------------------------------------------------------------------
[1] Proposed Insertion
--------------------------------------------------------------------------
2.4. Syntax of an externally stored list name
A name of an externally stored list MUST be an URI [URI].
2.4.1 Relative URIs
A relative URI MAY be interpreted by a Sieve engine as a reference to
a list service resource managed by the implementation. An
implementation which does not support relative URIs SHOULD raise an
error at compile time when a list name is a relative URI.
2.4.2 Absolute URIs
An absolute URI indicates an external list processing resource.
Implementations might find URLs such as [LDAP], [CardDAV], or
[etc, continuing as per original]
--------------------------------------------------------------------------
[2] Original Text
--------------------------------------------------------------------------
2.4. Syntax of an externally stored list name
A name of an externally stored list is always an absolute URI [URI].
Implementations might find URLs such as [LDAP], [CardDAV], or
[TAG-URI] to be useful for naming external lists.
The "tag" URI scheme [TAG-URI] can be used to represent opaque, but
user friendlier identifiers. Resolution of such identifiers is going
to be implementation specific and it can help in hiding the
complexity of an implementation from end users. For example, an
implementation can provide a web interface for managing lists of
users stored in LDAP. Requiring users to know generic LDAP URL
syntax might not be very practical, due to its complexity. An
implementation can instead use a fixed tag URI prefix such as "tag:
example.com,<date>:" (where <date> can be, for example, a date
generated once on installation of the web interface and left
untouched upon upgrades) and the prefix doesn't even need to be shown
to end users.