Hello!
On Mon, Sep 28, 2009 at 03:11:57PM -0400, Jeffrey Hutzelman wrote:
--On Monday, September 28, 2009 10:15:19 AM -0700
NED+mta-filters(_at_)mauve(_dot_)mrochek(_dot_)com wrote:
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.
In other words, the behavior is undefined, and the implementation can do
whatever it wants. This sort of thing is fairly common in protocol and
langauge specifications, including some which are considerably more formal
and exhaustive than typical IETF specifications. See, for example, ANSI C.
Frankly, I consider C a bad example. C uses undefined and unspecified
behaviour in order to achieve performant execution for a relatively
low-level programming language. Sieve is a relatively high-level
language. Java would perhaps be a slightly more apt comparison, and I
think there's much less "undefined" or "unspecified" behaviour (even
though I haven't read the whole language specification yet).
Back to Sieve, I *do* see the need to leave room for implementors in
some areas. Sieve is used in different kinds of mail delivery (or even
other) scenarios, so interaction with the environment can vary. I *do*
see it as reasonable that e.g. the validity of mailbox names for
fileinto (if supported at all) may vary. I *do* see reason to leave room
for when to check the validity of strings that interpolate variables,
e.g. not forcing constant propagation onto implementors, i.e. allowing
to check every string value (e.g. of comparator names) at runtime.
But as an implementor who has compiler construction background, I see
the boundaries different. Specifications should, in my eyes, be
well-defined. If they intend "unspecified" or "undefined" semantics,
they should explicitly say so, so users *see* they may cause demons to
fly out of their nostrils. If they intend to allow only a limited
freedom to implementors, they should say so. A relatively good example
in Sieve specifications is the way numbers are defined, they *have*
to be unsigned, they *have* to have at least a specified range (so
users may rely on that), they *may* have a larger range. I say
*relatively* good, as users can't test for the exact range the
implementation permits, so allowing a bigger range isn't of so much use
anyway.
HTML is another bad example. Because implementations varied too widely,
*and because they were too tolerant*, one has created a mess and in fact
*hampered* interoperability. Stricter specifications (e.g. fewer or
even *no* optional tags or optional close tags, which would've been even
possible with SGML) and the early reference implementation(s) being
actually strict according to the specifications would perhaps have been
good for interoperability.
If Sieve leaves too much open for implementors to decide, and at the
same time, not even the implementations are registered and *announced*
(e.g. using a capability), it hinders interoperability. One might need
to code a script this way for site A and that way for site B even if
both support the set of extension the script needs.
Kind regards,
Hannah.
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve