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

Re: document status: 3028bis, body, editheader

2006-03-22 08:36:49

Philip Guenther wrote:

Alexey Melnikov <alexey(_dot_)melnikov(_at_)isode(_dot_)com> writes:
...
I think you've missed a couple of issues I've reported:
1). I can't see any text about stripping leading/trailing whitespaces (text moved from the relational extension)

Section 5.7:
  The "header" test evaluates to true if the value of any of the named
  headers, ignoring leading and trailing whitespace, matches any key.

(This was present in rev -04 too)
Ah, my fault. I've only checked the diff between -03 and -04. I didn't realized that you've already addressed the issue.
[...]**

Philip Guenther wrote:
...
I've made one tweak for the next rev to the wording in section 2.7.1
regarding ':match' and the definition of 'character'; I had overlooked
an off-list comment at the turn of the year.  The paragraph now
reads:
 The ":matches" match type specifies a wildcard match using the
 characters "*" and "?"; the entire value must be matched.  "*"
 matches zero or more characters in the value and "?" matches a single
 character in the value, where the comparator that is used (see 2.7.3)
 defines what a character is.  For example, the comparators "i;octet"
 and "en;ascii-casemap" define a character to be a single octet so "?"
I don't think en;ascii-casemap is working on octets. So either the comparators draft need to be changed, or this sentence need to be changed.
Sure it is.  Section 9.2.1 of draft-newman-i18n-comparator-08 seems to
concur.
In another section it says that no comparator but i;octet should operate on octets.

I've already sent a comment to Arnt asking him to allow en;ascii-casemap to work on Unicode characters. The advantage of this is that Unicode characters outside of ASCII are legal and not going to cause matching failure anymore.
I though you agreed to this in one of your messages to the mailing list.

So, are there any objections to change en;ascii-casemap to work on Unicode characters?