On Tue, Dec 5, 2006, Alexey Melnikov
<alexey(_dot_)melnikov(_at_)isode(_dot_)com> said:
Aaron Stone wrote:
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.
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.
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?
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,
Can you elaborate?
I have a function call to return all extensions. I'll need to add an
argument specifying which set of extensions to retrieve.
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.
Uh, I've heard that before...
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.
All future ManageSieve extensions will have to be registered with IANA,
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