Let "i;octet" work on characters and document the name is a misnomer.
IF someone really feels the need to specify and implement them: Introduce
Sieve extensions for a "i;binary" comparator that compares against a
string representation of binary data. Introduce new tests "rawheader"
and "decodedheader".
I am not aware how "i;octet" is used at other places, so the above may
only fit well to Sieve.
Your suggestion make sense for header fields. But what about body
extension when matching against application/* MIME part?
I don't think the MIME type should make a difference on what a test or
comparator does, or how the literal used for comparison is represented.
Things get too confusing otherwise.
That having said, using "i;octet" could not be used reasonably on decoded
MIME parts that can not be translated to unicode. Trying to do so should
yield the same behaviour as it does on headers that can not be translated
to unicode, e.g. because their character set is not known.
The imaginary "i;binary" comparator would be the proper solution to
compare with an octet sequence, working on the decoded part, if we tried
to keep a minimum of logic. And I really hope the extension does not
specify what exactly "i;octet" does to let me get away with saying: I am
not breaking it.
Honestly, I never looked at the body extension, because it is way
too expensive for my systems. Skimming it, it does not talk about
comparators and assumes they work as defined by external references,
which is the way it should be.
Michael