On Fri, Apr 13, 2007, Alexey Melnikov
<alexey(_dot_)melnikov(_at_)isode(_dot_)com> said:
Stephan Bosch wrote:
Hello Alexey,
Hi Stephan,
I am implementing a managesieve daemon and it seems that recent
(draft) changes to the sieve specification will conflict with the
current managesieve specification (at least the examples given therein).
The new sieve specification states in chapter 6 'Extensibility':
Any extensions to this language MUST define a capability string that
uniquely identifies that extension. Capability string are case-
sensitive; for example, "foo" and "FOO" are different capabilities. If
a new version of an extension changes the functionality of a
previously defined extension, it MUST use a different name. Extensions
may register a set of related capabilities by registering just a
unique prefix for them. The "comparator-" prefix is an example of
this. The prefix MUST end with a "-" and MUST NOT overlap any
existing registrations.
The latest managesieve draft gives the following example in section
1.8 'Capabilities':
S: "IMPlemENTATION" "Example1 ManageSieved v001"
S: "SASl" "DIGEST-MD5 GSSAPI"
S: "SIeVE" "FILEINTO VACATION"
S: "StaRTTLS"
S: "NOTIFY" "xmpp mailto"
S: OK
The capability fileinto for example is replied in upper case and the
sieve specifications currently define all extensions in lower case.
Good catch. I've fixed examples in my copy, so this will be fixed in -08.
I still don't understand why we've created the capability prefix registry
and then decided not to use it for notify. This seems silly:
S: "Implementation" "ManageSieved"
S: "SASL" "DIGEST-MD5"
S: "SIEVE" "fileinto vacation comparator-i;ascii-numeric"
S: "STARTTLS"
S: "NOTIFY" "xmpp mailto"
S: OK
I suggested this, but Alexey and others pointed out that it breaks extant
servers and clients quite badly:
S: "Implementation" "ManageSieved"
S: "SASL" "DIGEST-MD5"
S: "SIEVE" "fileinto vacation"
S: "STARTTLS"
S: "NOTIFY" "xmpp mailto"
S: "COMPARATOR" "i;ascii-numeric"
S: OK
Since we have existing implementations that expect comparator-foo, and we
created an IANA registry for extension prefixes, notify should use that:
S: "Implementation" "ManageSieved"
S: "SASL" "DIGEST-MD5"
S: "SIEVE" "fileinto vacation comparator-i;ascii-numeric notify-xmpp
S: notify-mailto"
S: "STARTTLS"
S: OK
In draft-ietf-notify-07, I suggest removing this from IANA:
8. IANA Considerations
The following template specifies the IANA registration of the notify
Sieve extension specified in this document:
- To: iana(_at_)iana(_dot_)org
- Subject: Registration of new Sieve extension
- Capability name: enotify
- Description: adds the 'notify' action for notifying user about the
- received message. It also provides two new test: valid_notify_method
- checks notification URIs for validity; notify_method_capability can
- check recipients capabilities.
- RFC number: this RFC
- Contact address:
- The Sieve discussion list <ietf-mta-filters(_at_)imc(_dot_)org>
This information should be added to the list of sieve extensions
given on http://www.iana.org/assignments/sieve-extensions.
And replace with this (follows the format used in draft-3028bis-12):
Capability name: enotify
Description: adds the 'notify' action for notifying a user via
some external method that a message has arrived,
adds the 'valid_notification_method' test to check
a notification URI for validity,
adds the 'notify_method_capability' test to check
if a notification method supports additional
capabilities.
transport sender and recipient address
RFC number: this RFC (Sieve notify base spec)
Contact address: The Sieve discussion list
<ietf-mta-filters(_at_)imc(_dot_)org>
Capability name: notify-* (anything starting with "notify-")
Description: adds the indicated notification method for use
with the notify action
RFC number: this RFC (Sieve notify base spec)
Contact address: The Sieve discussion list
<ietf-mta-filters(_at_)imc(_dot_)org>
I think we also need a notification capability registry for the
notification method documents to register their method-specific
capabilities with. The test in draft-ietf-sieve-notify-07.txt is this:
This document defines a single notification-capability value
"online", which is described below. Additional notification-
capability values may be defined by a Standard Track or Experimental
RFC.
Is that sufficient without an IANA registry?
Aaron