(Edit: since I got mine it’s acquired the word ‘international’ but lost the word ‘driving’. Swings and roundabouts.)
https://en.m.wikipedia.org/wiki/International_Computer_Drivi...
Admittedly I haven't looked into it because I'm perfectly fine with top posted emails. But I routinely sort files in my directory. Why not emails in a displayed thread?
The ability to semantically parse text to determine what order paragraphs should be displayed in to suit the tastes of the individual reader is a very recent development. Or, rather, will be soon. Maybe not very soon.
If you need to address a specific point in a message you're replying to, quote just that bit.
We are emailing TBs of data around daily that provides no value to anyone.
The point of bottom posting was you never left the original text intact, but trimmed it to show the relevant details you are replying to and so enhance readability. Exactly as I am doing now in this reply.
> If you need to address a specific point in a message you're replying to, quote just that bit.
Precisely. Just like this. We are on the same page!
- parsing the unstructured email body and looking for quote levels, html formatting and printed email heads
- parsing certain headers like message-id, in-reply-to, dkim sig
- looking for sections of the message body in the inbox
This is done because there is nothing in the protocol to cleanly accomplish what you want. Even if there was, you could not rely on it at all. Doing anything with email is a gigantic PITA, you sometimes get emails where the msg-encoding header doesnt match the body's encoding, html in the plaintext section and other fun things.
Since nobody really cares about the RFC and just does their own thing, there is no chance at improvement.
I came up with a routine to parse and translate about 2-3GB of saved emails into MBox format once.
The official delimiter is unbelievable, IMHO.
« the exact character sequence of "From", followed by a single Space character (0x20), an email address of some kind, another Space character, a timestamp sequence of some kind, and an end-of-line marker. »
https://datatracker.ietf.org/doc/html/rfc4155
https://en.wikipedia.org/wiki/Mbox
That's it. An email is a section of text beginning with
From $something
That's the spec.
It's one of the things I like about Gmail. It does plain-text and bottom quoting just fine.
> Let’s face it, the world has moved on, new generations are online, and we are the wrong ones now.
NEVER GIVE UP! NEVER SURRENDER!
https://mygeekwisdom.com/2014/03/15/never-give-up-never-surr...
However, the original email is included as a convenience in case my MUA doesn't support threaded display or it's a mailing list I joined after the original email was sent or any other reason why I might not see it. That's why there is quoting at all.
Nobody top-posts when using selective quoting because obviously it's different.
The biggest and most successfull FOSS project of all time is coordinated entirely by email. These are the rules:
https://subspace.kernel.org/etiquette.html
Again: you are wrong.
> Again: you are wrong.
No, you.
Immediate and indefinite suspension of email license.
Q: Why is top posting bad?
- New text conversations show at the _top_ of the list of conversations - New messages are at the _bottome_ of a conversation - New emails are at the _top_ of your email client (?) - and now you remind me that email replies can be both at top and bottom (:
It feels arbitrary, but I suspect this is due to the heritage of paper, where newer things are on top of the pile, but in a given document, newer text tends to be added at the bottom/end. (it's a stretch :))
Bottom posting replies was the default in all early email and USENET clients.....
Then MS Outlook came along, which was the first email client to break convention and default to top posting (i.e. putting the cursor at the top when replying to a message). Thence forth, "office" users began top posting, and the confusion began.
To this day, the old guard (like me) bottom posts and always trims the above quoted text of irrelevant details (!). Anything else was considered not only lazy and sloppy, but the mark of a noob with bad netiquette.
Even though X.400 is no longer officially feature of Exchange, the entire data model of MAPI is based on it, shared between Outlook and Exchange, with somewhat lossy translation when it has to go outside of X.400-over-RPC that MAPI provides.
Sometimes you can get burned by vestigial parts of the model, like how MS MAPI implementation as provided by Outlook/Exchange (there used to be others!) does not actually support HTML email, and crashes with corrupted message errors if given an email object containing a HTML body.
Now I can hear you going "but Outlook does HTML email!".
Outlook converts HTML email body part into RTF-wrapped HTML and stores the resulting message in RTF body field of message object. In fact, before Outlook got changed to convert RTF to HTML, Outlook users were infamous for sending RTF formatted emails (at least RTF was always documented, as it was supposed to be interchange format).
But MAPI messages do also contain a HTML message body field... But if you put HTML there, MAPI.DLL explodes - or at least did every time I did it.
In reality it's:
Q: Why is bottom posting bad?
Q: Why is bottom posting bad?
A: Because it repeats itself.
Q: Why is bottom posting bad?
A: Because it repeats itself.
Q: Isn't this also a problem with top posting?
Q: Why is bottom posting bad?
A: Because it repeats itself.
Q: Isn't this also a problem with top posting?
A: No, because the reader skips to the next message when they get to the quoted part.