Hello!
On Mon, Sep 28, 2009 at 10:15:19AM -0700, Ned Freed 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
(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.
Was a false friend from my native language. I meant something like the
style of other parts of the specification which were clearer about
errors - which errors have to be handled strictly and which have to be
handled in a tolerant manner (e.g. :from syntax errors vs. valid syntax
but not viable values for policy reasons).
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.
So you mean to imply IETF specs are meant with users, not implementors
as audience? At least I read "descriptive" as "describe to users what's
actually implemented out there" and "proscriptive" as "tell implementors
what they ought to do".
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.
Other wrongs don't make this wrong better. (I'd have liked those match
types to be keywords in the whole, like :value_eq ... or two keywords in
order, like :value :eq, btw.)
The vacation
specification doesn't say what to do if a :mime reason argument is not found to
be valid MIME. And so on.
Other specifications *do* tell, like the email address syntax for
redirect.
I'd like to look at the good examples more than the bad examples.
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,
Therefore the quotes.
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.
It would be just one sentence. Either "if the string is not exactly
equal to one of the three possible value, it is an error" (perhaps insert
reference to section 2.10.6. of the base spec) or "if ..., the
:importance parameter is ignored and the default is used".
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.
And there have been quite loose specifications that have not proved to
bee good for interoperation, like HTML.
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.
That's what the variables extension says, yes.
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.
In principle you're right. And usually I read the specifications so. But
here, the ABNF-like notation suggests otherwise. Btw, your above example
was good, as in the relational extension, the ABNF-like notation for the
match types also suggests otherwise. There are other places where the
specifications have such not so explicit contradictions and could need
some clarification in my eyes, like the use of variable names in the
imap4flags extension in the hasflag test and in the setflag, addflag,
and removeflag actions. Especially the latter actions look like they are
parallels to "set", just with a bit different evaluation of the *value*
that is stored into the variable. In "set", the variable name (target of
the store) is *constant*. In *that* place, I would think a clarification
would be appropriate.
So
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
constant)?
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
that.
In many other places, the fact that e.g. variables are expanded by
default is not so obscured by suggestive ABNF-like notation.
Btw, I just see that the ABNF-like notation is
[":importance" <"1" / "2" / "3">]
In ABNF, the quotes are *metasyntax*, so the spec is contradictory here,
anyway. From ABNF, that would imply a keyword and a *number*, not a
keyword and a string! Of course, the text clears it up well enough
`The ":importance" tag is followed by a numeric value represented as
a string'
So *if* the specification is amended, it *could* be changed into
[":importance" <value:string>]
and value could be explained in the text below. The "string" would be
clear enough to imply variable expansion (just as in :from, etc.) and
the text could be clarified to say what to do if the value of the string
is not "1", "2", or "3". As said, one sentence could probably be enough.
Kind regards,
Hannah.
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve