Subject: managesieve comments

From: Cyrus Daboo <[email-masked]>
Date: Mon, 09 Dec 2002 14:00:10 -0500

Some comments on the managesieve -04 draft based on client implementation 
experience:

Comments on Manage SIEVE

- According to the current IANA registry port 2000 is already assigned to 
'callbook'. Looks like we have to pick another default port?

- STARTTLS command description still has text stating that server must send 
capability items.

- 'sieve-name' item in formal syntax is just defined as 'string'. Why not 
just use 'string' instead? If you want to impose the semantic script name 
requirement, then the 'sieve-name' item should have a comment with a 
reference to section 1.7.

- 'command-authenticate' is missing the mandatory CRLF at the end. The 
correct syntax should be:

    command-authenticate  = "AUTHENTICATE" SP auth-type [SP string]
                            *(CRLF string) CRLF

- 'extension-data' in 'resp-code-ext' is not defined in this document. It 
is in ACAP, but there is no comment about dependency on ACAP formal syntax 
for undefined items here. Either add 'extension-data' in this doc or add 
reference to ACAP in the formal syntax introduction paragraph.

- There is no support for disconnected/multi-access behaviour. In 
particular, a client has to always upload a script before making it active 
as it has no way of knowing whether the one it uploaded in a previous 
session has been changed by some other client. This will be an issue for 
large scripts. The fix for this would be to have some kind of modtime or 
uid stamp for each script - this is probably not necessary right now, but 
may become important later.

-- 
Cyrus Daboo

---

From: Tony Hansen <[email-masked]>
Date: Mon, 09 Dec 2002 16:54:16 -0500

Cyrus Daboo wrote:
> 
> Some comments on the managesieve -04 draft based on client 
> implementation experience:
> 
> Comments on Manage SIEVE
> 
> - According to the current IANA registry port 2000 is already assigned 
> to 'callbook'. Looks like we have to pick another default port?

We don't pick ports -- IANA assigns them.

The port should be listed as TBA (to be assigned), and a note put in the 
IANA Considerations section indicating that they need to register a port 
for this purpose.

	Tony Hansen
	[email-masked]

---

From: Marc Mutz <[email-masked]>
Date: Mon, 09 Dec 2002 23:02:35 +0100

On Monday 09 December 2002 20:00, Cyrus Daboo wrote:
> Some comments on the managesieve -04 draft
<snip>

Oh, you have a copy? Can you send it?

Marc

-- 
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.      -- Benjamin Franklin

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 09 Dec 2002 18:26:32 -0500

Hi Marc,

--On Monday, December 9, 2002 11:02 PM +0100 Marc Mutz <[email-masked]> wrote:

|> Some comments on the managesieve -04 draft
| <snip>
|
| Oh, you have a copy? Can you send it?

Try:

<ftp://ftp.ietf.org/internet-drafts/draft-martin-managesieve-04.txt>

-- 
Cyrus Daboo

---

From: Lyndon Nerenberg <[email-masked]>
Date: Mon, 09 Dec 2002 16:42:33 -0700

>may become important later.

Can we just let the server return the MD5 digest of the script?

--lyndon

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 09 Dec 2002 19:08:16 -0500

Hi Lyndon,

--On Monday, December 9, 2002 4:42 PM -0700 Lyndon Nerenberg 
<[email-masked]> wrote:

|> - There is no support for disconnected/multi-access behaviour. In
|> particular, a client has to always upload a script before making it
|> active  as it has no way of knowing whether the one it uploaded in a
|> previous  session has been changed by some other client. This will be an
|> issue for  large scripts. The fix for this would be to have some kind of
|> modtime or  uid stamp for each script - this is probably not necessary
|> right now, but  may become important later.
|
| Can we just let the server return the MD5 digest of the script?

That would work. Are you suggesting a new command to return the MD5 of a 
named script?

I was thinking in IMAP terms of introducing a UID command and have that 
modify existing command behaviour:

UID LISTSCRIPTS - this would return the list of scripts with the UID for 
each script listed in the responses.

UID PUTSCRIPT - this would return the new UID as a response code in the OK 
response if it succeeded.

UID SETACTIVE - the client would provide a UID value in the command, and if 
that did not match the UID for the stored named script, the command would 
fail.

One could consider UID command for DELETESCRIPT and GETSCRIPT but I'm not 
sure of the value of those.

-- 
Cyrus Daboo