ietf-mta-filters
[Top] [All Lists]

Re: [sieve] Notify (RFC 5435) questions

2009-09-28 17:46:30
On Mon, Sep 28, 2009 at 10:36 AM, Hannah Schroeter 
<hannah(_at_)schlund(_dot_)de> wrote:
Section 3.4. Notify Tag ":importance" says that the :importance tag
specifies a numerical value from one through three as a string. However,
it doesn't specify what happens when a script fails to comply with that,
i.e. the string specifies a different number, or not a number at all

What happens is the same as what happens with any other syntax error:
it causes a compile-time error (or, if variable substitution is used,
a run-time error after the variable substitution).

If you want to overload the term "syntax error" this way, fine, but it is then
important to distinguish between the core Sieve syntax as specified in the pase
specification and the layered syntax requirements imposed by specific tests and
actions.

It is quite clearly an error, detectable at compile time, for a sieve to have
invalid core syntax. So this case is easy.

But what about layered syntax requirements? THings get very tricky very
quickly. For one thing,  if there's a sentence in the specifications that say
"anything not conforming to any layered syntax requirements MUST, in the
absence of more direct guidance, be treated as an error" I for one don't know
where it is. The absense of such a statement is why I believe this to be
implementation-specific at the present time.

And adding such a requirement - assuming it isn't already there - is trickier
than you might think. One example where it is decidedly nontrivial is the
reason parameter in vacation when :mime is used. Perhaps you think that
requiring that sieve engines check the MIME syntax in this case is a good idea;
I most emphatically do not and I will state right now that I would have zero
problem violating any sort of requirement that says such a check should be done
on the grouns of total asininity.

This doesn't fit with the ductus of other parts of the spec (such as
:from, or the parameter method) where error handling or ignoring things
(e.g. from values that are syntactically correct but not allowed for the
script owner for policy reasons) are clearly specified.

I don't know what "ductus" means, but this isn't a case of policy.
There's no need to say specifically what happens if a script violates
the grammar in this case, because we know what to do when a script
violates the grammar in general.

Again, there are two levels of grammar here, and violations of them don't
necessary have the same implications.

By the way, the ABNF suggests that the number has to be given literally,
but the specification doesn't spell it out whether that really implies
the :importance parameter has to be a *constant* string in the sense of
the variables extension.

We thought it was clear that these were strings, which could be put in
as variables, but I see how it can be confusing.  The intent is
certainly that variables may be used here.  Perhaps we should enter an
erratum suggesting a comment in the ABNF that makes this clear.

I think that's a really bad idea because it puts us on the slippery slope of
specifying all the places where variables can be used. Unless we then go
through every specification and every parameter and add similar text will lead
people to the erroneous conclusion that variables can only be used in places
where the specifications say they can.

If this is in any way unclear - and I don't think it is - the place to explain
it better is in the variables specification. In fact as I recall the notion of
explicitly calling out all the placesa where variables can be used was
consideered during the development of that specifications and summarily
rejected.

                                Ned
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve

<Prev in Thread] Current Thread [Next in Thread>