Addresses are for routing

I was reminded by a reader's comment that address handles are still given properties beyond their only designed role: addresses are for routing. That is, routing only. Any attempts at loading an address handle with an additional meaning is only creating confusion. Address handles are not identity tokens. Address handles must not provide application logic. This bad practice is the best way to create lock-ins and decrease applications' scalability and extensibility. An address handle must be used in a single context: to indicate the destination of a communication.

This foreword done, the comment originated from the need for proper conversion rules when translating addresses from a communication space into another. The example was taken from the current XMPP transport practices, where the non-XMPP address handles are encoded as the node part of a JID. I believe this practice is wrong and does not possess any good technical grounding.

In an XMPP addressing space, a component such as a transport will have a JID comprised of a domain part only. Let's say "transport.montague.net". If a user on the XMPP side of the transport has contacts in the legacy side, the common practice is to apply an encoding logic on the legacy address to build the node part of a JID representing that contact in the XMPP world. The result might look like "juliet%capulet_it@transport.montague.net". The issue with this conversion lies in the resulting urge by many developers to use this "logical" encoding of the node to derive a meaning in a client for example. If the contact JID had been "a2ff356@"transport.montague.net" the programmer would never had used the node for anything but its role. The opaque node keeps all the routing properties of an good address handle, which in this case requires that a stanza using this JID be routed to the "transport.montague.net" service. It is also easy to see that this approach is completely independent of the target legacy system.

Introducing a logic in the node encoding of early transports has

• induced developers to reverse this logic inside their code, creating a de-facto legacy inside the XMPP clients and transports implementation,
• imposed at a time different encodings because the target legacy systems have different addressing spaces syntax.

Lastly, I believe there is no good reason to use a logical encoding of the JID's node for legacy contacts. Finding the contact's address can be achieved by looking-up the opaque node value in a cached table to obtain the legacy address. In terms of performances, I believe the time difference between a lookup and a decoding does not count much when compared to the actual transport wire transmission overhead.

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