Subject: Managesieve

From: Simon Josefsson <[email-masked]>
Date: Sun, 05 May 2002 13:11:35 +0200

Any progress on the managesieve spec?  It seems to have expired from
the I-D repository.  I still think it is a good idea to have it
published.

Some comments:

+ Supporting both quoted and literal strings in all places makes it
  more difficult to implement the protocol without much gain.  The
  AUTHENTICATE "strings" must be base64 so quoted strings are
  sufficient.  The PUTSCRIPT and GETSCRIPT strings are probably only
  literals in practice.  Quoted strings are sufficient for SASL names.
  The only problematic one was the response-oknobye for PUTSCRIPT
  where it can contains multiline errors. In practice I think a long
  error doesn't make much sense, so I restricted it to just a quoted
  string.

+ It is not clear if the protocol is called "managesieve" or "sieve".
  I don't see much confusion arising from using "sieve" (which is used
  for the SASL service and /etc/service entry already), so I suggest
  this for brevity ("managesieve" looks ugly).

+ There is no URL syntax for a managesieve resource.

Patch:

--- draft-martin-managesieve-03.txt.orig	Sun May  5 12:28:48 2002
+++ draft-martin-managesieve-03.txt	Sun May  5 13:07:40 2002
@@ -36,9 +36,9 @@
 Abstract
 
     Sieve scripts allow users to filter incoming email. Message stores
-    are commonly sealed servers so users cannot log into them , yet
+    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 for securely managing Sieve scripts on a remote
+    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.
 
@@ -103,7 +103,7 @@
 
 8.     Author's Address  . . . . . . . . . . . . . . . . . . . . . .  18
 
-
+A.     URL Scheme  . . . . . . . . . . . . . . . . . . . . . . . . .  19

@@ -193,9 +193,9 @@
 
 1.3.  Syntax
 
-    This a line oriented protocol much like [IMAP] or [ACAP]. There are
-    three types: ATOMS, numbers and strings. Strings may be quoted or
-    literal. See [ACAP] for detailed descriptions of these types.
+    This a line oriented protocol much like [IMAP] or [ACAP]. There
+    are four types: ATOMS, numbers and quoed strings and literal
+    strings. See [ACAP] for detailed descriptions of these types.
 
     Each command consists of an atom followed by zero or more strings
     and numbers terminated by a newline.
@@ -634,9 +634,7 @@
     readable and SHOULD contain a specific error message giving line
     number of the first error. Implementors should strive to produce
     helpful error messages similar to those given by programming
-    language compilers. Client implementations should note that this may
-    be a multiline literal string with more than one error message
-    separated by newlines.
+    language compilers.
 
     Example:
 
@@ -807,7 +805,7 @@
                             command-putscript / command-capability / command-havespace /
                             command-starttls
 
-    command-authenticate  = "AUTHENTICATE" SP auth-type [SP string]  *(CRLF string)
+    command-authenticate  = "AUTHENTICATE" SP auth-type [SP quoted]  *(CRLF quoted)
 
     command-capability    = "CAPABILITY" CRLF
 
@@ -821,7 +819,7 @@
 
     command-logout        = "LOGOUT" CRLF
 
-    command-putscript     = "PUTSCRIPT" SP sieve-name SP string CRLF
+    command-putscript     = "PUTSCRIPT" SP sieve-name SP literal CRLF
 
     command-setactive     = "SETACTIVE" SP sieve-name CRLF
 
@@ -850,7 +848,7 @@
                             "TRANSITION-NEEDED" / "TRYLATER" /
                             resp-code-ext
 
-    resp-code-sasl        = "SASL" SP string
+    resp-code-sasl        = "SASL" SP quoted
 
     resp-code-ext         = iana-token [SP extension-data]
                             ;; unknown codes MUST be tolerated by the client
@@ -860,13 +858,13 @@
                             response-putscript / response-capability / response-havespace /
                             response-starttls
 
-    response-authenticate = *(string CRLF) (response-oknobye)
+    response-authenticate = *(quoted CRLF) (response-oknobye)
 
-    response-capability   = *(string [SP string] CRLF) response-oknobye
+    response-capability   = *(quoted [SP quoted] CRLF) response-oknobye
 
     response-deletescript = response-oknobye
 
-    response-getscript    = [string CRLF] response-oknobye
+    response-getscript    = [literal CRLF] response-oknobye
 
     response-havespace    = response-oknobye
 
@@ -875,7 +873,7 @@
 
     response-logout       = response-oknobye
 
-    response-oknobye      = ("OK" / "NO" / "BYE") [SP "(" resp-code ")"] [SP string] CRLF
+    response-oknobye      = ("OK" / "NO" / "BYE") [SP "(" resp-code ")"] [SP quoted] CRLF
 
     response-putscript    = response-oknobye
 
@@ -883,9 +881,9 @@
 
     response-starttls     = response-oknobye
 
-    sieve-name            = string
+    sieve-name            = quoted
+
 
-    string                = quoted / literal

@@ -1010,3 +1008,61 @@
 
 Expires November 6, 2001        Martin                         [Page 18]
 
+Internet Draft           Managing Sieve Scripts              May 1, 2001
+
+
+A.  URL Scheme
+
+      URL scheme name: "sieve"
+
+      URL scheme syntax:
+
+      Described using ABNF [RFC 2234] and ABNF entities from RFC 2396.
+
+      sieveurl = "sieve://" [ hostport ] "/" scriptname
+
+      scriptname = *pchar
+
+      Character encoding considerations: The script name, if present,
+      is in UTF-8.  Non-ASCII characters must be escaped as described
+      in RFC 2396.
+
+      Intended usage: A sieve URL identifies a sieve server or a sieve
+      script on a sieve server.  The latter always have the
+      application/sieve MIME type.
+
+      Applications and/or protocols which use this URL scheme name:
+      The protocol is described in this document.
+
+      Interoperability considerations.  None.
+
+      Security considerations:  None.
+
+      Relevant publications:  This document and RFC 3028.
+
+      Person & email address to contact for further information:
+      Author of this document.
+
+      Author/Change controller:  Author of this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires November 6, 2001        Martin                         [Page 19]
+

---

From: Marc Mutz <[email-masked]>
Date: Sun, 5 May 2002 14:20:43 +0200

On Sunday 05 May 2002 13:11, Simon Josefsson wrote:
<snip>
> +      sieveurl = "sieve://" [ hostport ] "/" scriptname
<snip>

s/hostport/server/

Do we need a way to activate a script via URLs? Like 
sieve://user@host/myscript1.siv?activate=1
?

Marc

- -- 
Marc Mutz <[email-masked]>

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 05 May 2002 18:27:50 +0200

[Resending to list with correct From: header]

Marc, thanks for your comments.  Comments inline.

>> +      sieveurl = "sieve://" [ hostport ] "/" scriptname

Use of server (to get username/password) is NOT RECOMMENDED according
to RFC 2396 and I kind of agree with their rationale.  But I'm sure
this issue come up with almost every URL syntax, so perhaps the "best
practices" for this has changed since 2396.  Any W3C/URI gurus here?
I don't care much either way, only that we should not go against
established procedures.

(Who came up with "NOT RECOMMENDED"?  I wish they had read RFC2119.)

> sieve://user@host/myscript1.siv?activate=1

Personally I dislike this abuse of URLs.  URLs should point to network
resources, not embed actions.  I know the history is full of bad
examples when it comes to these things; pop URL etc, but perhaps
that's not a good enough reason to perpetuate it.  Embedding username
and passwords is also an example of this abuse, and it is a
particulary bad one since it is not generic over all authentication
mechanisms (no way of expressing similar things for STARTTLS, GSSAPI
etc authentication), so in the end username/passwords gets used just
because it is easier to use it than other mechanisms, which has
security implications.

But again, I don't care much either way and if people think it is OK
then let's change it.