Re: managesieve: formats; :global; read-only; checkscript

[Alexey Melnikov <[e-mail]>]

Hi Дилян,

Дилян Палаузов wrote:

> Hello,
>
> Some more thoughts on ManageSieve:
>
> *FORMATS* Provided that a sieve-script can have textual 
> (application/sieve) format, and xml format 
> (draft-freed-sieve-in-xml-01) it would be interesting when a 
> managesieve-server can live with several possible sieve-formats.  I 
> would like to suggest adding a third optional parameter to PUTSCRIPT 
> and GETSCRIPT specifying the format of the sieve code. Strictly 
> speaking an intelligent ManageSieve server would recognize the format 
> automatically and a dummy server would return in GETSCRIPT the file as 
> it was uploaded (regardless of the format). However with a third 
> parameter to GETSCRIPT a server can be used for converting between xml 
> - application/sieve (- cyrus-sieve-bytecode).
>
>
> *:GLOBAL* Provided that draft-daboo-sieve-include is not dead, and 
> users can "include :global" it would be useful to provide 
> managesieve-possibilities to see how the global scripts are written.  
> My suggestion is to let the user see the global scripts, when the 
> authorization ID is the empty string.  In terms of the Sieve URL 
> Scheme, the global scripts could be accessible when owner = '\0'.  I 
> mean when
>          sieveurl-script = "sieve://" [ authority ] "/"
>                            [owner "/"] scriptname
> has the form
>          sieveurl-script = "sieve://" [ authority ] "//" scriptname
> then requested are the global scripts.

While I think having a standardized way of accessing global scripts 
would be a good idea, I am not convinced that the empty string is going 
to be Ok.
This might have some weird side effects on URI parsers (but I am not sure).

> *READ-ONLY* In this case however the users shall have only read-only 
> access on the global scripts and one more Response Code will be 
> appropriate READONLY (returned together with NO after PUTSCRIPT and 
> together with OK after AUTHENTICATE).
>
> This makes sense in one more case: Imagine there are sieve scripts, 
> that SMTP/ejerect-s mails from non-subscribers.  In this case the 
> people who manage the list might be interested to see how the script 
> looks like, but shall not to able to create mess by changing it.  As a 
> matter of fact for a list there could be more than one scrips 
> generated (e.g. for the address ...-unsubscribe@), so...
>
> Would be too weird if I propose a new command "LISTAUTHZ" (or alike) 
> listing the authorization IDs that can be used by the user with the 
> current authentication ID?

This creates security issues.
Besides the list of all allowed authorization ids might not be readily 
available.

> *CHECKSCRIPT* I don't like very much the command CHECKSCRIPT, cause 
> the same things can be achieved by using "" as first parameter to 
> PUTSCRIPT and allowing it in unauthenticated-state (incl. changing the 
> ABNF for PUTSCRIPT to permit sieve-name or empty-string as 1st 
> parameter). PUTSCRIPT "" provides the same flexibility as CHECKSCRIPT 
> and keeps the protocol simpler.

I am afraid you are going against rough WG consensus in this case.

> Moreover
>
> "LANGUAGE - ... Note that the current language MAY be per-user 
> configurable (i.e. it MAY change after authentication)."
>
> (How) shall a user be able to set a language?

It is not currently possible. An extension would be needed in order to 
add the ability to change a user's language.

> Greetings,
>     Dilian
>
>
> PS: The link at http://tools.ietf.org/wg/sieve/ to Draft dependency 
> graphs (http://www.fenron.com/~fenner/ietf/deps/viz/sieve.pdf) is not 
> working.

It seems to be working now.