41–50 of 120 posts
Does it solve SPAM problem?
Nope, that needs to be solved in SMTP. Unfortunately, JMAP only replaces IMAP/POP. I have personally been working on a new protocol that replaces both IMAP and SMTP. It's not ready yet, but the solution turns out to be quite elegant and I have great hope that it will work in the future.
Earlier quoted context omitted.
"possible to replace with alternatives" != "useless"
By useless I meant that the use of HTTP doesn't contribute anything essential. Though maybe I could be wrong? But that's what I understood by "is not core to its operation". I understand it to just wrap the JSON in HTTP for the benefits that come from its ubiquity in use and not so much because of merits of the mechanisms described in the HTTP spec.
Ubiquiti is a feature. Not having to explain the caching model to people is a feature.
Does it solve SPAM problem?
I haven't read JMAP, but I don't think that's the problem it's tackling. Also, I think SPAM is as solved as it can be with blacklists, heuristics-based filtering software like spamassasin, and personal filtering with sieve scripts. What else would anyone suggest?
What are the optimizations in JMAP that make it faster than, say, Solid? Solid is built on a bunch of W3C Web, Security, and Linked Data Standards; LDP: Linked Data Protocol, JSON-LD: JSON Linked Data, WebID-TLS, REST, WebSockets, LDN: Linked Data Notifications. [1][2] Different worlds, I suppose. There's no reason you couldn't represent RFC5322 data with RDF as JSONLD. There's now a way to do streaming JSON-LD. LDP…
Is there a reason you'd want to? I clicked all your links but I still have no idea what Solid is.
If this takes off, it would remove one of the last few holdouts of non-HTTP application specific protocols. That just leaves us with SMTP really. While using HTTP is not necessarily a bad thing, it's certainly an interesting indication of how application developers prefer convention based protocol definitions (JSON over HTTP) instead of having a strictly defined protocol over a duplex stream (IMAP over TCP).
If this takes off, it would remove one of the last few holdouts of non-HTTP application specific protocols. That just leaves us with SMTP really. While using HTTP is not necessarily a bad thing, it's certainly an interesting indication of how application developers prefer convention based protocol definitions (JSON over HTTP) instead of having a strictly defined protocol over a duplex stream (IMAP over TCP).
Why is this happening? Forgetting ubiquity of tooling, is there something technical about HTTP that makes it so attractive? I get JSON. People don't want to write text-parsers. But what's attractive about this abuse of HTTP? This isn't hypertext. Is it so complicated to work with a duplex-stream? Could a library alleviate the complications? Could it be that developers are more familiar with HTTP than with TCP and so…
Slightly different than ubiquity of tooling is firewall policies: HTTP(S) is the protocol most likely to get where it needs to without someone configuring something to allow it, so tunnelling everything over HTTP(S) is the path of least resistance to widespread use.
Earlier quoted context omitted.
The IETF's standardisation process almost can't help but improve whatever it is you're trying to standardize. Not only are you being shepherded by peers with expertise in whatever corner of networking you're excited about (the Area Directors for whichever Area your Working Group was assigned to) but you're obliged to put up with anyone who cares to offer an opinion mailing it in. Looking for consensus isn't a good wa…
JMAP is still young; just wait until a plethora of non-interoperable optional extensions get added.
What are the optimizations in JMAP that make it faster than, say, Solid? Solid is built on a bunch of W3C Web, Security, and Linked Data Standards; LDP: Linked Data Protocol, JSON-LD: JSON Linked Data, WebID-TLS, REST, WebSockets, LDN: Linked Data Notifications. [1][2] Different worlds, I suppose. There's no reason you couldn't represent RFC5322 data with RDF as JSONLD. There's now a way to do streaming JSON-LD. LDP…
> There's no reason you couldn't represent RFC5322 data with RDF as JSONLD. There's now a way to do streaming JSON-LD. Is there a reason you'd want to? I clicked all your links but I still have no idea what Solid is.
https://en.wikipedia.org/wiki/Solid_(web_decentralization_pr...
They're not just doing IMAP over http, they invented their own error bodies, schema's , negotiation and RPC.
Earlier quoted context omitted.
> I think that part actually works fairly well today (not optimally, but well enough in practice). I haven't done much with IMAP, but I did setup a watcher for my mailboxes that uses the IDLE extension. I consider it a flaw that I need to create a separate connection, each needing their own session, for each folder I want to watch simultaneously. Servers understandably limit the amount of simultaneous connections you…
Being unauthenticated as a default certainly doesn't jive with modern security practices.