Subject: Review comments on draft-martin-managesieve-04.txt

From: [email-masked]
Date: Fri, 17 Oct 2003 09:08:41 -0700 (PDT)

It was recently mentioned on the imapext list that it is time to get
the managesieve protocol spec moving forward. So I decided to take a look
at the specification as it stands. My comments are as follows:

(0) In keeping with IESG feedback on the sieve subaddress specification, I
    think the title needs to be changed to "A Protocol for Remotely Managing
    Sieve Email Filtering Scripts".

(1) The second paragraph of the introduction regarding ACAP should only
    appear in the introduction (see next point), not in the abstract.

(2) This specification really needs an introduction. Currently the
    introduction section is blank. I suggest an extended version of the
    abstract, something along the lines of:

  Scripts written in the sieve [SIEVE] language allow users to specify
  filters for the email they receive. Typically each user of a message
  store can have his or her own private sieve script or scripts.
  However, message stores are commonly sealed servers so users cannot
  log into them, yet users must be able to update their scripts on them.

  This document describes a protocol "sieve" for securely managing Sieve
  scripts on a remote server.  This protocol allows a user to have multiple
  scripts, and also alerts a user to syntactically flawed scripts.

  This an interim measure as it is hoped that eventually Sieve scripts
  will be stored on ACAP. This document is intended to proceed on the
  experimental track.

(3) Section 1.1 needs to be marked as needing to be removed prior to
    publication.

(4) Sections 1.3 and later really don't belong as subsections of the
    introduction. I suggest moving all of these up a level.

(5) Section 1.3, first paragraph, second sentence. Three types of what?
    Tokens? And why is ATOMS capitalized?

(6) It seems to me section 1.3, Syntax, should provide a prose description
    of the syntax of responses as well as that for commands.

(7) The bit about the port number in section 1.3 really needs to be in a
    section other than one on syntax. Perhaps a section of its own is
    appropriate? It could contain the usual prose about how managesieve
    servers listen for connections on TCP port <tbd>. It also should be
    make it clear that the prose about port 2000 needs to be removed prior
    to publication.
   
(8) Section 1.7 and probably elsewhere. "UTF8" -> "UTF-8".

(9) Sieve script names are UTF-8 identifiers, and as such would seem to me
    to be subject to UTF-8 normalization concerns. The usual way this is
    dealt with is to specify an appropriate stringprep scheme to use. (Indeed,
    the specification appears to be silent on whether or not even ASCII
    script names are case sensitive.) I'm tempted to say that the right
    course of action is to simply reuse the nameprep stringprep profile
    defined in RFC 3491, but this assumes case-insensitivity is what you want.

(10) Section 1.8, paragraph prior to example. "any other capabilities given" ->
     "any capabilities given".

(11) Section 2.1, second example. There probably should be an ellipsis or
    something similar at the begining to indicate these aren't the first
    commands in a session.

(12) Section 2.8. Should make it clear any previously active script is
     deactivated. There's also the question of what happens to the currently
     active script when SETACTIVE is specified with a bogus script name.
     Does the currently active script remain active or is no script active
     after this is done? Need to be specific either way.

(13) Section 3, Sieve URL scheme. A couple of problems here. First, the
     function of this URL scheme needs to be stated in prose prior to the
     registration template. Second, given that the URL can either be
     used to identify either a managesieve server or a script on that
     server, doesn't the scriptname have to be an optional part of the
     URL? Third, I think the name "sieve" is too general for any URL
     scheme in this document -- it is entirely possible there will be other
     URLs that deal with sieve in some way. I suggest "managesieve" instead. 
     And finally, the usage section talks about a "sieve server". Isn't
     this a "managesieve" server?

(14) Section 4, ABNF. The rules iana-token and extension-data
     aren't defined in this specification and the only external rules that
     are inherited are the ones from the base ABNF specification. It looks
     to me like the reference for these rules that needs to be added is
     ACAP (RFC 2244). And there's also the issue of references to the
     sieveurl ABNF given in section 3. The simplest way to deal with this
     would be one more sentence saying it also refers to the sieveurl
     production defined in section 3.

(15) Section 5, second paragraph. Doesn't TLS, properly implemented, also
     provide protection against passive observation and MITM attacks?
     A pointer to the security considerations for sieve itself in RFC 3028
     would probably be a good thing to add as well.

(16) This document needs an IANA considerations section that tells IANA
     to register the URL scheme defined in section 3 and to assign a port
     for the managesieve protocol to use.

(17) Reference to [imap4rev1] needs to be updated from RFC 2060 to RFC 3501.

(18) References need to be split into normative and informative groups.

(19) Indentation of first reference doesn't match the rest.

(20) The required IPR boilerplate section is missing from this document.
     See, say, RFC 3598 section 8 for what this needs to contain.

That's it!

				Ned

---

From: "Madan Ganesh Velayudham" <[email-masked]>
Date: Sat, 18 Oct 2003 00:15:59 +0530

Martin,

	Recently I have given a draft on "organize extension" in imap. 
	I'm new to mta-filters group. Pls correct me if I'm wrong.

	I would like to participate in managesieve too.

	2.7 LISTSCRIPTS.

	Can we have an [ script-name ] optional parameter to this 
	command to list the given script-name. 

	In GETSCRIPT/DELETESCRIPT, I'm not clear whether
	regular expression are entertained. Pls clarify. 
	Otherwice can we have a defined keyword like ALL.

	GETSCRIPT ALL

	DELETESCRIPT ALL

	Thoughts please.

	+MG

---

From: [email-masked]
Date: Fri, 17 Oct 2003 22:21:03 -0700 (PDT)

> 	command to list the given script-name.

Why? Getting the content of the script is what GETSCRIPT is for.

An optional argument specifying a pattern to match script names to
return would make sense. However, I don't think it is particularly
useful since it seems quite unlikely a single user will have so many
scripts that filtering the list is necessary.

> 	Otherwice can we have a defined keyword like ALL.

Again, why? You use LISTSCRIPT to list the scripts available, then use
GETSCRIPT to get the scripts you want. Adding facilities to GETSCRIPT
to return more than one script would require adding additional
structure to responses to delimit and identify multiple scripts.

> 	Thoughts please.

I don't any of these changes are either necessary or useful.

				Ned

---

From: "Madan Ganesh Velayudham" <[email-masked]>
Date: Sat, 18 Oct 2003 15:28:05 +0530

> Why? Getting the content of the script is what GETSCRIPT is for.

	When I gone through the draft, I co-related things with unix
commands 
	ls and cat.

	If I just want to know whether a script is there or not,
LISTSCRIPT would 
	return all the script names.
	like,
	ls filename

> Again, why? You use LISTSCRIPT to list the scripts available, 
> then use GETSCRIPT to get the scripts you want. Adding 
> facilities to GETSCRIPT to return more than one script would 
> require adding additional structure to responses to delimit 
> and identify multiple scripts.

	I just thought that adding some more flexibility to that would
be a value add.

	If I have n scripts and If I want to delete scripts which start
with a*. I will 
	do LISTSCRIPT, then delete one by one which requires more
server/client interactions.
	Rather DELETESCRIPT a* which would remove all the scripts and
require only one server/
	client interaction.

	For GETSCRIPT, if I compare with 'cat'. I thought it is useful.

	+MG

> 
> An optional argument specifying a pattern to match script 
> names to return would make sense. However, I don't think it 
> is particularly useful since it seems quite unlikely a single 
> user will have so many scripts that filtering the list is necessary.
> 
> Again, why? You use LISTSCRIPT to list the scripts available, 
> then use GETSCRIPT to get the scripts you want. Adding 
> facilities to GETSCRIPT to return more than one script would 
> require adding additional structure to responses to delimit 
> and identify multiple scripts.
> 
> > 	GETSCRIPT ALL
> 
> > 	DELETESCRIPT ALL
> 
> > 	Thoughts please.
>

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Sat, 18 Oct 2003 12:56:43 +0200

On Sat, 2003-10-18 at 11:58, Madan Ganesh Velayudham wrote:
> commands ls and cat.

it is better to compare the protocol to the Unix system calls:
readdir(2) and  open(2)/unlink(2).  you can't specify a pattern to
either of these, that work is left to the client application (actually
sh(1), not ls(1) or rm(1)).

-- 
Kjetil T.

---

From: "Madan Ganesh Velayudham" <[email-masked]>
Date: Sat, 18 Oct 2003 16:52:32 +0530

> > 	When I gone through the draft, I co-related things with 
> unix commands 
> > ls and cat.
> 
> readdir(2) and  open(2)/unlink(2).  you can't specify a 
> pattern to either of these, that work is left to the client 
> application (actually sh(1), not ls(1) or rm(1)).

	Excellent comment ! I agree.
	
	My only concern was that client and server systems could be 
	different, ie., In between network comes into picture. The
	no. of transactions between server and client also matters.

---

From: [email-masked]
Date: Sat, 18 Oct 2003 06:22:54 -0700 (PDT)

> 	return all the script names.

OK.

> 	I just thought that adding some more flexibility to that would

Only if it is a genuinely useful feature. This has to be weighed against the
complexity of the facility and the cost of implementation. In this particular
case the complexity cost is not completely trivial given that we'd be dealing
with utf-8 globs or worse, regexps.

> 	Rather DELETESCRIPT a* which would remove all the scripts and

Sure, but that presupposes client interactions are at a premium here.
I don't think they are.

> 	For GETSCRIPT, if I compare with 'cat'. I thought it is useful.

Useful in some abstract sense, perhaps. But I don't think the benefits
outweigh the costs.

All IMO, of course. Others may feel differently.

				Ned

---

From: "Madan Ganesh Velayudham" <[email-masked]>
Date: Sat, 18 Oct 2003 19:26:33 +0530

Thanks for sharing your thoughts.

> All IMO, of course. Others may feel differently.

	Since I'm new to filters, I did not get what IMO means ?

	+MG

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Saturday, October 18, 2003 6:53 PM
> To: Madan Ganesh Velayudham
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> Subject: RE: Clarification on draft-martin-managesieve-04.txt ?
> 
> 
> 
> > 	If I just want to know whether a script is there or 
> not, LISTSCRIPT 
> > would
> > > Again, why? You use LISTSCRIPT to list the scripts 
> available, then 
> > > use GETSCRIPT to get the scripts you want. Adding facilities to 
> > > GETSCRIPT to return more than one script would require adding 
> > > additional structure to responses to delimit and identify 
> multiple 
> > > scripts.
> 
> > 	I just thought that adding some more flexibility to 
> that would be a 
> > value add.
> 
> Only if it is a genuinely useful feature. This has to be 
> weighed against the complexity of the facility and the cost 
> of implementation. In this particular case the complexity 
> cost is not completely trivial given that we'd be dealing 
> > 	If I have n scripts and If I want to delete scripts 
> which start with 
> > a*. I will
> > 	Rather DELETESCRIPT a* which would remove all the 
> scripts and require 
> > only one server/
> > 	client interaction.
> 
> Sure, but that presupposes client interactions are at a 
> premium here. I don't think they are.
> 
> Useful in some abstract sense, perhaps. But I don't think the 
> benefits outweigh the costs.
>

---

From: [email-masked]
Date: Sat, 18 Oct 2003 07:23:28 -0700 (PDT)

> 	Since I'm new to filters, I did not get what IMO means ?

IMO means In My Opinion.

				Ned

---

From: Rob Siemborski <[email-masked]>
Date: Sun, 19 Oct 2003 12:09:41 -0400 (EDT)

> All IMO, of course. Others may feel differently.

For what its worth, I agree that these features add significant
implementation complexities and don't see much benefit in the real world.

Its very rare that we see users with more than one script stored on the
server at any given time.  Maybe this would change if there was an
"include" sieve functionality (actually, I seem to remember seeing a draft
for this at one point), but even then I don't see this being a frequent
occurance.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

---

From: Marc Mutz <[email-masked]>
Date: Sun, 19 Oct 2003 18:30:58 +0200

On Saturday 18 October 2003 11:58, Madan Ganesh Velayudham wrote:
<snip>
>         Rather DELETESCRIPT a* which would remove all the scripts and
<snip>

v04 of the managesieve draft requires command pipelining support. You 
can write a _lot_ of DELETESCRIPT commands in one packet.

Marc

-- 
There's a lot of "throwing the baby out with the bathwater" going on,
but the bathwater is so foul that many companies don't mind the
occasional loss of baby. -- Bruce Schneier on spam filters,
                            Crypto-Gram 07/2003

---

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 21 Oct 2003 15:52:42 -0400

> scripts that filtering the list is necessary.

I would agree that there is no necessity of having an argument to
LISTSCRIPTS.  However, some wording about namespace might be in
order.  It may be true that a single user will not have a lot of
scripts, but a single user may have a lot of files hanging around.
The server will need to be able to determine which files are scripts.
It would probably be enough to say that this is outside the scope of
the document, and is implementation-specific and all that, but still
it might be said somewhere that the scripts collection is identifiable
somehow.

[ I was going to muddy the waters by talking about script libraries,
and individuals being able to publish there, but it looks like that's
in another thread. ]

But this leads me to a couple of tangential comments.

In the managesieve thread(s) there have been the comments that:

 - a user will not have many script files;
 - a user will only have one active script.

I do not think either is necessarily true, and I think this is a
deficiency in the managesieve outline.  There is at least one mail
system (qmail) where an individual user can manage multiple email
addresses through different control files.  The user might have
multiple domain names being delivered to their account via different
control files in that account.  And with qmail each address can be
extended, with each extension being controlled individually.
Some of this control *can* be mapped through the same place, but
that's not always the best thing to do.

At anyrate, each email address (or address space) that the user is
responsible for can have its own set of controls, including a filter
for that address.  And in fact each control can have more than one
action in nsequence, e.g.:

  1.  Apply first filter
  2.  first filter passed, take some other action
  3.  Step 2 passed, apply second filter
  4.  etc.

Here one would have 2 active filters for a single destination (and
one might have multiple destinations for a single user).  This may
sound like a pathological invention, but it is not.  Personally
I would like to see some consideration for:

 - selection of destination address space within a user space;
 - selection of filter step within a destination address space.

I also think it would be more interesting to talk about "manage mail
delivery filter" rather than "manage sieve".  Do we have to lock
the manage interface into the filter language being used?

There are more comments but they relate more to the document than
to this message, so I'll take a breath :-)

-mm-

---

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 21 Oct 2003 16:44:10 -0400

> at the specification as it stands. My comments are as follows:

Hi-

A few comments:

As I mentioned in another note, I think it would be worth making the
interface a little more generic: rather than being sieve-specific,
allow it to be used for whatever sort of scripting language is
officially available on the mail server.  There could be more than one
such language available.

I would also like to see support for address-space for the
authenticated user.  A user might have different controls for various
email addresses that are mapped to that user's account.  My own
account here receives mail for a number of different addresses and
domains, each with its own control area and associated filter(s).  I
doubt that I'm the only one that would like to be able to individually
manage filters for different address spaces under my control.  Thus
I'd like to see this interface take multiple address/filter spaces
into account.  Each address space might also (or might not, depending
on the server configuration) have its own namespace for filters, so
that "myscript" for [email-masked] could be a different file than
"myscript" for [email-masked] .

Perhaps an optional argument to PUTSCRIPT/GETSCRIPT/SETACTIVE/etc that
indicates the specific address space:

    PUTSCRIPT :address-space "[email-masked]" "myscript"
    PUTSCRIPT :address-space "[email-masked] "myscript"
    SETACTIVE :address-space "[email-masked]" "myscript"

HAVESPACE:  Is there really a point to this?  PUTSCRIPT will already
tell you if the operation fails due to quota.  There's no guarantee
that resource availability at HAVESPACE-time will be the same as the
availability at PUTSCRIPT-time.  Not only that, but I could imagine
that a for given implementation you would not be able to predict the
required space for a script (say, if PUTSCRIPT caused a compiled
version to be stored along with the source).  For a variety of
reasons, HAVESPACE doesn't necessarily tell you what would happen if
you try to upload a script.

PUTSCRIPT/GETSCRIPT:  Regarding this:
  putscript "myscript" {nnn+}
    nnn bytes

I'm not really fond of that byte-counted argument imapism in this
context.  Am I the only one?  I'd much prefer to see some sort of
terminated content a la SMTP.

-mm-

---

From: Marc Mutz <[email-masked]>
Date: Wed, 22 Oct 2003 02:18:22 +0200

Hi Mark,

On Tuesday 21 October 2003 22:44, Mark E. Mallett wrote:
> > It was recently mentioned on the imapext list that it is time to
> > get the managesieve protocol spec moving forward. So I decided to
> > take a look at the specification as it stands. My comments are as
> > follows:
<snip>
<snip>

Thanks for your comments, but I don't think that we should talk about 
new features in managesieve such as those you detailed in this thread 
_now_. That opens all sorts of cans of worms as anyone tries to push 
his or her pet feature.

managesieve is implemented at least in the Cyrus server suite and at 
least Mulberry and KDE have client implementations for this protocol. 
It's not that we start from scratch here. Some things you asked for 
might be nice to have - but as an _extension_. Others, like supporting 
different script languages might never be implemented. And there's 
certainly no room to debate whether size literals are to be used or not 
- they are already.

Marc

-- 
It seems that the only thing worse than being an enemy of the US is
being a close friend and ally.
     -- John Horvath, "The Meaning of Friendship", Telepolis #14395

---

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 21 Oct 2003 21:13:13 -0400

Hi-

> certainly no room to debate whether size literals are to be used or not 

Hmm- maybe I should have started out by asking what the real draft
status was (as opposed to the "expired" status on the document).  I
understand that some drafts exist to sanctify existing implementations,
others (such as various other sieve drafts out there) to work out how
to do things.  Sounds like this one is the former.  That's kind of a
shame, because what you call "pet features" I, well, don't.  As you
might expect :-)  Not to mention that any call for discussion seems
moot now.

Sorry to hear about the size literals being mandated by an existing
implementation.  It's not a make-or-break thing with me, I just don't
like them.  I'll live.

Yours,
-mm-

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 22 Oct 2003 22:21:07 +0200

On Tue, 2003-10-21 at 22:44, Mark E. Mallett wrote:

> email addresses that are mapped to that user's account.

you could just as easily set up each e-mail address as an account in
Managesieve.

the use of the extensions "include" (still in draft form) and
"subaddress" (RFC 3598) is probably more convenient for most people.

> availability at PUTSCRIPT-time.

sounds like a reasonable argument.  I don't remember the rationale for
it?

> terminated content a la SMTP.

terminated content a la SMTP means dot stuffing.  I don't think that's a
cleaner solution.

-- 
Kjetil T.

---

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 22 Oct 2003 17:16:37 -0400

> you could just as easily set up each e-mail address as an account in

That would be cumbersome as a general solution.

> "subaddress" (RFC 3598) is probably more convenient for most people.

Yup, I did mention that that sort of thing was an option (although not
the best one).

mm

---

From: "Madan Ganesh Velayudham" <[email-masked]>
Date: Thu, 23 Oct 2003 14:41:42 +0530

> I would agree that there is no necessity of having an 
> argument to LISTSCRIPTS.  However, some wording about 
> namespace might be in order.  It may be true that a single 
> user will not have a lot of scripts, but a single user may 
> have a lot of files hanging around. The server will need to 
> be able to determine which files are scripts. It would 
> probably be enough to say that this is outside the scope of 
> the document, and is implementation-specific and all that, 
> but still it might be said somewhere that the scripts 
> collection is identifiable somehow.

These comments would avoid assumption during implementaion. Agreed