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.
> 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?
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)
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).
