3 ms·

I didn't explain it fully, but the alternate future I was imagining was one where SMTP could evolve/instantiate a connection for "ASAP email" -- AKA instant mes

I didn't explain it fully, but the alternate future I was imagining was one where SMTP could evolve/instantiate a connection for "ASAP email" -- AKA instant messaging. Kinda like how HTTP can upgrade to websockets. There would obviously be a lot to work out, but if something like this was in the SMTP standard (or at least introduced), I think eventually email providers would race to differentiate themselves with support for it, and we might not be where we are today. In my view there's no reason to even require the SMTP servers to serve chat traffic -- as long as they could hand off reasonably, and everything spoke the language as specified in the spec (or at least came close).

toomuchtodo 8y ago
I don't want instant messaging in my email though. If you need synchronous communications, use a chat client.
- hardwaresofton 8y ago
  This is probably where we differ -- I don't think limiting email to asynchronous communications helps anyone, and it could have been written in an extensible manner to also support synchronous communication. Even if I'm completely wrong and email should be left asynchronous, SMTP could at least have introduced some standard around chat negotiation and a protocol negotiation process for remote chat servers/agents.
  - toomuchtodo 8y ago
    > Even if I'm completely wrong and email should be left asynchronous, SMTP could at least have introduced some standard around chat negotiation and a protocol negotiation process for remote chat servers/agents. Wouldn't this be best handled with SRV DNS records or some other service discovery process outside of SMTP? https://wiki.xmpp.org/web/SRV_Records https://wiki.xmpp.org/web/SRV_Records
    - hardwaresofton 8y ago
      I agree that it would be but my wanting to bundle it with SMTP is for forcing the linking of the two concepts -- I guess my argument is less technical and more that I think the two concepts should have been linked early on -- I think if we'd bundled email and instant messaging (aka "live" or "instant" email), we would have encouraged service providers to offer the service in a standards compliant way. I don't have a preference on exactly how the service discovery would work -- I'm merely suggesting instant messaging could/should have been an extension of the SMTP spec like websockets were an extension of HTTP. [EDIT] - Looking over the link you sent, that is exactly what would have made a good addition in my mind -- if SMTP had some sort of functionality to suggest that XMPP was available and where to check (DNS SRV records)
      - toomuchtodo 8y ago
        After thinking about it some more, I agree with you. There should be some command or extension in SMTP and JMAP that, if the user permits it, the availability of XMPP could be exposed and a redirect of some sort could be provided (similar to intentions on iOS).

toomuchtodo 8y ago

I don't want instant messaging in my email though. If you need synchronous communications, use a chat client.

hardwaresofton 8y ago
This is probably where we differ -- I don't think limiting email to asynchronous communications helps anyone, and it could have been written in an extensible manner to also support synchronous communication. Even if I'm completely wrong and email should be left asynchronous, SMTP could at least have introduced some standard around chat negotiation and a protocol negotiation process for remote chat servers/agents.
- toomuchtodo 8y ago
  > Even if I'm completely wrong and email should be left asynchronous, SMTP could at least have introduced some standard around chat negotiation and a protocol negotiation process for remote chat servers/agents. Wouldn't this be best handled with SRV DNS records or some other service discovery process outside of SMTP? https://wiki.xmpp.org/web/SRV_Records https://wiki.xmpp.org/web/SRV_Records
  - hardwaresofton 8y ago
    I agree that it would be but my wanting to bundle it with SMTP is for forcing the linking of the two concepts -- I guess my argument is less technical and more that I think the two concepts should have been linked early on -- I think if we'd bundled email and instant messaging (aka "live" or "instant" email), we would have encouraged service providers to offer the service in a standards compliant way. I don't have a preference on exactly how the service discovery would work -- I'm merely suggesting instant messaging could/should have been an extension of the SMTP spec like websockets were an extension of HTTP. [EDIT] - Looking over the link you sent, that is exactly what would have made a good addition in my mind -- if SMTP had some sort of functionality to suggest that XMPP was available and where to check (DNS SRV records)
    - toomuchtodo 8y ago
      After thinking about it some more, I agree with you. There should be some command or extension in SMTP and JMAP that, if the user permits it, the availability of XMPP could be exposed and a redirect of some sort could be provided (similar to intentions on iOS).