5 ms·
But those are problems with /the client/. Not the protocol.
by darau1 5y ago
But those are problems with /the client/. Not the protocol.
- paxys 5y agoThey are all problems with the protocol, considering that the protocol doesn't define how to do any of this.
- darau1 5y agoThen should we not amend the protocol to define these things? Why reinvent the wheel, when we could improve it?
- paxys 5y agoYes we should, but people have been trying for 20 years and it hasn't happened yet. The wheel has been successfully reinvented already. The biggest reason for it is that in practice email isn't as open and decentralized as people like to think. For most of its history all advancements were controlled by Microsoft, AOL and Yahoo, and today it is controlled by Microsoft and Google.
- jjav 5y ago> Then should we not amend the protocol to define these things? Most of the OP list of things they don't like are about client UI presentation. Inherently unrelated to the protocol itself. I don't have any of those issues because I use a client that does the interaction and presentation exactly how I like it.
- darau1 5y agoWhat client is that?
- jameshart 5y agoI don’t understand how your client can solve for someone else sending you top-quoted replies, or word-html-engine compatible HTML designed to work in outlook. Or eighty other people hitting reply all on the email chain you’re on. The clients other people use can behave completely differently, because the protocol leaves so many decisions up to clients.
- jjav 5y agoYou're adding things not in the OP list I was responding to so I didn't claim that. But let's try: Reformatting top-quoted replies. This is possible with email because you can pipe the messages through any preprocessing you want. Inserting custom processing into the delivery pipeline is generally impossible with all proprietary systems, but easy with an open standard like email. HTML formatting: Again, easy due to customizable preprocessing and/or viewers. Eighty people responding to a thread: This is threading, handled natively by most good email clients. Gmail makes a mess of it though, so I get why it'd be painful if you use gmail. Don't use gmail. > because the protocol leaves so many decisions up to clients. I feel like this is a misunderstanding. The clients have nothing to do with the protocol (SMTP), that's the job of the MTAs (mail transport agents). The client provides the UI/UX interaction part. It is an immense strength of standards like email that there are tons of clients. You may want a completely different UX with your email than me, so you're free to have it exactly the way you want and so am I. And we can still message each other. This is impossible with proprietary walled gardens.
- jameshart 5y agoClient support for the features you’re talking about has everything to do with the protocol. How are you threading if not based on SMTP headers? What SMTP headers are meaningful for threading? What does SMTP have to say on the subject? Nothing - because it only talks about MTA behavior not clients.
- babypuncher 5y agoYou have some magical email client that turns "reply all" firehoses into clean Slack/Discord-style message threads?
- jjav 5y agoSlack threads are the worst possible UI ever, so that's not something to aspire to. Email threading is trivial, nothing magical about it. Most every decent email client will properly thread conversations. Gmail will not, so yes gmail is super painful for long threads. Use a better client.
- chii 5y agoThe protocol doesn't need to define any of those things. Just like HTTP doesn't define what goes on inside the viewport of the browser.
- babypuncher 5y agoThat is the problem. The protocol doesn't dictate how prior messages in a thread should be included or referenced. So any given thread is a hodgepodge of different solutions, making for an ugly, unreadable mess. Some clients try to clean this up, but it's basically an impossible task when you have no way of knowing what other clients will do.
- deleted 5y ago[deleted]