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
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.
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