comparators and "error"

Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> Tue, 02 May 2006 15:40 UTC

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42Fej49062611; Tue, 2 May 2006 08:40:45 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k42FejFl062610; Tue, 2 May 2006 08:40:45 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42FeioL062604 for <ietf-mta-filters@imc.org>; Tue, 2 May 2006 08:40:44 -0700 (MST) (envelope-from arnt@gulbrandsen.priv.no)
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 7819A4AC35; Tue, 2 May 2006 17:40:43 +0200 (CEST)
Message-Id: <buylDuhckrLTBjUJ7Xr9Kg.md5@libertango.oryx.com>
Date: Tue, 02 May 2006 17:43:44 +0200
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: ietf-mta-filters@imc.org
Subject: comparators and "error"
Content-Type: text/plain; format="flowed"
MIME-Version: 1.0
Sender: owner-ietf-mta-filters@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe>

I've been doing some editing on the draft, trying out how some things 
suggested look in prose.

1. It seems useful to me that e.g. ascii-numeric can distinguish between 
comparing nonequal numbers and comparing out-of-scope input.

Take the equality operation as an example:

"Match" means that the collation knows how to work on the input, and the 
two inputs are equal as defined by the collation.
"No-match" means that the collation knows how, and the two are unequal.
"Error" means that it doesn't know how to.

Conflating the two latter cases smells of bad design to me, even though 
the difference may not be useful in every case.

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?

Arnt