[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
managesieve: formats; :global; read-only; checkscript
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.
*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?
*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
"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?
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