Mailing List Archive
tlug.jp Mailing List tlug archive tlug Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]Re: [tlug] Changing subject in thread.
- Date: Fri, 16 Aug 2013 21:59:17 +0200
- From: Benjamin Tayehanpour <benjamin@example.com>
- Subject: Re: [tlug] Changing subject in thread.
- References: <CAJA1Y2b_7JCsDKSv8hZxpwUxqOVS-2VXHwmxd9RoiVQq-ZyzcQ@mail.gmail.com> <CAL-VO6JfTnTG4=Xo8f+xLjJgaU6y7q=OwevDxN2aAmLi-c2X+Q@mail.gmail.com> <20130815204127.GA14948@scott1.scottro.net> <201308151606.45045.daniel.ramaley@drake.edu> <87ioz6ic5j.fsf@uwakimon.sk.tsukuba.ac.jp>
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.
- Follow-Ups:
- Re: [tlug] Changing subject in thread.
- From: Stephen J. Turnbull
- Re: [tlug] Changing subject in thread.
- From: Josh Glover
- References:
- Re: [tlug] [Was: Why Hollywood does break foreign films ?] Changing subject in thread.
- From: Bruno Raoult
- Re: [tlug] [Was: Why Hollywood does break foreign films ?] Changing subject in thread.
- From: Benjamin Tayehanpour
- Re: [tlug] [Was: Why Hollywood does break foreign films ?] Changing subject in thread.
- From: Scott Robbins
- Re: [tlug] [Was: Why Hollywood does break foreign films ?] Changing subject in thread.
- From: Daniel A. Ramaley
- [tlug] Changing subject in thread.
- From: Stephen J. Turnbull
Home | Main Index | Thread Index
- Prev by Date: Re: [tlug] [Was: Why Hollywood does break foreign films ?] Changing subject in thread.
- Next by Date: Re: [tlug] Proprietary derivatives of FLOSS and other absurdities
- Previous by thread: [tlug] Changing subject in thread.
- Next by thread: Re: [tlug] Changing subject in thread.
- Index(es):
Home Page Mailing List Linux and Japan TLUG Members Links