Programming Jabber

What the reflector is actually doing

Each of the JIDs that are browsed to look like this:

[component name]/[relative LDAP DN]

such as:

ldap.cicero/ou=UK, ou=People

The hostname part of the JID—[ component_name ]—is the name of the LDAP reflector component, and the resource part of the JID—[ relative_LDAP_DN ]—reflects the DN of the node (minus the base DN suffix) within the LDAP structure that the <item/> with that JID represents.

The crucial bit is that the [ component_name ] part remains the same (ldap.cicero) across every call. This means that all of the jabber:iq:browse requests made in the navigation sequence go to the component, in this case, the ldapr script.

Once the component receives these requests, it disassembles the JID, extracting the resource part, and uses it to query the LDAP server on the Jabber client’s behalf. It then builds a response, in the form of an IQ-result containing the all-important jabber:iq:browse-qualified extension, containing the results of the LDAP query.

JIDs are used to convey information to the component, as well as to have the request delivered to the right place.

Using JID Parts to Convey Information

The example from Section 6.2.5.1 showed the information being conveyed as the user part of the JID:

<item name='ou=People' jid='ou=[e-mail]'/>

This is perfectly fine, as long as the information we want to convey doesn’t contain characters deigned illegal for that part of the JID. There are far fewer restrictions on how the resource ...