[ Copied to mutt-dev from mutt-users. - Cameron ]
On 16:45 27 Feb 2002, Charles Jie <[EMAIL PROTECTED]> wrote:
| I've posted before about that mutt can not decode a mime qp-encoded
| string with raw spaces in it. I was answered that the standard doesn't
| accept a raw space in qp-encoded string.
Hmm. I thought the stanardard just requires _trailing_ spaces to be
encoded. A space in the middle of the text is fine (deliberately so:
QP is _meant_ to be fairly human readable).
You're possibly confusing it with RFC2047, for encoding special character
sets in a From: (or To: etc) line, where embedded spaces -are_ forbidden
to minimise interactions with RFC822 address tokenisation.
But general QP encoding (RFC 2045) says, in section 6.7, rule 3:
(3) (White Space) Octets with values of 9 and 32 MAY be
represented as US-ASCII TAB (HT) and SPACE characters,
respectively, but MUST NOT be so represented at the end
of an encoded line. Any TAB (HT) or SPACE characters
on an encoded line MUST thus be followed on that line
by a printable character. [...]
So clearly, embedded spaces (and tabs!) are permitted, and MUST be
recognised by decoders. If mutt isn't doing this, that's a serious bug.
| But today I happened to find that Perl module "MIME::QuotedPrint"s
| encode_qp() also leaves the space as it is. It doesn't encode space as
| '=20'.
| Thus I turn to check the unix tool 'mimencode' (from package
| metamail-2.7) and find it does in the same loose way.
It's not loose. It's correct.
| * I would comment that mutt has a too strict strategy to DECODE such
| non-standard qp-encoded string, hasn't it?
It seems to have a too strict decoding rule even for standard strings.
--
Cameron Simpson, DoD#743 [EMAIL PROTECTED] http://www.zip.com.au/~cs/
The first person I met having made their aquaintance on the Net was Mike
Holmes. And no, we didn't have sex.
- Jeremy "That's my story and I'm sticking to it" Henderson
<[EMAIL PROTECTED]>
