Mailing List Archive


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

Re: [tlug] Changing subject in thread.



On 16 August 2013 04:48, Stephen J. Turnbull <stephen@example.com> wrote:
> The problem is that there is no such thing as "rich-text".  There's
> Microsoft "Rich Text Format", which is obviously out as a binary
> format, there's RFC 1896 "text/enriched" which isn't implemented well
> or completely in any MUA I've used (but that doesn't include
> ThunderBird or whatever GNOME recommends, Evolution?), and there's
> HTML.
>
> Unfortunately, HTML isn't really acceptable, since as implemented by
> many agents (eg, Word) it's not at all a human-readable format (even
> Gmail is quite bad).  Worse, without a full DOM implementation, it's
> entirely unsuitable for use on most mailing lists because there's no
> simple way to add headers and footers to the message body, and ensure
> that all MUAs will display them as expected (which is very bad if they
> contain legalese such as responsibility disclaimers or the unsubscribe
> URL required in some jurisdictions).  Problems with HTML mail are
> frequently posted to the Mailman lists.
>
> So for now (both by personal preference and as a Mailman developer) I
> recommend sticking to plain text conventions.

Ah, so there is no actual formal standard for enriched text in e-mail?
That's the rational reason I was looking for. Thank you!

> Of course it does.  The HTML part (and GIF background, but I digress)
> bloat my spools and archives dramatically.

I don't know your definition of "dramatically", but I just made some
size comparisons on gzipped plain-text vs. gzipped HTML, and there was
a 2.5% difference. These were e-books, mind you, so there was more
mark-up in my test files than there would be in a HTML-enriched e-mail
with the odd cursive marker. Assuming (generously) that 10% of all
messages are enriched, we're looking at a 0.25% bloat. Still a better
drama than Twilight, but little else.

> True, *presuming* high-quality implementation and appropriate user
> configuration (including automatic disposal of redundant text/* parts,
> which nothing does by default AFAIK).  But how about one whose MUA
> expects text/plain and gets *only* text/html?  An implementation or
> configuration failure, but frequent in my experience.

In many webmail clients, sending HTML e-mails is the standard
behaviour, so one could also consider *that* an implementation or
configuration failure, also frequently occurring.

> It's not rational, but HTML smells like spam to me.  (I'm the proud
> (?) recipient of both an actual paper 419 scam letter and the original
> Green Card spam post to Usenet; that smell disgusts me.)  The first
> filter I imposed on a message body was for no-see-um HTML iframes,
> used by worms like Frethem.  95% of the (text parts of the) crap in my
> spambucket is HTML.

As you say, it's not rational. Unlike you I haven't investigated the
matter thoroughly enough to give you an accurate figure expressed in
parts-per-hundred, but I'm fairly convinced that a notable share of
the *genuine* messages in my inbox is HTML. Spam messages, however,
often contains *extreme* formatting, with embedded images and whatnot.
I'm not suggesting that *that* level of formatting is a welcome
phenomenon, obviously!

> Adapting to HTML, while theoretically possible, has no really high-
> quality implementations that I've seen.

Good point. I didn't explicitly name HTML as a good candidate for
enrichment, though. Using **, //, &c., is good enough for me, I just
wanted some nice rational arguments against parsed enrichment, such as
some of the points you have raised.

> It's not that the ways that are wicked, but that there's a whole set
> of customs that have evolved.  Use of text/plain mail is one of them.

Customs are a fine thing to have, as long as you remember the
reasoning behind them. One way of doing so is to have them challenged
once in a while :)

> Relying on precise words rather than emotive formatting is another.

Good point. Technically not a rational one, but I don't care. It's a
good one. My favourite, so far.

> Using regexp-based filters rather than complex applications (like
> OpenOffice or Mozilla) to process our mail is another.

With a decent formalised standard for enrichment, regexp-based filters
would work. As I said, I didn't mean HTML specifically.

> I can't, as Comic Sans lacks Japanese glyphs.  My employer would be
> unable to express the concept. :-)

Fair enough! :) You get my point, though.

> Sure, but in a text/plain world, that's because *you* chose to display
> mail in Comic Sans.  You would be living in a Bizarro comic strip!

That was meant as a counter to the argument that orthography is the
only important thing to consider when conveying thoughts by script. It
wasn't meant as a counter to text/plain as such.

On Thu, Aug 15, 2013 at 10:41 PM, Scott Robbins <scottro@example.com> wrote:
> Don't forget---some people pay for bandwidth in quantity, therefore, the
> person who sends an html mail is costing them money.  What a selfish thing
> to do, especially if the recepient has no use for it.

Fair point, sort of. I wasn't aware that such pricing schemes were
still prevalent in the developed world. With the recent (and notable)
exception of certain high-speed cellular data plans, Sweden has
generally been flat-rate since the early 2000s.

Interesting inversion: I'm a member of Uganda LUG, as I was a
volunteer worker in that country for some time. There, bandwidth is
*really* at a premium, with some operators bleeding you dry if you
step outside the established boundaries for your purchased bundle. I
would expect a plain-text policy in their mailing list, but,
interestingly, almost everyone seem to send HTML e-mails regardless of
any actual formatting taking place in them. I don't know what to make
of that.

> I strongly believe that most people on this list prefer plain text.
> Therefore, the one who feels they have to send in rich text or html is
> equivalent to the ugly American who visits a Japanese house and refuses to
> remove their shoes.

Wait, are you saying Americans don't remove their shoes indoors?
That's... that's disgusting! You'd be dragging in all kinds of filth
from the streets, and... Ugh. Thanks for the nasty image, but I don't
see how your comparison would be valid. There are some rather obvious
reasons to remove one's shoes indoors; the same cannot really be said
about plain-text, which is why I was asking. It's not as if I'm
refusing to type in plain-text (as is evident); I'm merely making
enquiries. Politely, I hope.

> HTML makes it far easier to insert viruses and malware.  It lessens the
> risk at no cost to anyone save for the person who wanted to put in italics
> or colored text for an audience that will ignore it.

This would be a good point if I meant HTML in the first place. As it
was, I'm enquiring about the *idea* of rich-text in e-mails. Suppose
an RFC would be drafted which outlines an economic, easily-parsed,
easily-filtered method to insert orthographic emphasis in e-mail.
Would you be opposed to it?

> See the shoes analogy.

See the shoes fallacy.

On 16/08/13 14:36, Bruno Raoult wrote:
> Interesting. A reason of principle rather than practical, in 2013.

That was my original thought. Now I have seen *one* good reason not to
enrich e-mails, namely that there isn't a well-defined way of doing
so. Even if there were no rational reasons, though, I still would have
accepted a non-reason along the lines of "that's the way we've always
done it", as long as it would come with the concession that it defies
reason.

> I agree with Benjamin on many points.

Thank you. Don't misunderstand me, though: I'm not, by any means,
proposing any changes in policy, at all. As stated, I was just curious
as to the rationale behind the current policy. I believe that a policy
(or an opinion, or an attitude, or a belief, or a law) which can't
withstand some healthy questioning once in a while is a flawed policy.

On Fri, Aug 16, 2013 at 3:52 PM, Godwin Stewart <gstewart@example.com> wrote:
> Refusing to adopt local netiquette rules while knowing that they exist
> and why they exist is basically a big "f**k you" to the rest of the
> community.

Obviously. In this case, however, I didn't know why they existed. That
was the whole point behind my enquiries. Even if the reasoning had
been declared in, say, a 1990s article on netiquette, times change.
The bandwidth problem, for instance, is less of an issue today than it
was twenty years ago. As a wise (but, alas, fictional) woman once
said: "Give me the judgment of balanced minds in preference to laws
every time. Codes and manuals create patterned behaviour. All
patterned behaviour tends to go unquestioned, gathering destructive
momentum."

On Sat, Aug 17, 2013 at 12:14:55AM +0800, Raymond Wan wrote:
> Given this, you'd probably want to write it according to what others
> on the list want...  If you write it however you want without thinking
> about the reader, then don't be surprised if no one replies or, worse,
> they focus on how you formatted your message instead of the content.

An excellent point. This is one of the reasons why I, for instance,
value strict adherence to grammar. However, one of the reasons why I
actually questioned this policy to begin with is that I saw what I
thought was a discrepancy between it and the actual capabilities of
MUAs in use today. If a rule (and I'm not necessarily referring to
this one specifically) is made superfluous due to technology marching
on, keeping the rule would be pointless. Wouldn't you agree?

> Scott uses shoes in a Japanese house as an example.  Here's another.
> How about if you were a first-time tourist to Japan and were lost.
> You needed to ask a convenience store for directions.  Would you speak
> in something other than Japanese or would you give it a go with your
> Berlitz Japanese phrase book and try to hash out a sentence?  The
> latter, probably, since it might improve the chance of a helpful
> reply...

I would probably just use Google Maps, to be honest. But reality aside..:

> Ultimately, you're not there to prove to the shopkeeper that you can
> speak in your native language ... you're there to get directions.

Your analogy is flawed. In your convenience store scenario, I am
decidedly at a disadvantage, since I am a lost gaijin and thus "in the
wrong" from the get-go. The interaction is a simple duologue with the
sole purpose of acquiring a piece of information from the store clerk.
In a mailing list, however, I'm in an eternal *dialogue* with my
peers. If everything works as it should, the exchanges (and benefits)
should be mutual. While I obviously have no right to *defy* currently
held standards, I do have the same right as anyone else to ask about
and discuss them. No more than anyone else, naturally, but also no
less.


Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links