On 05/11/2010 09:36 PM, Tim wrote: > 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.). > > Nice tome, and accurate. But, I still wasn't sure what you meant when you said..."There are some languages which just aren't going to post in text/plain." I suppose if by "languages" you were including HTML and XML, then yes one should use text/html or text/xml to indicate those "languages". But, if you were talking about spoken/written/human languages then they all fall under text/plain and there are none that can't be posted as such. Yes, "languages" can be an ambiguous term.... -- Keep your mouth shut and people will think you stupid; Open it and you remove all doubt. 葛斯克 愛德華 / 台北市八德路四段
Attachment:
signature.asc
Description: OpenPGP digital signature
-- 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
