antecipate: Phone numbers JID or extended address?

At this point, XMPP lacks a standardized way of addressing of a PSTN number. As usual, in order to achieve this definition, I would advocate re-using existing published standards and adapt them to the XMPP adressing scheme.

I see two different approaches to solving this issue:

Create a syntax to express a phone number as a JID.
Make use of the extended stanza addressing and include an existing URI scheme using the external uri form of the address element.

On one hand, XMPP entities are addressable with an URI containing a set of ordered elements formed of a domain identifier, node identifier, and resource identifier. In short a JID looks like node@domain/resource. This form is similar to existing addressing schemes defined to represent a phone number. So it should be easy to define an appropriate syntax to incorporate a phone number in the node part of the JID. A possible approach could be to map the JID node to an E.164 number (international public phone number) and create a JID of the form +15551234@domain/resource.

On the other hand, the extended addressing approach requires adding an address extension to every stanza targetting a phone number. But in this case the extension directly holds the phone number URI without any need to define an additional syntax for the JID. We could then use the tel URI for telephone number existing IETF standard. As this approach is also used by the SIP signalling protocol when dealing with phone numbers, it could simplify gatewaying to SIP based VoIP networks. An extended phone address would lokk like:

Both approaches have pros and cons.

Pros: the phone JID is easy to understand and can be handled like any other JID, allowing for example to define contacts in a roster directly as phone numbers. The extended addressing decouple the phone number representation from XMPP, and is directly usable in gateways, and allow all the semantic of the phone URI without impacting XMPP.

Cons: the phone JID implies a specific semantic in the addressing scheme. In short, there is logic in the address, and a compliant implementation must decode the JID to extract the phone number. The extended addressing is slightly more difficult to implement and render in a traditional XMPP client.

If we have this standard addressing scheme in place, then it becomes easier to hide many of third party providers addressing disparity behind a Jingle service implementation. My recommendation is to use the extended addressing approach, as it would be wrong to overload the XMPP JID scheme with adressing format logic. A JID’s primary role is to allow stanzas routing to a destination. We must keep it that way.