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.