[Kolab-devel] [UPDATE] KEP #14: Non-conflicting edits of RFC5228/Sieve scripts by multiple editors

[Jeroen van Meeuwen (Kolab Systems)]

On 15.09.2011 12:39, Georg C. F. Greve wrote:
> Dear all,
>

Hi Georg,

we seem to be close to wrapping up this one! Thanks for the updates.

> Based on Jeroen's feedback and including some other, smaller points, 
> KEP #14
> has seen an update which does not dramatically change the function, 
> but
> clarifies a couple of points, and also establishes a little bit more 
> fine
> grained rules for the editors themselves for the various cases.
>
> The updated version is online at
>
>   KEP #14: Non-conflicting edits of RFC5228/Sieve scripts by multiple 
> editors
>   http://wiki.kolab.org/User:Greve/Drafts/KEP:14
>
> and your review and feedback would be appreciated as we'd like to 
> move this
> towards closing soon. Consider this your last call to provide input. 
> :)
>

== Random Ramblings ==

- I think 'imapflags' as been a draft RFC implemented with Cyrus IMAP 
2.3 (current Kolab deployments), and has been replaced with an 
'imap4flags' Sieve extension RFC[1] (current + future Kolab 
deployments); imap4flags however is not a supported extension in Cyrus 
IMAP currently. I *think* this (sort of) compatibility may need to be 
noted as well. I *think* client scripts have little opportunity to 
discover the Sieve extensions supported by a server.

[1] http://tools.ietf.org/html/rfc5232

- A Sieve editor SHOULD check the use of namespace prefixes and 
hierarchy separators, for example:

     fileinto "INBOX/Spam";

   will only work on a server with 'altnamespace: 0' and 
'unixhierarchysep: 1' configured, whereas:

     fileinto "Spam";

   on a server with 'altnamespace: 1' configured would work (despite 
unixhierarchysep: setting), and

     fileinfo "Shared Folders.spam";

   will only work on a server with 'altnamespace: 1' (where you can 
rename the shared folder prefix from 'shared'), 'unixhierarchsep: 0' 
(re-introduces the '.' (dot) folder hierarchy seperator) and 
'sharedprefix: Shared Folders' configured.

   I think a Sieve editor SHOULD do so when retrieving the script as 
well as when uploading the script.

   Optionally, as the Sieve script is executed with "user privileges", 
perhaps access to the folders referred to could be checked (MAY? 
SHOULD?) -including setting flags ('w' right), posting messages ('p' 
right), maintaining seen state ('s' right) and (future!) setting message 
annotations ('n' right). Let's also note that the admin ('a' right) does 
not imply / include any of the other rights, though the user effectively 
does have permissions to alter the Access Control Entry (ACE) associated 
with the user's Access Control Information (ACI subject).

   Note that the NAMESPACE command in IMAP will give the client the full 
details on both 'altnamespace' and 'unixhierarchysep' that it needs.

== KEP Remarks ==

* A 'different, supported editor', and 'different editor' both come 
very close to "the editor MAY offer the user the possibility for the 
editor to take ownership and SHALL require positive confirmation".

== Language Tweaks ==

* "Editor MAY allow the user to edit the script if the user requests 
that the editor take ownership of this script"

Editor MAY allow user to edit, SHALL require positive confirmation, 
MUST take ownership?

* "a manually written script"

A manually maintained script?

* "It MAY attempt to parse and display, but it MUST never modify this 
script."

   (...) it SHALL NOT modify this script. "MUST never" is barely used in 
any RFC, and places that "must never" is used do not capitalize / 
emphasize 'must'.

Kind regards,

Jeroen van Meeuwen

-- 
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +44 144 340 9500
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08