Arnt Gulbrandsen <arnt(_at_)gulbrandsen(_dot_)priv(_dot_)no> writes:
Kjetil Torgrim Homme writes:
On Fri, 2005-05-27 at 14:49 +0200, Arnt Gulbrandsen wrote:
> header :is ["X-Caffeine"] [""] => false
> header :contains ["X-Caffeine"] [""] => true
There are no null strings here, only empty strings, so I don't think
it's relevant.
the example wasn't very relevant here, since the header exists.
And since "" is a empty string, not an NULL string. The comparator text
states that NULL strings aren't substrings of anything, so :contains
["X-Caffeine"] [:null] should evaluate to false (if :null were valid).
Right. To avoid confusion going forward, I've updated the base-spec to
refer to the zero-length string ("") as "empty" instead of "null".
Hmm, perhaps the third text paragraph of section 5.7 ("Test Header")
should say that if a named header is not present, then its value is the
NULL string (...with verbiage to keep people from confusing that with
the empty string). Indeed, the behavior of matches against missing
headers could be construed as underspecified currently. Sure, a missing
header doesn't contain the empty string, but does is compare equal to
zero under the i;ascii-numeric comparator?
Well, can you show some example where it actually makes a difference,
and where the difference is useful? It has to be some collation
operation where it's sensible and understandable that NULL (TBD) is
distinct from "". The draft offers two properties that seem relevant to
sieve:
1. NULL is equal only to NULL. The example could use :is.
2. NULL is not a substring of anything. The example could rely on
:contains to return false if the second argument is NULL.
Neither of these can be expressed in sieve, as sieve has no way to
express a NULL second argument to a comparison. The reverse of the
first of those ("NULL !:is non-NULL") is arguably used when the header
test is given a header name that isn't present.
(I can also imagine an implementation that treated
address :domain "To" "example.com"
as using a NULL string for the domain when the address in the To field
was syntactically invalid by lack of a domain part, ala:
To: John Smith <smith>
...but how invalid inputs are handled is beyond the scope of the spec.)
I can't construct such an example, and I really don't want to take the
draft forward with a feature that's incompatible with some running code
and whose utility I cannot explain.
The alternative is for every application that uses collations and
combines the comparison with a key lookup (i.e., anything that rolls an
email header value lookup into the operation) to describe how the "key
not found" case is handled. The -03 rev of the collation registry draft
let both application protocols and collations override the default
handling of NULL strings; dropping them would effectively make that
_just_ application specified.
Philip Guenther