Re: elisp encoding

Re: elisp encoding

[Katsumi Yamaoka]

[-- Attachment #1: Type: text/plain, Size: 586 bytes --]

>>>>> In <ufu0wuicqb.fsf@d-fens.mopniei.ru>
>>>>>	"Ilya N. Golubev" <gin@mo.msk.ru> wrote:

> Gnus v5.10.6
> `(mml-to-mime)' marks type="application/emacs-lisp" body parts with

> Content-Transfer-Encoding: 8bit

> header even if body part data is pure ascii.
> Even explicit `encoding=7bit' MML tag does not change this.

2001-07-24 12:00:00  ShengHuo ZHU  <zsh@cs.rochester.edu>

	* mm-encode.el (mm-encode-buffer): Don't use 7bit encoding if
	there are long lines.

I couldn't find the reason why it was needed.  Anyone?
See the following parts in the " *Original Article*" buffer.


[-- Attachment #2: Type: application/emacs-lisp, Size: 81 bytes --]

[-- Attachment #3: Type: application/emacs-lisp, Size: 13 bytes --]

Re: elisp encoding

[Katsumi Yamaoka]

>>>>> In <b9ylli5a92v.fsf@jpl.org> Katsumi Yamaoka wrote:

> See the following parts in the " *Original Article*" buffer.

> (setq t nil) (setq t nil) (setq t nil) (setq t nil) (setq t nil) (setq t nil)

> (setq nil t)

Oops, the long one is different from the result of mml-preview.
I'll look into it...

Re: elisp encoding

[Katsumi Yamaoka]

I'm sorry for wasting the bandwidth.

>>>>> In <b9y4qota86w.fsf@jpl.org> Katsumi Yamaoka wrote:

> Oops, the long one is different from the result of mml-preview.

I don't know why the part was modified into quoted-printable
from 8bit, but it may be doing of MTAs.  What Ilya and I wanted
to say is why ShengHuo changed it so that the `CTE: 8bit' is
used when a part contains long lines even if there's no
non-ascii text.  I cannot find out the necessity.

--=-=-=
Content-Type: application/emacs-lisp
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

(setq t nil) (setq t nil) (setq t nil) (setq t nil) (setq t nil) (setq t nil)

--=-=-=
Content-Type: application/emacs-lisp
Content-Disposition: inline

(setq nil t)

--=-=-=--

Re: elisp encoding

[Kai Grossjohann]

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.  What Ilya and I wanted
> to say is why ShengHuo changed it so that the `CTE: 8bit' is
> used when a part contains long lines even if there's no
> non-ascii text.  I cannot find out the necessity.
>
> --=-=-=
> Content-Type: application/emacs-lisp
> Content-Disposition: inline
> Content-Transfer-Encoding: 8bit
>
> (setq t nil) (setq t nil) (setq t nil) (setq t nil) (setq t nil) (setq t nil)

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?

Kai

Re: elisp encoding

[Ilya N. Golubev]

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

So a standard procedure of testing mime encoding without actually
sending mail is absolutely necessary.  As requested by <mml testing>
posted to <bugs@gnus.org> on Wed, 30 Jun 2004 00:21:54 +0400
(<027e40e1cf6186-gin@mo.msk.ru>).

> What Ilya and I wanted
> to say is why ShengHuo changed it so that the `CTE: 8bit' is
> used when a part contains long lines even if there's no
> non-ascii text.  I cannot find out the necessity.

Agree.  This imposes the limit of 76 octets per line on pure 7bit body
parts.

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.

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)'.

Re: elisp encoding

[Katsumi Yamaoka]

>>>>> 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>

Re: elisp encoding

[Katsumi Yamaoka]

>>>>> In <b9y6598f5qh.fsf@jpl.org> Katsumi Yamaoka wrote:

> 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.

It will probably be better to use qp-or-base64 than qp.