[Top] [All Lists]

Re: ManageSieve: sieve: URIs and OWNER capability

2008-11-25 16:39:42

On Tue, 2008-11-25 at 20:54 +0000, Alexey Melnikov wrote:
Alexey Melnikov wrote:


Then two other changes would make this particularly useful:
1. Allow a script name (at least in putscript) to be either a Sieve URI
or a local name.  This allows, for example, a secretary to set the
script for her boss.

We've discussed this in more details in Minneapolis and the room 
agreement was that ManageSieve commands should accept URIs in addition 
to script names.
However, I am having second thoughts on this.

1). It looks like at least the following commands would need to be updated:

But LISTSCRIPTS returns script names. Should it be changed to return 
URIs? I think this would break all existing clients, so I don't think 
that an unextended version of LISTSCRIPTS should do that.

Also, should it list *all* scripts accessible by the current user, or 
just personal scripts? The former seems like an extension that Dilian 
was talking about.

2). Considering that Sieve script names are in Unicode it would also 
make sense to specify IRI version of Sieve URIs. I frankly don't have 
experience specifying IRIs.

So my current thinking is that these changes might have undesired 
effects on existing clients and they also seem to require quite a bit of 
But I really want to get this document done (for Lemonade/OMA MEM among 
other things). So can we postpone this change till an extension?

+51% wait to work on an extension. Now that we've enumerated some more
of the issues URI's raise, I think it's likely we'll get really stuck on
working out the details.

Is there another way that we can achieve the goal of one user modifying
another user's Sieve scripts that's not too ugly and can easily become
URI in a future revision?

Is there a path we might agree on for merging Sieve management into IMAP
protocol, and cease work on ManageSieve at some reasonable level of

2. Add a capability that advertises the owner name that applies to a 
given managesieve session (this would be derived from the 
authentication id).

[I think Chris meant "authorization identity" above.]

So, OWNER corresponds to 2). When using SASL authentication a client 
can authenticate as one person ("authentication identity"), but be 
allowed to act as another ("authorization identity"). OWNER is 
returning the latter.

I have a weak preference for having the OWNER capability. So far I 
found a couple of reasons for it:

Imagine you have a ManageSieve client that need to process several 
Sieve URIs (e.g. to update several scripts).
The client would be able to compare the "owner" part of an URI against 
the value returned in the OWNER capability in order to decide if it 
needs to authenticate as another user before processing another script 
identified by a URI.

I also think that the OWNER capability can be useful for debugging 
(i.e. for analyzing protocol trace logs). Of course this only helps if 
the client requests capabilities after authentication.

I've missed another obvious use case: constructing URIs to give them to 
third parties.

It would be a shame if the Sieve URI's ended up being like email message
ID's -- they look like something that you could use to uniquely identify
and retrieve a message from somewhere in the universe, but not really.