Subject: [draft-melnikov-sieve-external-lists] Proposed Addition To Section 2.4

From: Robert Burrell Donkin <[email-masked]>
Date: Fri, 24 Jul 2009 12:38:51 +0100

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.

---

From: Barry Leiba <[email-masked]>
Date: Sat, 25 Jul 2009 14:23:29 -0400

> Use relative URIs to represent resources managed transparently by the

This was my thought as well, when Alexey first brought the idea up.
Originally, the idea was that the list name was just a string,
understood by the Sieve processor.  It quickly became clear that that
was problematic, and we should go with URIs.  Some thought they should
always be absolute, and I thought relative ones should be allowed.  We
batted that around for some while, and settled on absolute.

Apart from the reason you mention -- that it can be confusing -- the
main argument against using relative URIs is the difficulty in clearly
(and interoperably) defining what the relative ones mean.  Saying that
the Sieve processor understands what they mean ignores the real
problem with making sure the user (and/or the client) also understands
it.

I think we should stay with absolute URIs.

Barry

---

From: Aaron Stone <[email-masked]>
Date: Mon, 27 Jul 2009 16:07:36 -0700

> I think we should stay with absolute URIs.

[As IC:]

With the tag: URI scheme, you do get the effect of a server-specific URI,
and with a clear indication that that's what you're looking at (since it
begins literally with "tag:"). Does that address the concerns here?

Aaron

---

From: Aaron Stone <[email-masked]>
Date: Mon, 27 Jul 2009 17:01:26 -0700

> begins literally with "tag:"). Does that address the concerns here?

[Still an IC:]

Sorry, I didn't read the original comment and text. Of course this is
exactly what's at issue.

Personally, I'm concerned about potential ugliness of the identifiers if a
UI thinks it's hidden, but that's kind of an omnipresent issue around here.

I do like the idea of just writing ':list "MyList"' and not needed much
else. It does seem a bit overkill to be typing my own email address into
the Sieve script for the very same account.

Aaron

---

From: Barry Leiba <[email-masked]>
Date: Tue, 28 Jul 2009 03:39:00 -0400

> [As IC:]

"IC"?

> UI thinks it's hidden, but that's kind of an omnipresent issue around here.

Sorry; I can't make sense of that.  Try rephrasing?

> the Sieve script for the very same account.

I like the idea also, but I see the problems in interpreting it,
especially as one tries to move scripts form one implementation to
another.  I'll also point out that in most cases (us geeks
notwithstanding), the script will be generated under the covers.  So
the user might, indeed, just type "MyList", and the icky-looking URI
would be filled in for her.

Barry

---

From: Robert Burrell Donkin <[email-masked]>
Date: Thu, 30 Jul 2009 11:13:31 +0100

>> [As IC:]

<snip>

> I like the idea also, but I see the problems in interpreting it,

what difficulties do you see?

> another.

could you explain when - given a server instance capable of supporting
at least two sieve implementations and with access to resources mapped
by a relative URL - moving a script from one implementation to another
should create special difficulties?

- robert

---

From: Robert Burrell Donkin <[email-masked]>
Date: Thu, 30 Jul 2009 11:24:00 +0100

> I think we should stay with absolute URIs.

the location and interpretation of resources with arbitrary semantics
across arbitrary protocols is - i think - too difficult a problem to
be tackle by this draft. therefore, we should be satisfied now just by
specifying what we can and leaving these difficult interoperability
problems to other expert groups.

- robert

---

From: Robert Burrell Donkin <[email-masked]>
Date: Thu, 30 Jul 2009 11:32:08 +0100

<snip>

>  I'll also point out that in most cases (us geeks

how might such a generator discover how to map "MyList" to
"tag:MyList" (say) in an interoperable fashion?

- robert