Re: comparators and "error"

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