On Tue, Oct 04, 2005 at 04:38:12PM +0200, Kjetil Torgrim Homme wrote:
On Tue, 2005-10-04 at 15:24 +0200, Michael Haardt wrote:
The ease of a new option like ":full" for keeping white space makes me
think "bloat", but unfortunately it does add what we ask for without
breaking anything.
we would need to come up with a more precise name for the match-type.
if envelope :all :full "lt" "from" "kjetilho(_at_)example(_dot_)com" ...
what is :all and what is :full? two alternative names are ":verbatim"
and ":compare".
adding a match-type means we would need a new name for the extension, or
perhaps a separate document for it. I'm not sure it's worthwhile, as
there is a known workaround for the stripping in the variables case
(prefix both values with non-space) and in the header case I doubt any
script will care.
My perspective was that it was less about match-type than how you derive
the data. Part of the tricky wording included mentioning whitespace
elimination when a value ("on the left") was extracted from the message.
My earlier response upthread was that this is not really specific to the
relational tests, but specific to how the values are obtained for the
underlying Sieve action. I ran into this very early on with e.g. the
header action: since in common practice there is at least one space
after the colon in message header fields, you have to strip at least one
leading space in the "value from the message" in order to meet users'
expectations, not to mention making some of the RFC examples work. And
if you have to strip one-- well, in for a penny, in for a pound.
Ditto in address and envelope tests; there should be no spaces in the
data "from the message" after extraction from the message. The big
surprise happens when you try to impute this space-skipping behaviour to
the matching logic rather than on how to obtain the data for comparison;
the "string" test doesn't take its data from the message, and it doesn't
follow that one would expect it to strip spaces from the left side
argument.
Given this perspective, I don't think any of that is specific to the
relational extension and doesn't belong there, and it would be better to
have more explanation about how the data is extracted from the message
in the base document (or whatever document describes the specific
action).
Well that's my (possibly contrary) take on it, anyway.
mm