Hello!
On Wed, Sep 09, 2009 at 10:47:11AM -0700, Ned Freed wrote:
On Wed, Sep 09, 2009 at 12:04:01PM -0400, Cyrus Daboo wrote:
--On September 9, 2009 6:01:20 PM +0200 Hannah Schroeter
<hannah(_at_)schlund(_dot_)de> wrote:
[...]
I'm stalled with the Date/Index Extensions a bit because of a few things
that are unclear to me.
- Index extension: It seems it is not specified what happens if the
index is out of range, that is it's greater than the number of headers
actually found for the header names given to the test.
if header :index 5 "Received" "..."
if there are only 4 Received headers, for example.
The test is supposed to fail in this case. I agree the RFC could be clearer
about this.
Thanks for the heads on (I'm not fond of the wording "fail" for "return
false", as people not firm with the language used could more easily
confuse it with "error" or "temporary failure" than if one said "return
false" or "not match", but that's a general language issue with the
Sieve test specifications; sorry for the side note, if it's noise for
you). As you say at the end of your mail, there might be a clarification
or revision on the RFC, anyway, so one could include that.
The base specification uses the phrase "returns false" for this sort
of thing so that's what I plan to use here as well.
For this, I've gone on and made the test fail (not match) - even for
:contains with an empty key -, but the RFC doesn't explicitly say
this (in contrast to for example yielding a run-time error).
That's the correct behavior.
- The index extension doesn't specify its behaviour with respect to
:count tests. (The date extension does.)
For header, is it meant to yield 1 if the index is in range, 0
otherwise? And for address, the number of addresses in the one
selected header line (if the index is in range)?
The meaning of :count is tied to the test being performed. :index only
restricts the applicability of the test to a specific header field
occurannce;
it does not change the interpretation of count in any way. So, when :index is
used with header, :count produces a 1 if the specific header with that index
exists, 0 otherwise. Address is more useful; it would return a count of all
the
addresses in the header. Date would again be a 0 or 1 depending on the
existance of the header and whether or not it contains a valid date.
I don't see a need for further clarification here.
I do.
On one hand, yes, one can second guess the authors of the RFCs, as you
did, and as I did, too (but still asked). Our common conclusion is the
same, so it looks like a very reasonable second guess, that one can
deduce from the text of the specs,
There is no second guessing involved. This is simply a matter of reeading
what's there in the relevant specifications. RFC 5231 is quite clear on how
:count interacts with header and address tests, and RFC 5260 explains how it
interacts with date. All :index does is restrict the set of headers the test
can see. It does not change the semantics of :count in any way.
It would of course be possible to reiterate what RFC 5231 says, but
reiterating one specification in another is almost never a good idea.
RFC 5231
The COUNT match type first determines the number of the specified
entities in the message and does a relational comparison of the
number of entities, as defined below, to the values specified in the
test expression.
You need to read a little further. This section fully explains how :count
interacts with address and header tests.
And :index modifies the specification of fields, voilà.
No it doesn't.
So yes, the deduction looks right.
There's no deduction involved as far as I can see.
Still, I'm in favor of specs where one doesn't have to use deduction
steps like those in the first place. Even if most would probably come to
the same conclusion, it takes some thought to reach it. People less apt
in English would have a more difficult time with it and one could ease
the issue with a spec that just doesn't leave room for any speculation.
Then, I've got some compiler construction background. And there, it's a
virtue of language specs to be just clear and well-defined and
unambiguous (even if existing specs often don't completely reach up to
that goal, even for "real" programming languages) and, IMO, also without
inducing the need to deduce too much about the intended syntax and
semantics. (Though one might have to deduce much about how to *achieve*,
how to *implement* it, for example if the syntax is difficult to parse
with commonplace techniques - C++ comes to mind - or if the semantic gap
between source and target is large - some functional or logic
programming languages come to mind.)
I'd be for clarification, even if our common result is the most, or even
the only, logical conclusion.
And I'm opposed, for the reasons I've given.
- Date extension:
* Section 4.2 enumerates the possible values for the date-part argument.
However, it does not specify any error handling for the case if the
script uses an invalid value there; especially if that value is
generated by use of the variables extension, thus possibly making
static checking impossible.
Should invalid date-part arguments be an error (static, if possible,
run-time else)?
Yes, I think so. Our implementation certainly does.
It's not completely clear. There's precedent for tolerant behaviour, e.g.
allowing syntactically invalid header names in tests (2.4.2.2. in the
basic Sieve spec, RFC 5228), making the tests fail (return false), but
not an error, which is opposite to the precedent for strict behaviour
in other places I already cited.
As the precedent is mixed, the conclusion is less clear than in the
above question, so this should in my eyes really be clarified in a
further revision of the RFC.
Does your implementation also flag an error if it can be detected only
during run-time? (Causing an implicit keep and some kind of notification
to the script owner about the error, as 5228 says...)
Our implementation only flags the error at runtime. In general this is
the only time it can be done.
Ned
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve