We don't need to add more cruft to email itself. If you want to create extra protocols for doing different things using email as a medium, go ahead. Email is extendable, as Microsoft, Gmail, Xobni, etc have shown.

Long story short, you can do whatever the hell you want with email. It's not perfect, but it's a really great messaging framework. You can send any message you like, to whomever you like. How the recipient interprets that message is up to them (ie their client).

EDIT: just wrote this up since I'm sick of repeating myself: http://blog.killtheradio.net/technology/email-is-not-broken-...

This is literally what I suggested in the article.

As far as i know, there is no mime-type stuff to the proposed "semantic alternatives".

But I tend to think that's a corner case (email based subscriptions notifications that need to be delivered by non-email means) - we already have tech to do this, between Microformats, RSS feeds with enclosures, and other established attachment formats like vCard and [v|i]Cal. I'm thinking that building on those rather than inventing new and arbitrary JSON syntax to enclose via MIME is probably a better long term strategy.

I also see the distinct possibility of abusive, antisocial behavior. Most people don't understand whitelisting, and the crazies among them already set their email clients to always tag every email from them as being "IMPORTANT", demand read receipts on everything, send HTML only messages, and worst of all, top post.

But there's no way you'll succeed in pushing people to reply to those requests you're making.

Mail to my inbox might be considered 'important' by the sender and might consider a header that makes my MUA ask me if I'd like to confirm that I'd read the message - but I can disagree and decline. In fact, I have rules that filter out important flags at work (they are always abused and there's no need to flag something on your side if I'm reasonably on top of my mail queue anyway) and ignore read receipts (Send me stuff and I read it unless it is spam. But I decide when and won't disclose that with anyone).

Use a good subject and accept that mail is not a real time protocol and we're getting along.

Just know I have a filter to ban those who send read requests too often.

The use case goes in both directions: extensable code means plugins to do what you need, and reusable code means multiple remote services can use the same UIs. Think of a single inbox which natively sends & receives messages with email, private social network(s), twitter, Facebook, LinkedIn, and anything else with a web API (or that can be wrapped in one). Adding new services and/or UIs is just adding a JS file.

So I'm building this HMVC-like mediator framework that uses command objects (which behave like http requests / responses) to try to make that happen. It's kind of like a set of UI-building proxies in the browser. Each module is a contained set of resources which should drop into a URI structure and start working.

I need to refactor the API a bit and write the docs. I also figure it would be cool to package it with some node servers to allow users to install it and run it purely clientside, since all it really needs is config persistence, a proxy to deal with cross-origin, and some gateways to handle oauth.

There are measures to address these issues more broadly with SMTP, but they are not widely adopted, something that could be standardized in a new protocol, ie: encryption by default, message signing to prevent spoofing, encrypted transmission, etc.

In fact email is wrong but so is ADSL's design (using the high frequencies on copper lines) - yet it works. So at the cheapest, email protocol could simply be augmented with a set of metadata which then clients have to somehow integrate.

It doesn't sound like the solution, but it is a quick and dirty fix. And it may be all we need until the real solution emerges, which I think nobody quite knows what it is yet.

1, Acknowledgement of receipt .. this has a whole load of pitfalls to watch out for so you really have to treat email as a send and forget and if you require acknowledgement of a message .. good luck.

2, Timing, email isn't real-time, your message will arrive when it's good and ready.

I build a system that synchronized user data between to organisations. It didn't need to be real time, just a nice feature where a user could change his or her address a the parent organisation and it would later trickle down to other systems.

A second system has handling orders for production of electricity in the Danish power grip. The decentralized power plants had a little as 15 minutes to react. The designers of this system clearly didn't understand email, the assumption was that emails show up in a minute or two, failing to understand that in reality it shows up when, as you say, "It's good and ready".

Email can be a good it for a messaging mechanism, you just need to consider the application. If you need to communicate with a lot of people or system cheaply, and you can afford to lose a message or two, emails fine.

On the other hand, email and ftp is most likely the two most misused protocols ever devised.

Email appealed to me mainly because it explicitly includes identity. The system I was attempting to use it for was an online school data management system that needed to stay in sync with the schools in house data systems. Unfortunately spam filters just kept breaking things, because in the UK many schools have what are know as "managed services" which translates to underpaid keyboard monkeys with no clue running their IT infrastructure.

That may be the reality for sending e-mail to random people on the internet.

However, when both the sender and the receiver are under your control then you can indeed make assumptions about average latency, delivery guarantees and failure modes.

I.e. an e-mail will normally arrive instantly (sub-second) unless it is relayed through an unknown path or the network-path is down.

Most MTA's were not designed to be used as a backend message-queue - but can still work very well for that when configured accordingly, as they have most of the relevant primitives baked in (durability, error reporting, redundancy, re-sends).

There's nothing wrong with piggybacking SMTP for such jobs as long as you know what you're doing.

I don't know about that - I was able to get my dad (not a tech-geek by any means) to understand it enough to start using it very easily.

The Web of Trust may be harder to explain, but you don't need to take advantage of the Web of Trust in order to get value out of PGP/GPG signatures...

Mayhaps I'll have time for that this summer.