--Boundary-02=_HOFE+1FpWZJ4ppY
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

On Monday 30 December 2002 14:00, Marc Mutz wrote:
> On Monday 30 December 2002 02:24, Ingo Kl=F6cker wrote:
> > Quoted-printable encoded data must not contain 8 bit characters. So
> > basically the message you received was not correctly encoded. Maybe
> > your mail server automatically converted the quoted-printable to 8
> > bit (as indicated in the Content-Transfer-Encoding header of the
> > message) but forgot to change the Content-Transfer-Encoding header
> > of the message part accordingly.
> >
> > It's disputable whether the quoted-printable decoder should strip
> > off 8 bit characters or whether the decoder should ignore and
> > output them. Marc?
>
> The decoder follows rfc 2045:
>
>    NOTE: Several kinds of substrings cannot be generated according to
>    the encoding rules for the quoted-printable content-transfer-
>    encoding, and hence are formally illegal if they appear in the
> output of a quoted-printable encoder. This note enumerates these
> cases and suggests ways to handle such illegal substrings if any are
> encountered in quoted-printable data that is to be decoded. <snip>
>     (4)   Control characters other than TAB, or CR and LF as
>           parts of CRLF pairs, must not appear. The same is true
>           for octets with decimal values greater than 126.  If
>           found in incoming quoted-printable data by a decoder, a
>           robust implementation might exclude them from the
>           decoded data and warn the user that illegal characters
>           were discovered.

"might exclude" doesn't mean "should exclude", let alone "must exclude",=20
right? And as we don't warn the user (which would be pointless and=20
would only confuse the normal user unnecessarily) the decoder should=20
probably simply ignore 8 bit characters and output them unchanged (cf.=20
the suggestion to output =3D as =3D in (2) and (3)).

I don't understand why RFC 2045 proposes to exclude "octets with decimal=20
values greater than 126" from the decoded data. It won't harm not to=20
exclude them.

Regards,
Ingo


--Boundary-02=_HOFE+1FpWZJ4ppY
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA+EFOHGnR+RTDgudgRAhqoAKCNTf1mgbPeiML4yOrElq1aWrxAXQCginuB
eXtcuD/ScOacldRAkW/15Gc=
=Tlu0
-----END PGP SIGNATURE-----

--Boundary-02=_HOFE+1FpWZJ4ppY--

_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail