[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ManageSieve: sieve: URIs and OWNER capability
Thanks again for your detailed review.
I think message I will reply to your question about the new OWNER
Stephan Bosch wrote:
- Explain the purpose of the OWNER capability. Common question would
be: clients already know their identity, so why advertise it as a
capability? Also, in my mind, listing status information in a
capability response seems hardly appropriate.
I wanted to post a message on this change, but you were quicker than me.
Chris Newman suggested in his original ManageSieve review 3 changes
related to Sieve URIs:
* IMAP URLs made the mistake of confusing the identity used to
authenticate with the identity that owns the script. This makes IMAP
URLs cumbersome. I would strongly encourage a naming model that
separates the two and keeps the script owner explicit. For example:
sieveurl-script = "sieve://" [ authority ] "/" owner "/" scriptname
As per mailing list discussions a modified version of this syntax was
adopted by the draft, so I've decided to address one of the 2 remaining
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.
2. Add a capability that advertises the owner name that applies to a
given managesieve session (this would be derived from the
[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.