antecipate: What are his address handles?

I have described in a previous post a usage of JEP-0030 to discover my own address handles for different addressing spaces. Thinking further of it, and researching the JSF mailing list brought up a slightly different approach to the problem. It is based on the recent trend in using disco queries addressed to a bare JID to retrieve pieces of information about that particular JID. Doing so assumes that the home server is the unique trusted source of information regarding a given JID. This is a very common assumption in the XMPP community, which I believe limiting the case for distributed XMPP information services. Nonetheless, I will present a version of the address handles discovery using the bare JID approach, as it results in a faster discovery process.

The server’s address mapping support is achieved by by issuing a generic item discovery to one’s XMPP home server.

<iq type='get' from='romeo@montague.net/orchard'
      id='info1'>
     <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

The server will provide a response similar to:

<iq type='result'
      from='shakespeare.lit'
      to='romeo@montague.net/orchard'
      id='info1'>
      <query xmlns='http://jabber.org/protocol/disco#info'>
           …
          <feature var='http://jabber.org/address#mapping'/>
          …
      </query>
</iq>

This (non normative) example illustrates how a client application would leverage service discovery to find if an XMPP server provides an address handle mapping service. The server includes the "http://jabber.org/address#mapping" namespace in its features set to indicates address mapping support. As explained earlier we leverage the existing JEP-0033 specification to further query for address mappings. The extended addressing schema supports non XMPP address namespaces through the use of an URI attribute instead of a JID. At this point, the client application will have to issue a query to a bare JID to discover the collection of address handles mapping to this JID. It is matter for JEP-0030 item discovery qualified by a node. The client will issue a query to the bare JID for which the mappings are requested. This example is for retrieving one’s own address handles:

<iq type='get'
      from='romeo@montague.net/orchard'
      to='romeo@montague.net'
      id='items1'>
      <query xmlns='http://jabber.org/protocol/disco#items' 
             node='http://jabber.org/address#mapping'/>
</iq>

<iq type='result'
      from='romeo@montague.net'
      to='romeo@montague.net/orchard'
      id='items1'>
      <query xmlns='http://jabber.org/protocol/disco#items' 
                 node='http://jabber.org/address#mapping'>
            <item jid='romeo@montague.net'>
                <addresses xmlns='http://jabber.org/protocol/address'>
                    <address type='to' uri='mailto:romeo@montague.net'/>
                    <address type='to' uri='sip:romeo@montague.net'/>
                    <address type='to' uri='iax2:shakespeare.lit/555'/>
                    <address type='to' uri='tel:+16135555555'/>
                </addresses>
            </item>
            ...
      </query>
</iq>

At this point, the client application has retrieved the mapping between its own JID and the address handles in different communication namespaces. The same approach can be used to retrieve all Juliet’s address handles, subject to existing ACLs provisioned on the Capulet home server… In the end, this alternative way of querying a bare JID leads to fewer packets exchanged. This alone provides a strong argument in its favor. I still believe it is narrower than the previous method I discussed by limiting the scope of the queries to a JID and assuming the service is provided by the JID owner’s home server.