[Top] [All Lists]

Re: [sieve] Notify (RFC 5435) questions

2009-09-28 13:45:40

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
(the latter could have been avoided if one had specified the parameter
of :importance as a number to begin with).

Which generally should be taken to mean it is up to the implementation to
decide how to handle such a case. IMO throwing an error would be fine, but so
would silently ignoring the parameter.

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 think you mean "dictus", not "ductus", here.

In any case, while I generally beleive tightening up specifications is a Good
Thing, this reading goes MUCH too far. IETF specifications are in general
descriptive, not proscriptive, in nature. it is therefore unreasonable to
expect that every specification is going to cover exactly what to do
with every possible input.

Indeed, I can think of many other cases where the handling of bogus inputs
aren't specified. For example, the relational specification doesn't say what to
do when an unknown string is given to :value or :count. The vacation
specification doesn't say what to do if a :mime reason argument is not found to
be valid MIME. And so on.

And it's not "justified" by being delegated to method specific handling,
as RFC 5435 itself *does* specify it to be the string representation of
a number from one through three.

It isn't a question of justification, it's a question of reaonsableneess and
specification readability. Tying down every possible loose end in every
possible case sounds like a great idea until you  see the text that results,
which often ends up so laden with incredibly obscure exceptional cases
implementors end up missing the important stuff.

There are plenty of formal language specifications that have been written with
exhaustive or near-exhaustive proscriptive text. It has not proved to be recipe
for successful interoperation.

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.

I don't think this is unclear at all. Variables operates at a level between
syntactic processing and semantic interpretation. As such, unless variable
substutions are specifically prohibited by a given parameter, they are allowed.

Having to state whether or not variable substition can be done in every case
would again be a recipe for vast specifciation bloat with useless garbage text.

  1. Is the parameter of :importance a *constant* string (as the ABNF
     suggests) or can it expand variables (as the variables extension
     says all strings do if one uses it unless *explicitly* told to be

The latter.

  2. If the string of the parameter doesn't specify a number at all,
     is that an error or is the parameter silently ignored and the
     default importance ("2") used?

That's currently up to the implementation to decide.

  3. If the string of the parameter *does* specify a number, but one
     out of range, is that an error or is it ignored? In the latter
     case, is the default importance used or is the number clipped
     to the range (from below 1 to 1, from above 3 to 3)?

This is the same as 2.

  4. Are leading zeroes tolerated as the *text* suggests "a numeric
     value represented as a string" or not, as the ABNF suggests,
     [":importance" <"1" / "2" / "3">]?

I don't think the text suggests that, which reduces this to 2 again.

Again, if pepple think it is worth tightening up the text regarding the
:importance parameter, or other specification locations, I have no problem with
that. But this should not translate into searching around and adding such text
everytwhere. Our specifications will be the worse for it if twe were to do

sieve mailing list

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