[Top] [All Lists]

Re: Future directions for the ManageSieve draft

2006-12-04 14:12:52

On Mon, Dec 4, 2006, Sebastian Hagedorn <Hagedorn(_at_)uni-koeln(_dot_)de> said:

[Alexey 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


as a user of smartsieve, easysieve, Mulberry and other tools that use 
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:

    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

    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.