[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: [PATCH] rewrite of KMMsgPartDlg and fixincludes rant
From:       Marc Mutz <Marc.Mutz () uni-bielefeld ! de>
Date:       2002-01-05 11:33:10
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 04 January 2002 01:26, Ingo Klöcker wrote:
<snip>
> > - added 7bit, binary encodings
>
> WTF is binary encoding?

- ---begin rfc2045 excerpt---
2.7.  7bit Data

   "7bit data" refers to data that is all represented as relatively
   short lines with 998 octets or less between CRLF line separation
   sequences [RFC-821].  No octets with decimal values greater than 127
   are allowed and neither are NULs (octets with decimal value 0).  CR
   (decimal value 13) and LF (decimal value 10) octets only occur as
   part of CRLF line separation sequences.

2.8.  8bit Data

   "8bit data" refers to data that is all represented as relatively
   short lines with 998 octets or less between CRLF line separation
   sequences [RFC-821]), but octets with decimal values greater than 127
   may be used.  As with "7bit data" CR and LF octets only occur as part
   of CRLF line separation sequences and no NULs are allowed.

2.9.  Binary Data

   "Binary data" refers to data where any sequence of octets whatsoever
   is allowed.
- ---end rfc2045 excerpt---

Basically, 8bit and 7bit is "text" (ie. organized in lines of no more 
than 1k chars, each delimited from the other by CRLF), while "binary" 
is just that: binary.

> > - added the possibility to select uuencode (by default it's not
> > shown)
>
> uuencode? Are you insane? Maybe we should be able to decode uuencoded
> stuff but we should definitely never use this deprecated (at least
> since June 1992) encoding. Please let uuencode die gracefully!

Did you see it in the popup? No. But OK, I will remove even the 
possibility...

> > Known bugs in new code: none
> > Known bugs in old code:
> > - When attaching an .o file and calling up this dialog, base64 is
> > selected. Selecting qp (or now binary), and hitting OK shrinks the
> > file to seven byte, after a warning is printed that body is binary,
> > but used as text. I don't know how this should have ever worked...
> > Keeping binary data in QCStrings... I thought this bug was fixed
> > long ago?
>
> Is 0x00 allowed in Quoted-Printable? And what is binary supposed to
> be? Everything encoded with '0' and '1' ;-) ?

- ---begin rfc2045 excerpt---
6.2.  Content-Transfer-Encodings Semantics

   This single Content-Transfer-Encoding token actually provides two
   pieces of information.  It specifies what sort of encoding
   transformation the body was subjected to and hence what decoding
   operation must be used to restore it to its original form, and it
   specifies what the domain of the result is.

   The transformation part of any Content-Transfer-Encodings specifies,
   either explicitly or implicitly, a single, well-defined decoding
   algorithm, which for any sequence of encoded octets either transforms
   it to the original sequence of octets which was encoded, or shows
   that it is illegal as an encoded sequence.  Content-Transfer-
   Encodings transformations never depend on any additional external
   profile information for proper operation. Note that while decoders
   must produce a single, well-defined output for a valid encoding no
   such restrictions exist for encoders: Encoding a given sequence of
   octets to different, equivalent encoded sequences is perfectly legal.

   Three transformations are currently defined: identity, the "quoted-
   printable" encoding, and the "base64" encoding.  The domains are
   "binary", "8bit" and "7bit".

   The Content-Transfer-Encoding values "7bit", "8bit", and "binary" all
   mean that the identity (i.e. NO) encoding transformation has been
   performed.  As such, they serve simply as indicators of the domain of
   the body data, and provide useful information about the sort of
   encoding that might be needed for transmission in a given transport
   system.  The terms "7bit data", "8bit data", and "binary data" are
   all defined in Section 2.

   The quoted-printable and base64 encodings transform their input from
   an arbitrary domain into material in the "7bit" range, thus making it
   safe to carry over restricted transports.  The specific definition of
   the transformations are given below.
- ---end rfc2045 excerpt---

The last parapgraph implies that "binary" is a valid source domain for 
any cte, thus for qp, too.

RFC2045 goes on to discuss the identity "encodings" thus:

- ---begin rfc2045 excerpt---
   Mail transport for unencoded 8bit data is defined in RFC 1652.  As of
   the initial publication of this document, there are no standardized
   Internet mail transports for which it is legitimate to include
   unencoded binary data in mail bodies.  Thus there are no
   circumstances in which the "binary" Content-Transfer-Encoding is
   actually valid in Internet mail.  However, in the event that binary
   mail transport becomes a reality in Internet mail, or when MIME is
   used in conjunction with any other binary-capable mail transport
   mechanism, binary bodies must be labelled as such using this
   mechanism.
- ---end rfc2045 excerpt---
- ---begin rfc1652 excerpt---
1.  Introduction

   Although SMTP is widely and robustly deployed, various extensions
   have been requested by parts of the Internet community. In
   particular, a significant portion of the Internet community wishes to
   exchange messages in which the content body consists of a MIME
   message [3] containing arbitrary octet-aligned material. This memo
   uses the mechanism described in [5] to define an extension to the
   SMTP service whereby such contents may be exchanged. Note that this
   extension does NOT eliminate the possibility of an SMTP server
   limiting line length; servers are free to implement this extension
   but nevertheless set a line length limit no lower than 1000 octets.
   Given that this restriction still applies, this extension does NOT
   provide a means for transferring unencoded binary via SMTP.
- ---end rfc1652 excerpt---

This means that I will remove the "binary" "encoding", too. Thus the 
list of encodings now becomes:
none (7bit text)
none (8bit text)
base 64 (binary data)
quoted printable (arbitrary text)

OK?

> > To do:
> > - Add config option to show or not to show the dialog on attaching.
>
> I think we need a new configuration category: "Superfluous config
> options". Wouldn't it be enough if you, Marc, could enable it by
> editing kmailrc? I doubt that anyone except you will miss this
> annoying dialog. Anyway, do whatever you want.

OK. I'll add a config option w/o GUI.

> Make it so.
<snip>

Yessir, Cpt. Picard!

Marc

- -- 
It is truly ironic that the United States, once the beacon for
promoting the principles of freedom of expression, is now
systematically infecting other countries with this dangerous public
policy choice [the DMCA] that will restrict more speech than any law
before it.    -- EFF FTAA Alert:
                 Stop Hollywood Forcing Technology Ban on 34 Countries
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8NuSH3oWD+L2/6DgRAhvqAJ4/DxqGhJ3NKDCyo/M8gmMR/BiqiACgoBEL
tS/Jh/5TWrJhMqmu5zY+dDQ=
=HbqR
-----END PGP SIGNATURE-----

_______________________________________________
kmail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail
[prev in list] [next in list] [prev in thread] [next in thread]