On XMPP, Federation and URLs in Emails

URLs in emails is part of our future. Don't waste time complaining about it.

Each blog has a subtopic that when written about – all hell breaks loose – it brings the comments in. For most technology blogs that would be saying something bad about Apple. For my previous blog, it was definitely XMPP. And here? Probably federation. Who would have thought that a post outlining the options of federation with WebRTC will bring so many comments.

This being the case, I had no choice but to write about this topic yet again. We'll see what happens next.

-

Philipp Hancke, who commented on my post, and is very involved in the realm of XMPP, wrote a post about the fact that sending URLs isn't a signaling protocol. While I agree to this statement, I think it is irrelevant. And I had to somehow comment.

Essentially, there are four reasons Philipp gives:

1. Sending emails isn't real-time. There is a need for an acknowledgement of receipt
2. Due to lack of feedback, the caller might hang up, and then how the callee gets notified?
3. The callee might reject. How is the caller get notified?
4. What happens to the URL after the call? Is it an identity? Does it become invalid?

Somehow, these reasons are unsatisfying. They assume that the basis of communication is a telephone session. While that may be true, it isn't necessarily the case. They also assume naively that the URL is the only mechanism in the proprietary signaling protocol, and it ends with the assumption that there needs to be an identity of sorts.

Here's how this doesn't match reality.

Acknowledgement of receipt

Emails can do acknowledgement of receipt. Nobody uses that, but they do. At least Outlook does.

I can also acknowledge the press of the link if the URL being sent has some identifying key/hash/whatever in it that is unique to the participant I invited.

Thinking about it, even when I dial someone, I can't really know if he missed my call because he didn't hear the ring, was just busy doing something else and couldn't pick up or something malfunctioned on his end.

Besides – I can always ask – or place the email in a calendar invite and wait for an acceptance, which is an acknowledgement of sorts.

Notifying on rejections and hang ups

What this is all about? Handling rejections and hang ups can be done once the URL is browsed. It is up to the application developer to figure this one out and to build it into his solution, which is the whole idea of proprietary – let the developer of the service decide what fits into his scenario and don't bog him down with all sorts of modals that might not even fit what he wants to achieve.

Identity

Identity who? Why is that needed exactly? I do a lot of different types of calls. The business ones often times end up on one service or another at a virtual space, either a static one or an ad-hoc allocated one – with a one time URL.

Who cares?

When I care, I select an identifiable service – with our without a URL attached to it.

-

Signaling protocols are no essentially irrelevant. They are needed and necessary, but they are by no means important or at the heart of a solution. What I am seeing is a large number of vendors forgoing treating signaling as some Holy Grail and just packing it into the application logic layer – where it should really reside if you are trying to deal with customized business processes.

Need SIP or XMPP? By all means use it, but why force it on the rest of humanity?