HTTP Access to Email Stores | Hacker News Reader

HTTP Access to Email Stores

tools.ietf.org

58 pointsrvkennedy25 comments

We're not talking about webmail here, but direct access by HTTP request, either from a website or a desktop/mobile client. Some other relevant links for this:

http://blog.gaborcselle.com/2010/02/how-to-replace-imap.html

http://blog.webhooks.org/2009/02/13/restful-email-over-http/

HTTP has had about 20 years of use, development, testing - culminating in SPDY now, which could get even 40% faster in some cases. I'm not sure I can think of a good reason not to make the switch.

There's probably more overhead in the request via HTTP than there is via IMAP, to be honest. I can't see any reason to make this switch other than being able to support port 80.

The reason is to write standardized webmail applications and other javascript apps that want to interact with the email universe.

> I'm not sure I can think of a good reason not to make the switch.

IDLE? Tagged, out-of-order replies?

You can probably make a SPDY-based protocol that does 99% of IMAP, but HTTP is too limited for current IMAP possibilities.

I guess I'm not really sold on why this is better than IMAP, which is a protocol that, um, actually exists and you can use today.

Fixing the perceived drawbacks of IMAP would seem to be a more productive goal than trying to produce a competing protocol/standard. (Cf. http://xkcd.com/927/)

How about we get rid of all the MIME/XML stuff and just represent emails as JSON objects?

The end.

...in UTF8.

Of course. As far as I'm concerned, you'd need a very good reason not to use UTF-8.

There are severe issues disassociating files from their native character set when you start dealing with east asian languages and the large amount of existing systems that you are dealing with. Forcing everyone in the world to use UTF-8 is not a legitimate option: it's great if you don't already have something more powerful (like MIME), but it should not dismantle existing known/working setups.

JSON is a MIME type.

Obnoxious, cryptic, and incommunicado?

application/json

You could fairly easily add conneg (yuk) or an alternate json representation to the atom feed... Given that the headers are name value pairs it shouldnt be too hard to standardize.

Multipart MIME is fairly clever in that it provides a reasonably human-readable fallback for old clients that don't support it. I'd be very wary of throwing that out. One of the benefits of plain-text email is its universality.

The only way I can see that working out would be if MTAs and MUAs negotiated during handshaking to decide on what message format they preferred, and then the MTA translated the message either to traditional RFC 2822 or some other preferred format, which could be JSON or pure XML or whatever.

If we get rid of MIME, won't we have gotten rid of HTTP?

If we're going to keep moving more and more apps from native to Web-based, I think we're going to see a lot more of this (standardizing an existing service to be accessible over HTTP), since WebSockets can't connect to any raw TCP sockets (and they shouldn't, that would be terrible security-wise) and WebRTC has the same approach: a protocol of its own with its own handshake & rules.

Better that than have everyone builds its own incompatible HTTP / REST API for common services.

I do wonder if there's any big companies like Google which have pledged to support this spec?

Didn't Outlook Express use some sort of DAV HTTP protocol to retrieve email from Hotmail?

1.2. Existing Work.

[...]

Microsoft did some early work on HTTP access to email. The Outlook Express client application uses a fully HTTP-based interface to do all mail functions on Exchange mail stores as well as Hotmail. At the time, Hotmail could or did not support IMAP. The Microsoft API uses PROPFIND to list mailbox contents (this mechanism predated Atom by several years).

Exchange also supports WebDAV - Outlook web access uses(d?) it. In fact, this became one of the easiest ways of integrating with Exchange server. Now that Exchange 2007+ has a full web services API, I hear the DAV stuff has been deprecated.

And I don't think it is in Exchange 2010

I'm not familiar with the IETF process, but it says "Expires: April 27, 2009"

With that said, I've been exploring the concept a while back myself. I tend to think of email as the largest "social" network in the world, and I think it's good to give it a sexy web face, and then extend it.

https://github.com/pepijndevos/Wemail

FYI, Context.io does something similar to this. I know a few YC companies use them.

What is the mark up language used for this plain text file? I really like the format of these minimalist 1 page documents.

I don't think there's a language, I believe it's just plain-text that gets marked up by rfcmarkup[1].

[1]: https://tools.ietf.org/tools/rfcmarkup/

The markup is defined in RFC 2629.

Actually I think that the CSS is what is appealing, not the source marked up file.

If you want, you can convert Markdown into RFC 2629 documents with <https://github.com/cabo/kramdown-rfc2629>.

Reply on news.ycombinator.com