On Tue May 2 16:43:44 2006, Arnt Gulbrandsen wrote:
2. Even though a collation specification distinguishes between
"no-match" and "error", there's no requirement that all protocols
must. If the distinction between "no-match" and "error" is
pointless in e.g. sieve, can't simply sieve treat the two as equal?
Ie. "match" is true, "no-match" is false and "error" is false?
I need to think on your argument some more, but note that there's two
forms of "error"
A) You tried to compare a valid input string against an invalid input
string.
B) You tried to compare two invalid input strings.
It's only case A that's really occured much in the wild, and that's
because only one mechanism - Sieve variables - allows for that case
to happen except in moments of silliness.
Specifically, one operand for a comparator is usually provided by the
client (in ACAP) or the script creator (in Sieve). With Sieve
variables, both can be derived from the message, which presumably
isn't known in advance.
I suspect that for Sieve, case A is obviously not a fatal error, and
probably indicates a non-match. Case B is a little trickier - there's
a reasonable argument that it ought to result in a match. ("Blue" and
"Yellow" do have equally non-existent numeric value, after all, and
they collate equally at the end, and "i;octet" has that funny bit
about the equality of two NIL values in ACAP, which of course you're
all familiar with.)
Dave.
--
You see things; and you say "Why?"
But I dream things that never were; and I say "Why not?"
- George Bernard Shaw