Re: Warning during installation of ns-2.34 on fedora-11

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux