[Top] [All Lists]

Re: comparators and "error"

2006-05-02 13:01:55

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.)

          You see things; and you say "Why?"
  But I dream things that never were; and I say "Why not?"
   - George Bernard Shaw

<Prev in Thread] Current Thread [Next in Thread>