Alexey Melnikov writes:
> Here is a strawman syntax for new quoted strings that would only allow
> for valid UTF-8 sequences, but would also allow for escaped non-UTF-8
> sequences:
> ...
The capability name needs changing.
> quoted-string = old-quoted-string / new-quoted-string
> ; "new-quoted-string" is not allowed as
> ; a parameter to "require" action.
> ; "new-quoted-string" is only allowed after
> ; 'require "utf8-strings";'
You're actually talking about non-utf8-compliant-strings. "utf8-strings"
is a poor name for that.
I find it very difficult to summon any enthusiasm for this extension.
Please include at least three realistic examples in the draft to show
that it has value.
The obvious one is that I, and I suspect lots of other people, have to deal
with unencoded 8bit in various charsets in message headers. I've tried the
"reject all mail containing raw 8bit in the headers" approach and find it
catches far too much legitimate (but malformed) mail - when I had such a policy
in place here at home my wife found it impossible to correspond with several
people she works with.
Interestingy, I actually find it's better to use this as a whilelisting
mechanism than a blacklisting mechanism, that is, I sometimes set up rules
that look for bogus 8bit sequences found only in legitimate mail and use
that to keep it out of the spam folder.
Ned