Hi! I've just read the sieve-notify-01 draft closely for the first time.
Here are some questions and comments.
Meta:
- It has expired, and I notice that there were some discussions on the
mailing list last July and a promise of a new version soon -- what is
its status now?
- The draft's header lists the title incorrectly as
<draft-ietf-sieve-notify-01.txt>.
3.1 Notify action
- I'd have expected an IANA registry that lists and fixes the
methods and options and corresponding require: tags.
Having these implementation-defined features without a way
of verifying them makes me uneasy.
Everything else in sieve is quite predictable; scripts as a whole
either fail because they use unimplemented features or have well-defined
meaning -- and here, all of a sudden, is this big, powerful,
implementation-defined area that sends out messages that sometimes
costs money without the author being able to automate verification
that what they think a script means actually means it.
- > The format of the notification is implementation-defined.
> However, all content specified in the notify action, including Sieve
> actions taken on the message, SHOULD be included.
If I understand this correctly, you would like the notification to
include a complete log of the sieve actions taken on the message, which
goes beyond "the content specified in the notify action"; it would
also include pieces of sieve script before and after the line that
issues the notification. Right?
- > If errors occurred in another action they SHOULD be reported
> in the notification.
And later:
> Failures of other actions MAY be reported in the notification.
This is in direct conflict with a rule in the sieve RFC 3028:
> When an error occurs in a Sieve script, all processing stops.
[2.10.6]
Variables
- I would like $env-from$ (and related variables, if you add them)
defined with a reference to the sieve "envelope" operator, not to
RFC 2?821. (The envelope used in sieve might not be an SMTP
envelope.)
- I strongly agree with the past discussion asking for more control
over the formatting and over which parts are chosen.
- In practice, I think limiting the length even of $from$ (and its
related variables) and certainly of $subject$ would be a good thing.
(Alternatively, allow implementation-defined limits on these things. )
When I have completely free hand, I tend to truncate single-line
texts in the middle, like this:
Subject: [mailing-list] This is a long ta ... cess and a frog.
It would be nice to be allowed to do this, but it's kind of
difficult to specify. (Maybe something is truncated in an
implementation-defined manner to no more than N characters.)
In response to July's discussion of whether this should be
counting chars or bytes, for SMS, it only makes sense to count
output bytes, not chars, since the limits one is trying to fit
into are byte limits.
3.2 Denotify Action
- This surprised me. Couldn't generic sieve control structures be used
to accomplish the same with fewer constructs and thus a simpler
language?
I'd hate to see a precedent set where other, future extensions, in
addition
to their specified action, also include an action-specific cancellation
mechanism!
I don't really have much experience with this mechanism; maybe it's
handy
if you write a lot, and complex, sieve scripts. But this is supposed to
be simple and small; I don't feel like this powerful mechanism fits
that.
Thanks!,
Jutta Degener
<jutta(_at_)sendmail(_dot_)com>