An entity is anything that can be addressed in Jabber. A server, a component, a user connected with a client—these are all addressable entities. Every entity is identifiable by a Jabber ID, or JID. These JIDs give these entities their addressability. This is what a typical JID looks like:
qmacro@jabber.org/Laptop
This JID represents a user, connected to Jabber on a particular client. We can look at this JID in a more abstract way, by identifying its component parts:
username@hostname/resource
The username is separated from the hostname with an @ symbol, and the resource is separated from the hostname with a slash (/).
It's quite likely that the JIDs that you may have encountered so far are those representing users' connections, such as the qmacro@jabber.org/Laptop example above. This is not the only sort of entity that JIDs are used to represent. As a Uniform Resource Locator (URL) is fundamental to the HyperText Transport Protocol (HTTP), so a JID is fundamental in Jabber. JIDs are used to represent not only users connected to Jabber via their clients, but every single entity in the Jabber universe that is to be addressed—in other words, that is to be the potential recipient of a message. Before looking at the restrictions that govern how a JID might be constructed (these restrictions are described in the section called Rules and Regulations), let's first have a look at some examples where a JID is employed to give entities their addressability:
A Jabber server is identified by a JID which doesn't contain a username. For basic addressing, the JID is simply the hostname:
jabber.org
To address specific features of the server, a resource is often specified and reflects the feature being addressed:
jabber.org/admin
The JID jabber.org/admin is used by server administrators at jabber.org to obtain a list of online users.
Administrators can send an announcement to all online users on the Jabber server yak by sending a message to the JID yak/announce/online.
yak/announce/online
In this case, the resource is announce/online. The first slash in the JID is interpreted as the separator; the second slash is simply part of the resource name.
Jabber clients can make a request for information on new versions of themselves by sending a special packet to an update server which manages a software version database. The packet they send is a presence packet (see later in this Chapter for an explanation of packet types) to a JID that takes this form:
959967024@update.jabber.org/1.6.0.3
In this case, the important part of the JID is the hostname—update.jabber.org—which is the Jabber server where the presence packet is destined. The username (95996702) is used to represent the unique identification of the client software requesting version information, and the resource (1.6.0.3) is set to be the current version of the client software.
Jabber has a conferencing component that provides group chat facilities akin to IRC. Where IRC has channels, the conferencing component offers rooms. These rooms are addressed with JIDs in this form:
jdev@conference.jabber.org
The room name is specified in the username portion of the JID, and the hostname reflects the address of the conference component.
Browsing is a powerful hierarchical navigation feature in Jabber. When a browse request is sent to an entity, that entity may return various pieces of information which reflects its component parts—how it's made up, what services it offers, what features it has, and so on.
The browse request is addressed to the entity via its JID, and the component parts that are returned in response are all identified with JIDs too. If we address a browse request to the JID yak/admin, we receive a list of online users. This is shown in Example 5-1.
Example 5-1. Querying the server yak for online users
SEND: <iq type='get' to='yak/admin'>
<query xmlns='jabber:iq:browse'/>
</iq>
RECV: <iq type='result' to='dj@yak/console' from='yak/admin'>
<item name='Online Users (seconds, sent, received)'
xmlns='jabber:iq:browse' jid='yak/admin'>
<user name='dj (548, 18, 15)' jid='dj@yak'/>
<user name='john (535, 11, 13)' jid='john@yak'/>
<user name='jim (488, 15, 17)' jid='jim@yak'/>
</item>
</iq>The JID yak/admin represents an administrative function in the Jabber server yak; it identifies the place—the service entry point—by Jabber address, where this information can be retrieved.
Example 5-1 shows how pervasive the JID is as a mechanism for identification within Jabber. How we might use the information returned to us is not relevant at this point; the key thing to note is that the hooks used in conversations to jump from one point to another, to refer to other entities—services, users, transports, call-hooks into a server to obtain specific information—take the form of JIDs. Each one of the highlighted attribute values in the example is a JID. [1]
Taking another example from the conferencing area, JIDs are used to represent those present in a room in an abstracted way. Each room participant has an identity specific to that room:
jdev@conference.jabber.org/bd9505f766f98bd559d4c2d8a9d5ae78e3a7bbf5
As before, the room itself is represented by the username@hostname parts of the JID—in this case it's the Jabber Developers room hosted on conference.jabber.org. The resource is the long hex number which represents an individual room participant. It's a hexadecimal SHA1 message digest of their JID, designed to be unique, and calculated and assigned by the conferencing component as a user enters the room. [2]
As you can see, JIDs are flexible identifiers used throughout Jabber to give addressability to various entities. In the context of the JSM and user management, the address structure username@hostname has many parallels with email addressing, and indeed not without reason. In the context of individual users, an email address represents a user on a specific email server. This server is their "home", their mailbox to which everything addressed to their email address is routed. Different email users have different home mailboxes. In the same way, the JIDs of different Jabber users reflect each user's home Jabber server, to which everything addressed to their JID is routed. A message addressed by a user based on one Jabber server to a user based on another Jabber server is automatically routed from the one server to the other.
A JID must contain a hostname part to be valid. The username and resource parts are optional; circumstance and usage dictates where either of these parts are necessary. A username is specific to the hostname that it's paired up with. For example:
qmacro@jabber.org
is not the same as:
qmacro@jabber.com
There are some restrictions on how each JID part is composed; Table 5-1 details these restrictions. Although you can be particular about the case of letters in a username, any operations (such as comparisons) at the Jabber server are case-insensitive. For example, if a user has registered dj as their username, then another user cannot register with the username DJ. However, the person who registered as dj can connect and send DJ when he authenticates, and for the duration of that session will be known as DJ not dj.
On the other hand, resources are case-sensitive.
Table 5-1. JID restrictions
| JID part | Restrictions |
|---|---|
| username | A username can be up to 255 characters in length, and may not contain any ASCII character under 33 (decimal), [a] nor can it contain any of the characters :, @, " or '; also whitespace (tabs, newlines, and carriage-returns) and control characters are forbidden. |
| hostname | The same restrictions apply here as for normal DNS hostnames. |
| resource | There are no restrictions for the resource part of a JID. |
| Notes: a. that is, it may not contain spaces or those considered to be control characters | |
| [1] | This administrative information about online users on a Jabber server can be retrieved by sending the IQ-get element shown in the example. However, the information is only forthcoming if the user making the request—sending the IQ-get element—is administrative user. See the the section called Administration in Chapter 4 for details on administrative users. |
| [2] | This is to shield the participant's real identity, which is the default setting for a conference room. |