Tim: >> base 64 and HTML are two completely different things. There are some >> languages which just aren't going to post in text/plain. Ed Greshko: > I think you may have mis-typed or I'm misreading. > > The only RFC defined text MIME types that I'm aware of are.... > > css, csv, html, plain, and xml > > plain is for any textual data in any "language". Now, certainly there > are some (many) "languages" which either must use base64, > quoted-printable, or 8bit in order to ensure they are transmitted > without lost of fidelity. Content encoding: If you write in ASCII (and I mean ASCII, not just text), then almost any encoding scheme can handle your text, and it can go through 7-bit mail systems as-is. If you write something that uses characters above position 127 (whether that be punctuation or typographical characters), then you need some way of transmitting 8-bit text (8 bits, at least), and you (your client) must declare which scheme it uses. While you *can* send 8-bit text as-is, some things still only live in the old 7-bit email world, so some clients will encode the content in a 7-bit manner to err on the side of caution, and some (not really helpful) servers will transcode your 8-bit message into a 7-bit scheme (at times you can see your message being transcoded back and forth between 8- and 7-bit, as it goes through different /helpful/ servers). In either case, that scheme could be base64 or quoted-printable. There's only one justifiable reason to reject base64 mail, and that would be if you had a mail client that simply couldn't read it (and, by 2010, it would a damn crap one). It's certainly not an indicator of the message content (good, bad, whatever). Content type: As far as content-type (not content encoding) text/plain versus text/ something else is about whether the text is to be read, or parsed. In the sense that if I type something on a typewriter, the text is simply meant to be read, there is nothing else to be done with it. Or, like in the case of HTML and XML, it contains markup as well as the text (paragraphs, lists, etc.). Likewise with other data formats, with there being data content and data descriptions, the content must be interpreted and specially handled before *you* can view it in its proper context. Further interpretation is needed rather than just displaying all the text as text. The issues regarding more than just text/plain stem around two *main* factors: Clients that cannot handle something like HTML, at all, and clients that are vulnerable because they have faults and exploits. Of course, there are other, lesser, problems, as well (badly created content that's hard to read, clients that even manage to render decent HTML badly, the waste of space, etc.). -- [tim@localhost ~]$ uname -r 2.6.27.25-78.2.56.fc9.i686 Don't send private replies to my address, the mailbox is ignored. I read messages from the public lists. -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
