Unnecessary "interoperability" drafting

After some time out of the communication realm, I will comment on the presentation of an Internet-Draft that defines how to enable basic interoperability between SIP/SIMPLE and XMPP.

It is funny how interoperability and federation between different communication media is always reduced to "mapping". This is once again exemplified by the draft proposal trying to explain how to achieve this hypothetical interoperability. From the architectural assumption, we already get the feeling this is too good to be true. Being amongst the very few people having implemented a federation between these two protocols, and probably the only one having designed a native SIMPLE connectivity on an XMPP server, I can tell you this is slightly more complex than the draft describe…

The draft goes to great length to describe how to convert between a SIP URI and an XMPP JID. This is an excellent and accurate work, and its undisputable merit lies in providing in one single document a thorough description of each address' syntax. But in real life, what are the chances for the addresses in these two communication spaces to require direct translation?. Not very high. Why would the syntactical similarity between a SIP URI and an XMPP JID provide a guarantee that the same address must be used? After all, we do not translate JIDs directly to email addresses, nor SIP URIs either. We do not translate AIM screen names to SIP URIs, nor to JIDs. In the real world, we perform a lookup of one communication space's address in the other... We use directories to achieve the "mapping", rarely direct translation. The only case where this would be used is when SIP/SIMPLE user agents connect directly to an XMPP server, which is somewhat uncommon.

Where the draft is not up to the task is when trying to map the long term presence subscriptions of XMPP with the short term subscription of SIP. It is all fine when there are no existing subscriptions form either side. In this case, translating an XMPP subscription into a SIP SUBSCRIBE would provide the desired effect. But only the first time. The next time, the permanent XMPP subscription will trigger a presence stanza, instead of a subscription stanza. Nothing in the draft addresses how to handle this difference. In SIP we have a well delimited publish-subscribe behaviour. In XMPP we have a variable context behavior: before and after subscription.

The draft indicates that the XMPP subscription could be terminated by the SIP subscription. But this is not realistic. From an XMPP user's stand point this would mean re-subscribing to the contact on every login. And further on, this would force the XMPP user to accept a SIP contact's subscription for every contact’s log in.

Working the other way round is easier, as it is always possible to translate a SIP SUBSCRIBE into an XMPP subscription. If no subscription exists for the SIP contact, the subscription stanza will be sent to the XMPP user's client if and only if the user is online. If the user is offline, the subscription will be stored by the XMPP server, awaiting the user's acceptance. So the gateway will have to deal with this case, which is not described in the draft. Similarly, the draft does not handle the case where the XMPP user refuses the SIP contact's subscription. In SIP, if a subscription is refused it translate into an error response. The gateway would have to be aware of the presence state of the XMPP user to take the right decision. This asynchronous handling does not easily "map" with the request/response nature of SIP. Following the proposed scenario, the gateway would have to maintain a copy of every user's presence. This is both inefficient and non scalable. And again not very realistic.

As said above, SIP presence is based on short lived publish-subscribe, initiated by the requesting user agent. This is the opposite of XMPP, where the server acts as a proxy for the client user agent. SIP relies on expiration to cancel subscriptions. XMPP sessions do not time out. SIP is connectionless, whereas XMPP relies on the client connection state to deduce the end of a client session. All these fundamental differences are not highlighted in the draft, and as a consequence the cases described are both superficial and incomplete.

In the end, I find no real value in issuing a document whose only real complete description is in highlighting the difference between XMPP and SIP address handles representations. It is also detrimental to reduce interoperability between the two protocols as a simple translation between message types. None of the real issues of application interoperability are addressed in this document which looses all its substance, and by consequence its necessity. Beyond having “the longest title in IETF history” I believe this draft would be better off retracted. This energy might have a better result applied to the Jingle specification…

Technorati Tags: XMPP, Jabber, SIP, Presence, Interoperability, Addressing, Antecipate