Subject: Re: Stripping leading/trailing spaces in relational draft

From: Kjetil Torgrim Homme <[email-masked]>
Date: Mon, 03 Oct 2005 12:17:39 +0200

(looks like Alexey hit the "reply" button rather than "reply all".)

On Sun, 2005-10-02 at 21:18 +0100, Alexey Melnikov wrote:
> Kjetil Torgrim Homme wrote:
> >On Tue, 2005-09-27 at 13:31 -0700, Ned Freed wrote:
> >>I'm in favor of the behavior being consistent across all tests. If it isn't
> >>we now hove to specify this obscure bit of behavior for every future
> >>extension that introduces a test. Not good IMO.
> >
> >I agree.
>
> I agree with Ned's statement, however this doesn't answer my question: 
> do you want to always strip leading/trailing spaces for all tests or not?

I do not particularily like the stripping, and ideally I think [ACAP]
should have specified that i;ascii-numeric ignores leading whitespace.
one alternative way back then would have been to register a new
comparator which handles true numbers (ie. negative numbers and possibly
even decimals) where leading whitespace is disregarded.

however, can we change [RELATIONAL] in such a backwards compatibility
breaking manner?
-- 
Kjetil T.

---

From: Ned Freed <[email-masked]>
Date: Mon, 03 Oct 2005 10:46:25 -0700 (PDT)

> however, can we change [RELATIONAL] in such a backwards compatibility

I see it as a question of which implementations do we break, and since there is
some chance that others have implemented these specifications in places we've
never heard of the bias needs to be towards keeping the status quo.

The reports I saw seemed to indicate that most implementations followed the old
specification in this regard. Our didn't, but it wasn't hard to change it to
comply. I also note that we implemented part of this but not all, so either way
this goes we'll need to change things.

My position is therefore that we should keep things the way they are. This
isn't the most convenient answer for our implementation, but given the
information we have available I think it is right one.

				Ned

---

From: Michael Haardt <[email-masked]>
Date: Tue, 4 Oct 2005 15:24:47 +0200

> even decimals) where leading whitespace is disregarded.

I agree that a new comparator and relational keeping white space would
be best, but I am afraid we are a minority on that issue.

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.

Michael

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Tue, 04 Oct 2005 16:38:12 +0200

> think "bloat", but unfortunately it does add what we ask for without

we would need to come up with a more precise name for the match-type.

  if envelope :all :full "lt" "from" "[email-masked]" ...

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.
-- 
Kjetil T.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 05 Oct 2005 12:10:18 +0100

Kjetil Torgrim Homme wrote:

>perhaps a separate document for it.
>
Right. If anybody want to pursue that that will be fine with me.

>I'm not sure it's worthwhile, as
It seems that the consensus is to keep the current behavior.

Kjetil, can I ask you to add your example how to work-around this issue 
to the "variables" draft.
After that I will tell Scott that the document is ready for IESG.

Alexey

---

From: Michael Haardt <[email-masked]>
Date: Wed, 5 Oct 2005 14:26:43 +0200

> >what is :all and what is :full?  two alternative names are ":verbatim"

Sounds much better indeed.

> Right. If anybody want to pursue that that will be fine with me.

Now that we do have a route to extend relational, should the need
ever arise in reality, plus a workaround that looks like it suffices,

I agree.

> After that I will tell Scott that the document is ready for IESG.

Stop! :)

There is still the yet unanswered question if leading or trailing white
space on the right side is an error, as it could never be matched by
any argument on the left side and is likely a mistake.

Michael

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 05 Oct 2005 15:50:42 +0200

> to the "variables" draft.

I added this text:

   Note: The "relational" extension also adds a match type called
   ":value".  This match type strips leading and trailing whitespace in
   both values before comparing them.  If it is desired to make
   whitespace significant in the variable comparison, this can be
   accomplished by prefixing and suffixing both values with any non-
   whitespace character.

   Example:
      require "relational";
      set "empty" "";
      set "spaces" "      ";
      if string :value "eq" "${empty}" "${spaces}" {
          # the above test succeeds
      }
      if string :value "ne" "X${empty}X" "X${spaces}X" {
          # the above test succeeds
      }

-- 
Kjetil T.

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 05 Oct 2005 16:11:40 +0200

> any argument on the left side and is likely a mistake.

you're assuming only "eq" or "ne".  for "lt" the trailing whitespace
will be significant.  also, there are many other tests which will never
match, e.g.

   if address :is "From" "[email-masked]"

while some implementation may choose to look for and report such errors
(during upload), I don't think we need to get into details of this sort.

thanks for the note, though, because the text I just suggested for
variables is wrong!  here's a fixed version:

   Note: The "relational" extension also adds a match type called
   ":value".  This match type strips leading and trailing whitespace in
   the source string (or string list) prior to comparison.  If it is
   desired to make whitespace significant, this can be accomplished by
   prefixing and suffixing every value with an arbitrary non-whitespace
   character.

   Example:
      require "relational";
      set "empty" "";
      set "spaces" "      ";
      if string :value "eq" "${spaces}" "${empty}" {
          # the above test succeeds
      }
      if string :value "ne" "X${spaces}X" "X${empty}X" {
          # the above test succeeds
      }

-- 
Kjetil T.

---

From: Michael Haardt <[email-masked]>
Date: Wed, 5 Oct 2005 16:50:47 +0200

On Wed, Oct 05, 2005 at 04:11:40PM +0200, Kjetil Torgrim Homme wrote:
> will be significant.

Yes, and very confusing so, given X-field: a

if header :value "gt" :comparator ["x-field"] ["a "]

the test is true.  But I agree it may be desired for anything but "eq"
and "ne", so I suggest the following example:

  require "relational";
  if header :value "eq" "X-field" "trailing space " {
    # the above test never succeeds, because trailing spaces are
    # removed from the left side, see section 3.1.  Use :is
    # instead.
  }

That should illustrate the problem.

Michael

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 05 Oct 2005 16:54:14 +0100

>any argument on the left side and is likely a mistake.
It is a generic problem with the relational extension, so I don't think 
we need to address it in the variables draft.

Besides, the right hand side of a string test can contain variables. So 
I don't think it is a good idea to make leading/trailing whitespaces in 
the rightmost parameter a runtime error.

---

From: Michael Haardt <[email-masked]>
Date: Wed, 5 Oct 2005 18:09:32 +0200

> we need to address it in the variables draft.

Oops, sorry.  I thought you were talking about the relational extension,
but reading it again, you wrote "variables".

> the rightmost parameter a runtime error.

Well, with "eq" and "ne" the right hand side can never match the
left, if it contains leading/trailing whitespace.  That's almost
certainly a mistake, but with the other operators it may be desired.
That's why I agree to documenting this issue in the _relational_
draft with an example.

Michael

---

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 5 Oct 2005 16:01:57 -0400

> (prefix both values with non-space) and in the header case I doubt any

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

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Thu, 06 Oct 2005 02:00:01 +0200

> follow that one would expect it to strip spaces from the left side

the "string" source could be a message originally.  anyway, I think with
the added note to "variables", this is clear enough.

> in the base document (or whatever document describes the specific

the base document has the tests "address", "envelope", "header",
"exists" and some others.  of these, only "header" is unclear on which
part of the header to consider.  I agree it would be useful to add a
sentence to the base spec making it explicit that the spaces following
the header field name are ignored.

of the published extensions, only "subaddress" has the possibility of
touching on this issue, but an e-mail address such as

   <"kjetilho+ awkward address"@ifi.uio.no>

seems contrived.  assuming a "+" subaddress separator, I expect the
source value to include the SPC, i.e., hold the value

   " awkward address"

(without the quotes).  I find this too academic to warrent concern, but
"subaddress" might do with a clarification of this case.

do you think a change to the base spec for "header" makes it possible to
remove the whitespace stripping rule in "relational"?
-- 
Kjetil T.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 11 Oct 2005 13:25:11 +0100

>the header field name are ignored.
I would really like if this gets us a clean solution to the problem.

Stripping leading spaces in headers is indeed a common practice these days.

>remove the whitespace stripping rule in "relational"?
Any opinions on this?

Alexey

---

From: Barry Leiba <[email-masked]>
Date: Tue, 11 Oct 2005 14:42:15 -0400

> do you think a change to the base spec for "header" makes it possible
> to remove the whitespace stripping rule in "relational"?

Well, I think *all* comparisons should strip leading and trailing white
space, and I don't see a problem with stressing that repeatedly.  In
particular:

1. In my experience it's ALWAYS a glitch when something retains leading
or trailing white space, and I can't recall EVER seeing a case where a
comparison RELIED on that white space remaining (and failing to match a
similar string without it).

2. Not only is it a glitch, but it's a HARD-TO-FIND glitch, which
causes a lot of wasted time.

3. Since "relational" is specifically discussing comparisons, I see
reasonable value, for clarity, in having text there that reminds people
that white space on the ends is ignored.

Barry

--
Barry Leiba, Pervasive Computing Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 12 Oct 2005 01:04:46 +0200

On Tue, 2005-10-11 at 14:42 -0400, Barry Leiba wrote:
> space, and I don't see a problem with stressing that repeatedly.

okay, I count this as a vote for changing the base spec.  since the base
spec is currently silent on this issue, I think it is OK to change
"header", even though this is subtly incompatible with existing
implementations.  I would argue that a silent spec means "don't meddle
with the data", so this needs to be explicit.

would you want the base spec to say that this stripping should be done
for _all_ tests?  my feeling is that we may regret that in the future,
but then it is not proper for "relational" to state that stripping
happens whatever the test type (and why only the LHS?)

in the case of the "string" test, it would need to be explicit whether
stripping is done or not.  if it is done, the workaround example needs
to stay.

I really want to get the _really_ final variables draft out before the
deadline, so I look forward to your comments.
-- 
Kjetil T.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 11 Oct 2005 19:16:25 -0400

>> Well, I think *all* comparisons should strip leading and trailing
>> white space
> 

Yes, that is, indeed, what I said (and meant).  Both sides of every
equation.  Why do you think we'll regret it?

As I said, in my experience I have NEVER encountered a situation where
anyone WANTED, say, "xyz" and "xyz " not to match, and I've only seen
it cause time-wasting confusion, as people tried to figure out why
something wasn't working as they expected it to.

But if people think otherwise, I'm happy to go along with it.  It's
just my opinion, here, that's all.

Barry

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 12 Oct 2005 02:15:13 +0200

On Tue, 2005-10-11 at 19:16 -0400, Barry Leiba wrote:
> equation.

that's not what "relational" says, it only strips whitespace from values
taken from the message, in other words the left hand side.

> Why do you think we'll regret it?

I don't know, just a gut feeling.  sooner or later someone will
introduce a test where keeping whitespace is the "intuitive" behaviour?
"string" may be such a test, but even "address" is to some extent.

recall that <"kjetilho"@ifi.uio.no> is semantically equivalent to
<[email-masked]> (RFC 2822, 3.2.5).  therefore, it is IMHO natural
that Sieve simplifies the localpart to 'kjetilho'.  example:

  address :localpart :is "From" "kjetilho"

this test should return true for both addresses.  consider then <" odd
address"@example.com>.  given the canonicalisation rule above, the
"address" test can not test for this value.

this is clearly an edge case, and it may be acceptable to sacrifice it
simply to ensure that all the relevant documents[*] agree on the
behaviour and specify a simple rule.  in my book, a simple rule should
not specify different behaviour for the two "sides" of a comparison.

[*] base, relational and variables
-- 
Kjetil T.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 11 Oct 2005 21:50:59 -0400

> that's not what "relational" says, it only strips whitespace from
> values taken from the message, in other words the left hand side.

OK, let's think about this sensibly, though.  I could ask Wolfgang, but
I'm quite sure that when he wrote the spec, he just assumed that no one
would write a test that could not possibly match, and if white space is
stripped from the data from the message, a string with leading white
space that's coded in the script can't possibly match it.

The other way around is a pretty stupid case too -- if we strip white
space from strings in the script and not from those from the message,
we'll have messages that can't possibly be matched by any script.

So, clearly, either we strip both, or neither.

Now that we have that settled, we're back to the real question, which
is whether to strip white space.

As to your example, well, I didn't ask whether you could *contrive* a
case where it could matter -- clearly, one can.  I asked whether it was
a sensible thing to expect in reality, and I think it's not.  And my
experience tells me that it's not.  And my experience tells me that
allowing for it causes problems, over time.

If we don't, then someone's implementation is going to turn
   To:  [email-masked]
into " [email-masked]", and it'll be forever before someone sorts
that bug out.

But if consensus has it that we don't strip, then, OK, we don't strip.
But then we "don't strip" on BOTH sides of the equation.  Both, or
neither.

Barry

---

From: Michael Haardt <[email-masked]>
Date: Wed, 12 Oct 2005 12:55:17 +0200

> into " [email-masked]", and it'll be forever before someone sorts

I strongly disagree to always stripping white space.  To me, it is
intuitive to strip leading (not trailing) white space for header tests,
and no white space at all for address or envelope tests.  If white space
is stripped on the left side (message value), it should be stripped on the
right side (literal) the same way, but that is an independent issue.
And I would love to keep this out of the relational extension, if I had
a choice.

The base specification indeed does not say anything on this, which means
implementations might differ depending on how the underlying systems
handles stuff.  Not good [tm].  What do

  header "subject" "abc"
  header "subject" " abc"

yield with different implementations on matching

  Subject:abc
  Subject: abc
  Subject:  abc

? My implementation evaluates the first test to be true, and the second
to false for all subjects.  Trailing white space is kept and used,
because that was intuitive to me, but indeed I should have brought this
up for discussion of the base spec.  It just didn't occur to me it was
really undefined. :-(

Let's first resolve this before proceeding with the relational extension.

Michael

---

From: Barry Leiba <[email-masked]>
Date: Wed, 12 Oct 2005 10:16:21 -0400

Michael Haardt wrote:
> because that was intuitive to me

It's intuitive to you that a message with this line
   Subject: banana
should NOT match this test
   header :is "subject" "banana"
?
What, you didn't notice the space character after the word "banana" in 
the subject line?  Neither did anyone else.

Repeating: I'm saying that I can imagine NO real situation where it 
matters, I can imagine NO ONE really wanting it to work that way, and I 
can imagine a LOT of wasted time trying to figure out why a script 
behaved in an unexpected way on a message.  I also expect that there are 
implementations of mail thingies out there (clients, servers, relays, 
whatever) that would strip that trailing blank from the header anyway, 
so I doubt such a thing could be transmitted reliably even if someone 
DID want to.

I'll believe that there are "IETF process" reasons why we can't change 
this now.  It'll be tough to get me to believe that anyone actively 
WANTS (for a reason better than "What if...?") the preservation of 
trailing white space in these comparisons.

Barry

---

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 12 Oct 2005 18:28:32 -0400

On Wed, Oct 12, 2005 at 12:55:17PM +0200, Michael Haardt wrote:
> and no white space at all for address or envelope tests.

I am mostly in agreement there.  In header tests, my implementation only
strips leading spaces, but only because that is what I believed a script
writer would expect (and, as I mentioned before, is the only way some of
the examples could work).  I could probably get on board with stripping
trailing spaces from header tests for consistency's sake, but do not do
it at present.

Unfortunately I can envision a situation where a script writer might want
to test for sequences of leading and, particularly, trailing spaces.
But you can't really have it both ways without adding some kind of other
options.

As for address elements, I believe I am stripping whitespace only if the
address is not in anglebrackets, but if anglebrackets are present, am
taking the interior as the literal string.  Kjetil's comments about
address canonicalization for the tests are interesting though; I had
thought of the address test as a string comparison against the character
strings found in the message header, not as a semantic test (i.e. against
what the address means).  But that interpretation has a lot of appeal
and I am at the moment inclined to change.

> If white space

I agree with the last part, but not the first :-)  I think that the
space-stripping conversation should be focused on the test inputs that
the script writer doesn't explicitly control, i.e. to the inputs that
are supplied by the implementation "from the message."  If the script writer
supplies a literal with spaces in it, and it doesn't make sense, well
that's a script bug.  The script writer has the ability to repair that
mistake.

> And I would love to keep this out of the relational extension, if I had

Agreed.

> to false for all subjects.

Ditto.  But your description of your implementation seems to contradict
your belief (quoted above) that spaces should be stripped from literal
strings if they have been stripped from another input to the test.
Do I misunderstand?

Yours,
-mm-  (way behind on everything, still)

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Thu, 13 Oct 2005 03:20:37 +0200

> that's a script bug.  The script writer has the ability to repair that

I think this makes sense.  consider this example:

        require "variables";
        if header :matches "Subject" "*" {
                set "subject" "${1}";
        }
        if string :is "${subject}" "devious" ...

if the message contains "Subject: devious ", the "string" test should
IMO succeed, *but* the stripping didn't happen there -- it should be
done by the "header" test.  in other words, ${1} contained "devious"
without the trailing space since the "Subject" value was stripped.

I want to revert the suggested text and example in "variables" about the
interaction with "relational", and the new suggested change relative to
the currently published -06 draft is as follows:

 5.  Test string
 
    Usage:    string [MATCH-TYPE] [COMPARATOR]
              <source: string-list> <key-list: string-list>
 
    The "string" test evaluates to true if any of the source strings
    matches any key.  The type of match defaults to ":is".
 
+   Some match types mandate stripping of leading and/or trailing
+   whitespace from the inputs prior to comparison whenever the string
+   value is taken from the message.  In the "string" test, both
+   source and key-list are taken from the script, not the message,
+   and whitespace stripping MUST NOT be done unless the script
+   explicitly requests this through some future mechanism.
+
    Example:
       set "state" "${state} pending";
       if string :matches " ${state} " "* pending *" {
           # the above test always succeeds
       }
 
    The "relational" extension [RELATIONAL] adds a match type called
    ":count".  The count of a single string is 0 if it is the empty
    string, or 1 otherwise.  The count of a string list is the sum of the
    counts of the member strings.

forgive my narrow focus on "variables" just now, but I really want to
get the document done.

> > And I would love to keep this out of the relational extension, if I had

yes, the behaviour really needs to get into the base spec.
-- 
Kjetil T.

---

From: Michael Haardt <[email-masked]>
Date: Thu, 13 Oct 2005 11:48:54 +0200

> the subject line?  Neither did anyone else.

In case there was a space after "banana", it's not there any more.
I am not sure what that means now.

But right, I did not notice it, even if it would have been there.  To me,
that says clients should possibly mark trailing space somehow.  I'll put
it on my list of mail client misfeatures. ;)

At one time I used a filter that matched (together with other tests) a
trailing space, because a really annoying spammer used it.  Worked well
until the spam stopped.  That's real enough to me for wanting things to
work that way, but I am not religious on this, if the majority decides
it should be stripped on header tests.

Michael

---

From: Michael Haardt <[email-masked]>
Date: Thu, 13 Oct 2005 12:11:20 +0200

> trailing spaces from header tests for consistency's sake, but do not do

Ok, so are there any votes against stripping leading white space on
header tests? I don't see agreement on how to treat trailing space
yet, but that's a different issue.

> But you can't really have it both ways without adding some kind of other

Indeed, and you can not test for the white space between the header
name and the colon either.  I guess that needs a new test operating on
raw headers.

> and I am at the moment inclined to change.

Note that the base spec requires to strip comments within addresses.
But indeed it is not clearly spelled out that e.g. quoted local parts
are to be matched unquoted.  Yet another change to the base spec.  We
discussed that before, but that might have got lost.

> that's a script bug.  The script writer has the ability to repair that

You have a point there.

> strings if they have been stripped from another input to the test.

Oops.  No.  I guess I thought "if it doesn't say it strips trailing
space, it should be kept" and reading your answer above, I agree that
it is really better that way.

I like symmetry a lot, but get carried away with it sometimes.

Michael

---

From: Dave Cridland <[email-masked]>
Date: Thu, 13 Oct 2005 11:12:47 +0100

On Thu Oct 13 10:48:54 2005, Michael Haardt wrote:
> > What, you didn't notice the space character after the word 
> "banana" in > the subject line?  Neither did anyone else.
> 

In this case, it's because Barry uses a client which does 
format=flowed text, so it's likely that the client itself stripped 
the space before sending - a trailing space has meaning in 
format=flowed. I don't think this weakens his argument.

If you're really intent on having some mechanism to test for "raw" 
features of the header content, then my personal view is that there 
needs to be a "header" test, which normalizes whitespace, strips 
header and footer, and decodes RFC2047, and a "rawheader", which 
provides the header field value with all spaces, encoded words, etc, 
intact.

The majority of people will intend that "banana" matches "Subject: 
banana ", "Subject: =?Q?iso-8859-1?banana?=", and "Subject:banana" 
and all other variations - the golden rule being if it looks as it it 
ought to have matched when they observe it in the MUA, then it ought 
to have matched.

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

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 13 Oct 2005 11:57:35 +0100

>yes, the behaviour really needs to get into the base spec.
Do we have a rough consensus to:
1). Move the text about stripping leading/trailing spaces in the 
leftmost parameter from the relational draft to the base spec.
2). Don't strip leading/trailing spaces in the leftmost parameter of the 
string test.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 13 Oct 2005 12:17:21 +0100

>+   explicitly requests this through some future mechanism.
I like the intent of the text, but it seems to be implying that a test 
can override stripping behavior mandated by a match type.
I thought we've agreed previously that this is not a good idea.

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Thu, 13 Oct 2005 13:58:10 +0200

> I thought we've agreed previously that this is not a good idea.

yes, I agree.  however, it's a cop-out just in case the base spec and
relational don't get changed, because that is (as I see it) how it
stands: ":value" changes the stripping behaviour of all test actions.
the text above isn't normative, anyway.
-- 
Kjetil T.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 13 Oct 2005 15:36:34 -0400

Dave Cridland wrote:
> banana ", "Subject: =?Q?iso-8859-1?banana?=", and "Subject:banana" and 
> all other variations - the golden rule being if it looks as it it ought 
> to have matched when they observe it in the MUA, then it ought to have 
> matched.

What he said.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Thu, 13 Oct 2005 22:25:09 -0400

Can we resolve this with respect to "relational", so I can get another 
draft out?  As I see it, we're all happy with taking the "stripping" 
language out of "relational", and the uncertainty is whether and where 
it belongs in the base spec.  Right?

So how about I change "relational", and we change the subject line on 
future iterations of this discussion, to replace "relational draft" with 
"base spec"?

Barry

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Fri, 14 Oct 2005 04:43:23 +0200

> future iterations of this discussion, to replace "relational draft" with 

sounds good to me.
-- 
Kjetil T.

---

From: Michael Haardt <[email-masked]>
Date: Fri, 14 Oct 2005 09:20:29 +0200

> > future iterations of this discussion, to replace "relational draft" with 

I would appreciate that, too.

Michael

---

From: Michael Haardt <[email-masked]>
Date: Fri, 14 Oct 2005 12:01:42 +0200

> provides the header field value with all spaces, encoded words, etc, 

Thinking about it, I suspected a new test might be useful in a
past mail of mine, too.  So that may indeed be the way out.

> ought to have matched when they observe it in the MUA, then it ought 

Hmm.  I can't think of anything that weakens that point.  If MUAs would
display trailing spaces, things might be different, but they don't.

So you have me convinced: The header test should strip trailing white
space and next time I get hit by a spammer where this bites, I shall
think about specifying a new test operating on raw headers.

Michael