ietf-mta-filters
[Top] [All Lists]

Other comparator issues

1998-08-20 13:26:50
Two more comparator issues have come up, in playing with our implementation.

(1) What to do if the implementation doesn't support the requested comparator?
The spec is silent on that point; I think the spec should prescribe what to
do, either as a MUST or as a SHOULD.  For instance:
  (a) If the requested comparator is not supported in the implementation,
      the implementation MUST fall back to the default comparator.
or
  (b) If the requested comparator is not supported in the implementation,
      the implementation SHOULD evaluate the condition as "false", but MAY
      treat the request as a script error.

or some such.  So there are two questions:  Should the spec spell it out, or
would others rather leave it to the implementation to decide?  And if it
should be spelled out, how should we spell it?


(2) How to handle RFC 2047 encoding in header fields?  For instance:
From: "=?ISO-8859-1?Q?J=FCrg_von_K=E4nel?=" 
<jvk(_at_)watson(_dot_)ibm(_dot_)com>

If I know that Juerg is using Q-P encoding, as here, I can code a test like
   if header ("from") contains ("von_K=E4nel") ...

But suppose he might be using base64 encoding, and he might or might not
use a "Dr." title in front of his name?  Now I have no idea how to code
something that compares raw field values and does anything useful.  Should
we be decoding the RFC 2047 stuff first, and then applying the comparator
to that?  Or should we be comparing the raw field?  Or do we need an
RFC-2047-specific comparator?  Or do we need a unicode comparator?  Or what?


Barry Leiba, Multimedia Messaging  (leiba(_at_)watson(_dot_)ibm(_dot_)com)
http://www.research.ibm.com/people/l/leiba



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