[geeks] Going with the (flowed)...

[Lionel Peterson]

>From: der Mouse <mouse at Rodents.Montreal.QC.CA>
>Date: 2006/09/29 Fri AM 09:48:05 CDT
>To: The Geeks List <geeks at sunhelp.org>
>Subject: Re: [geeks] HD/IDE question

>>>>> How come your email comes across in multi-hundred character lines?
>>>> Because your mail client doesn't break them up.
>>> http://www.ietf.org/rfc/rfc2646.txt
>> First off, that someone sat down and wrote a 12 page document becuase
>> he was annoyed at line length in text emails is (somewhat) amazing to
>> me...
>
>What reason do you have to think that that's what prompted 2646?

IIRC (and I haven't gone back to check) the RFC said there was a big problem with line length, esp. when displayed on 30 character wide PDA displays...

>> Finally, I don't consider that RFC binding, as far as I am concerned
>> that RFC has way too much logic in it for such a simple problem.
>
>Well, if you refuse to use the existing, standardized mechanism to
>represent the semantics you appear to want, I see no reason why I
>should go to any particular lengths to make up for it.

OK

>> It essentially says that I should specify "flow" in a header field,
>
>No, "flowed" (and I'm not sure I'd say "field" is a fair word, but
>that's a side note).

OK, fair enough on both points (hey - it was a bit early for me to be reading an RFC ;^)

>> and that I "should" limit line length to between 72 and 79
>> characters,
>
>Right.  The de-facto historical standard.

Based on what, Hollerith cards? 3270 Terminals? VT-100s? The default size of your Xterms?

>> and that based on the header line setting ("flow"
>"flowed"

Point made ;^)

>> or "fixed") any client that gets my email and can not handle lines
>> between 72 and 79 characters in lenght will
>may, ie, if it feels like it

Your mail client has feelings - you must use emacs (it has everything else. why not feelings?)

>> apply the rules laid out in the RFC to attempt to display the message
>> in a "sane" manner... Couldn't that all be resolved by the viewer
>> including a wrap/no-wrap setting for email display?
>
>Sure, except that it has no particular way to know which emails it's
>appropriate for.  That's why the spec calls for that information to be
>attached to the message.

I think it's "too clever by half", which is why I've choosen not to switch mail clients to accomodate the cited RFC...

>> Finally, just to cite another RFC:
>
>> http://www.ietf.org/rfc/rfc1149.txt
>
>Yeah...so?  If I were upset because other people didn't accept my IP
>datagrams over avian carriers when I were doing it sokme other way,
>that would be relevant.  As it is, you're just being silly.

Hold on, I was just throwing it out there because I like it (as I said, "just to cite anoter RFC" - I didn't claim, nor do I believe in any way that it reinforces my position - it simply was a little piece of candy for readers of my self-indulgent pseudo-rant...

IMHO, plain text is plain text, and your mail client should be able to display it in a meaningful way. If *I* am concerned about presentation of my emails, I'd send HTML formatted emails.

This is only a casual position on my part, I honestly never thought about it - but the RFC is something that your email client can support or not, same as my mail client, it's not required on either end of the transaction, so I consider it optional.

Lionel