Subject: Re: Future directions for the ManageSieve draft

From: Sebastian Hagedorn <[email-masked]>
Date: Mon, 04 Dec 2006 13:00:15 +0100

Hi,

--On 30. November 2006 15:57:07 +0000 Alexey Melnikov 
<[email-masked]> wrote:

> I've recently submitted draft-martin-managesieve-07.txt. I would like to
> get some feedback from people on whether the ManageSieve document should
> try to document what is currently deployed, or whether it should be
> changed to make ManageSieve more consistent with protocols like IMAP and
> ACAP.
>
> Thoughts?

as a user of smartsieve, easysieve, Mulberry and other tools that use 
ManagSieve I'd prefer the draft to document what's currently deployed.

Cheers, Sebastian
-- 
     .:.Sebastian Hagedorn - RZKR-R1 (Gebäude 52), Zimmer 18.:.
Zentrum für angewandte Informatik - Universitätsweiter Service RRZK
.:.Universität zu Köln / Cologne University - ✆ +49-221-478-5587.:.
                   .:.:.:.Skype: shagedorn.:.:.:.

---

From: "Aaron Stone" <[email-masked]>
Date: Mon, 4 Dec 2006 20:58:14 -0000

On Mon, Dec 4, 2006, Sebastian Hagedorn <[email-masked]> said:

[Alexey wrote:]
> ManagSieve I'd prefer the draft to document what's currently deployed.

Indeed, there are a sufficient number of interoperable implementations
right now that we probably have to treat -06 as written in stone, much
like imapflags vs. imap4flags because the former was so widely deployed.

I have two issues with -07, with the way that the NOTIFY extensions are
listed. I don't dislike the proposal, but it will necessitate an API
change for me, and it entails a normative reference on NOTIFY, doesn't it?
What about future extensions that also need reporting to the user
interface? I think it would be better to make it a generic extension
reporting mechanism. Text:

OLD: 
    NOTIFY - A space separated list of URI schema parts for supported
    notification methods. This capability MUST be specified if the
    Sieve implementation supports the "enotify" extension
    [NOTIFY].

Proposed:
    Other extensions - For each extension supported by the Sieve
    implementation that defines a registry, an additional capability
    response MUST be returned in the format:
        "ExTenSion" "registryitem1 registryitem2"

This drops the reference to NOTIFY, and gives us a generic mechanism for
future extension registries to be reported to the client.

Aaron

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 05 Dec 2006 00:17:32 +0000

>like imapflags vs. imap4flags because the former was so widely deployed.
There are many problems with existing clients in handling of strings 
(some clients expect only quoted or only literal strings in some places) 
and in handling of SASL authentication exchanges when "additional data" 
is not sent with "success indicator".
This concerns me. ManageSieve interoperability seems to be worse then 
IMAP interoperability.

>change for me,
Can you elaborate?

>and it entails a normative reference on NOTIFY, doesn't it?
>  
>
By the time ManageSieve document is approved for publication, the NOTIFY 
extensions should be already published ;-). So I think this is a non issue.

>reporting mechanism.
All future ManageSieve extensions will have to be registered with IANA, 
so I don't see much point in providing generic syntax.

How does this change avoid the API change you've mentioned above?

Alexey

---

From: "Aaron Stone" <[email-masked]>
Date: Tue, 5 Dec 2006 16:58:35 -0000

> This concerns me. ManageSieve interoperability seems to be worse then 

Ok, I am not sure where to begin tackling this. Is it as simple as "make a
chart of implementations, and test if they respond correctly to certain
inputs?" What's the usual process for wrangling a spec and implementations
like this one?

>>listed. I don't dislike the proposal, but it will necessitate an API

I have a function call to return all extensions. I'll need to add an
argument specifying which set of extensions to retrieve.

> extensions should be already published ;-). So I think this is a non issue.

Uh, I've heard that before...

> so I don't see much point in providing generic syntax.

How many are we looking at right now?

The only things on my mind are how to specify scripts for IMAP actions and
for MTA/MDA actions. Given the discussion on the recent thread about
multiscript, there are a lot of multiscript implementations! I would
certainly prefer to manage my multiscripts via ManageSieve.

What else is in mind? (I'm not trying to use a crystal ball to write all
extensions into the base spec, just want to get a handle on what we're
looking at right now.)

> How does this change avoid the API change you've mentioned above?

It doesn't. But it does suggest that I shouldn't have a function call
specific to the notify extensions, but rather generic to a variety of
extensions.

What about comparators? How are those discovered? I haven't had time to
look at all the Sieve extensions to see which ones have registries, but I
wonder if they each need to have a ManageSieve block. It also introduces a
reference from the extension onto ManageSieve. Does that hold up some of
the extensions and force a document approval order for the WG? What about
extensions with registries that are already published?

Aaron

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 05 Dec 2006 17:23:35 +0000

>How many are we looking at right now?
None at the moment.

>certainly prefer to manage my multiscripts via ManageSieve.
Sure. This might be one potential candidate.

>specific to the notify extensions, but rather generic to a variety of
You can still have a generic function, now that you are aware of the 
issue :-)

>What about comparators? How are those discovered?
>
The same way as other Sieve extensions, in the SIEVE capability:
"IMPLEMENTATION" "Isode M-Box SIEVED server 12.0v0"
"SIEVE" "fileinto reject envelope vacation imapflags notify subaddress 
copy comparator-i;ascii-numeric relational spamtest refuse regex"
"SASL" "PLAIN OTP NTLM LOGIN DIGEST-MD5 CRAM-MD5"

>I haven't had time to look at all the Sieve extensions to see which ones have registries,
>
In general Sieve extensions don't need to be specially registered with 
ManageSieve.
All Sieve extensions appear automatically in the "SIEVE" ManageSieve 
capability.

>but I wonder if they each need to have a ManageSieve block.
>
See above.
But even if they do, this can be done in a separate document.

>It also introduces a reference from the extension onto ManageSieve.
>
If registrations are done in a separate document, there is no need to 
have dependencies from the Sieve extension to the ManageSieve document.

>Does that hold up some of the extensions and force a document approval order for the WG?
>
In general, dependencies between document delay publication (after 
approval), until all normatively referenced documents are published.

>What about extensions with registries that are already published?
>  
>
Alexey

P.S. I was a bit brief in my comments, let me know if you need more 
detailed explanations from me.

---

From: "Aaron Stone" <[email-masked]>
Date: Tue, 5 Dec 2006 17:33:20 -0000

> Sure. This might be one potential candidate.

Is this something we might want to tackle in the base document by adding
the option for arguments following script names in relevant actions?

> "SASL" "PLAIN OTP NTLM LOGIN DIGEST-MD5 CRAM-MD5"

Right, ok, so why a new capability section for notify when we could add to
the existing "SIEVE" block a couple of "notify-method1 notify-method2"
entries?

Or should we break comparators out, and have responses like:

"SIEVE" "fileinto vacation subaddress envelope relational"
"COMPARATOR" "i;ascii-numeric"
"NOTIFY" "email xmpp"
"SASL" "plain cram-md5"

> detailed explanations from me.

No worries, thanks for the uber-fast reply, too :-)

Aaron

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 05 Dec 2006 18:24:10 +0000

>the option for arguments following script names in relevant actions?
I am not entirely sure what you recommend. Can you give an example?

>the existing "SIEVE" block a couple of "notify-method1 notify-method2"
We could, but notification methods and Sieve extensions names are in 
different namespaces, so in theory, they may conflict.

>"COMPARATOR" "i;ascii-numeric"
We could, but this would be a change that breaks deployed software ;-).

>"NOTIFY" "email xmpp"
<pedantic>"mailto xmpp"</pedantic>

---

From: "Aaron Stone" <[email-masked]>
Date: Tue, 5 Dec 2006 19:07:35 -0000

>>>>certainly prefer to manage my multiscripts via ManageSieve.
[snip]
> I am not entirely sure what you recommend. Can you give an example?

I'll get back to you on this. I need to find some time to distill the
recent thread about multiscript and take another look at IMAP Sieve.

Aaron

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 05 Dec 2006 19:38:49 +0000

Aaron Stone wrote:

>inputs?"
If you or somebody else would want to help with testing interop, that 
would help and would be appreciated.

>What's the usual process for wrangling a spec and implementations like this one?
>  
>
Having implementation experience helps in convincing ADs to publish a 
document, however this is not required for publishing a document as a 
Proposed Standard.
Interop report is needed when moving a document to Draft Standard. But 
we are nowhere nearly there for ManageSieve ;-).

---

From: Aaron Stone <[email-masked]>
Date: Thu, 07 Dec 2006 00:48:07 -0800

> recent thread about multiscript and take another look at IMAP Sieve.

Ok, here's what I'm thinking. In IMAP-SIEVE we have this section:

2.3.  New Functions Defined by IMAPSieve

2.3.1.  Changes to Manage Sieve

   [[Manage Sieve placeholder: This section is a placeholder right now,
   for changes to the Manage Sieve protocol.  We'll fill in more detail
   on the next iteration of this draft.]]

   Manage Sieve [Manage] is a protocol for managing Sieve scripts.  We
   define here an extension to that protocol to support multiple active
   scripts, each serving a different function.  The extension here will
   allow us to tell the IMAP server which script to use for which
   mailbox(es) for the conditions described in this document.  No Sieve
   script is invoked for an IMAP condition unless Manage Sieve has
   defined a script for it, and has "turned on" filtering for a
   particular mailbox or set of mailboxes.

Well, let's hack into it!

We need a few new actions:

LISTSCRIPTSEXT an extended version of LISTSCRIPTS that allows additional
atoms following the script names. The base spec only gives the ACTIVE
atom. Since it doesn't suggest that there might be other atoms, it's
entirely possible that implementations will explode if we just tossed
more atoms on the regular LISTSCRIPTS.

Atoms: ACTIVE, GLOBAL, ACT-IMAP-APPEND, ACT-IMAP-MULTIAPPEND,
ACT-IMAP-COPY, SMTP-THIS, SMTP-THAT [[since we've never had a Sieve SMTP
draft, have we?]]

Anyways, these additional atoms should correspond to the IMAP actions
that trigger a Sieve script and to the SMTP actions / delivery processes
that trigger a script in a multiscript delivery path.

SETACTIVEEXT an extended version of SETACTIVE that takes optional
arguments for the location of the script and the trigger.

e.g.:
    SETACTIVEEXT [trigger-atom] [GLOBAL] "scriptname"

and by extension:
   DELETESCRIPTEXT [GLOBAL] "scriptname"
   PUTSCRIPTEXT [GLOBAL] "scriptname"
   GETSCRIPTEXT [GLOBAL] "scriptname"

Ok, some rough ideas, but getting them out there.

Aaron