Hi, Cyrus!
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:
Is it okay to discuss issues (what seems like ambiguities or gaps to
me) in Sieve specifications (RFC texts, perhaps also drafts) here,
from an implementor's perspective?
Yes, you are more than welcome to do that.
Okay, thanks for your prompt reply.
And, what's the relationship between this list (sieve@) and
ietf-mx-filters?
sieve(_at_)ietf(_dot_)org is the new home for the mailing list. The old
@imc.org
address wil forward to the new list.
Ok, thanks.
I've currently got the task to add more extensions to our implementation.
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.
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).
- 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)?
- 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)?
A precedent would be the "envelope-part" argument for the envelope
test where implementations SHOULD consider unknown envelope parts
an error (but not "MUST"). For comparators (that are given as string),
it's even stronger: unknown comparators are an error (because they
are either declared with require and then require causes an error if
it's not known, or they aren't, then it's an error to use an
un-require'ed comparator; section 2.7.3 of the base spec, towards
the end).
* Section 4.3 tells about comparator vs. date-part interactions.
Do I read it right and that section is just recommendations for
users? I.e. the implementation shouldn't reject a script that
uses i;ascii-numeric in a non-recommended way (e.g. for "date",
where it will in fact just use the year), but at most warn the user
that the comparator may lose information (because it strips
the value at the dash separating year from month)?
* Date extraction: The specification (in section 4, before 4.1) says
the implementation must be able to extract a date from the entire
field content or from the end of a field, following a semicolon.
As the obsolete syntax is still not weeded out, even in RFC 5322,
this extraction may prove difficult.
Received: [... received-info ...]; Mon, 10 (This is a ridiculous
comment containing a semicolon: see here: ; ) Aug 2009 ...
Undoing the folding is probably easy, but finding the *relevant*
semicolon is difficult if I want to implement/use only a *Date*
parser and spare myself the work of parsing the structure of the
Received header too. The Date parser will be able to remove/skip
the obsolete comment, but not the leading received-info. So we'd
have to do a first pass in *reverse* to skip over CFWS until we hit
a semicolon (outside the CFWS we skipped).
Does the spec (RFC 5260) require that or would a simple-minded
implementation (strip everything up to the last semicolon,
regardless of structure, which would fail in my contrived example,
i.e. make the test return false and use a count of zero) fulfill the
spec too?
Kind regards,
Hannah.
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve