Re: elisp encoding

[Katsumi Yamaoka <yamaoka@jpl.org>]

>>>>> In <868ye5z6fp.fsf@rumba.de.uu.net>
>>>>>	Kai Grossjohann <kai@emptydomain.de> wrote:

> Katsumi Yamaoka <yamaoka@jpl.org> writes:

>> I don't know why the part was modified into quoted-printable
>> from 8bit, but it may be doing of MTAs.

> I think it makes sense to use qp encoding for long lines, by breaking
> them with the "= at end of line" trick.

> That would explain why CTE qp might be useful.  Perhaps someone
> overlooked this when they changed from qp to 8bit?

Thanks.  Now I'm sure the 8bit-to-qp conversion has been done by
a certain MTA.  It is useful when a message contains very long
lines of over 998 bytes.  ShengHuo may have entrusted folding of
them to MTA.  However, every MTA always doesn't do so.

>>>>> In <027c40e2d84907-gin@mo.msk.ru>
>>>>>	"Ilya N. Golubev" <gin@mo.msk.ru> wrote:

[...]

> This certainly is not the processing of long lines in body parts as
> specified by RFC 2045, which imposes line length limit of 998 octets,
> and which concerns both 7bit and 8bit transfer encodings.

So, I think Gnus should fold very long lines by itself.  An easy
way to do that is to replace all `8bit's with `quoted-printable'
in the mm-content-transfer-encoding-defaults variable.  WDYT?

(let (e)
  (while (setq e (rassoc '(8bit)
			 mm-content-transfer-encoding-defaults))
    (setcdr e '(quoted-printable))))

Even if it is done, 7bit is used for short ascii lines.

> Another bug of current processing is that it may leave an 8bit body
> part with lines longer than allowed by RFC 2045.  Actually observed
> such a standard violation.

> . Created an `.el' file containing 1 pure 7bit line of 1500 octets.
> . Attached it to message.
> . Evaluated `(mml-to-mime)'.

I also tested it sending the .newsrc.eld file to me.  The
contents were completely broken by MTA.
-- 
Katsumi Yamaoka <yamaoka@jpl.org>