This article was initially published in French, and it got some interest, so we started to translate the whole series in English. If you can read French, you can follow the whole series there: http://www.goffi.org/tag/parlons_xmpp

Now that we know what we’re talking about, let’s see what the core of the protocol looks like.

 

Originally, XMPP is defined by 3 (previously 2) RFCs: RFC 6120, RFC 6121, and RFC 6122 (there are others, but these 3 are the main ones). They explain the core of the system, such as sending messages, presence information, statuses and so on.

 

Without getting too much into details related to developers, we can quickly explain that XMPP is based on 3 element types, or “stanzas”:

• <presence/> to primarily indicate… our presence information (sometimes, we also add other things like our avatars, our capabilities, but let’s stay focused). The presence is broadcast by the server to all the people that you have given permission to (see below).
  We can associate a state and a message to our presence. The state can be one of the following (names can change depending on the client):
  • available (default): you’re online.
  • away: you’re away for a short period
  • chat: you want to talk
  • dnd (do not disturb): you’re occupied (often called “busy” in clients)
  • xa (eXtended Away): you’re away for a long while.
  The status messages allow you to specify your availability in a clear language (for example: “I’m watching a movie, do not disturb”), even though, in practice, it is used for any kind of message (a lot of people use a quote, for example).
• <message/> A message’s sending of type “send and forget”. There are 5 types of messages::
  • chat: the most well-known message, used for simple instant messaging;
  • error: this one is usually managed directly by client software. It is often shown by means of a notification window in your client, indicating that something wrong occurred;
  • groupchat: as “chat”, but for discussion with multiple people. In practice the difference concerns only developers and it should be transparent in the client;
  • headline: an important message, an announcement. Normally, these messages aren’t kept offline, so if you aren’t connected while the message is sent, you shouldn’t receive it. These messages don’t expect answers. A typical example is an announcement for an imminent server maintenance;
  • normal: a little known yet interesting type. It is a message which generally has a subject, but outside of an instant conversation. Yes, exactly like an email! It is more or less its XMPP equivalent.
  Conversation threads are managed as well, but we’ll talk about it another time.
• <IQ/> (Info/Query): used for everything that works on a question/answer pattern (it is mandatory to provide an answer to an request, even if you need to reply with an error). This is used mainly by developers, as it serves as a basis for most of the features you need. Using it is like saying "I need to know or edit this information".

 

I don't want to delve into technical details, but it seems essential for a user to know different message and presence types to understand their client.

 

One should note that there is an excellent feature that is largely underused in XMPP: it natively knows how to handle different languages because of its inheritance from XML (xml:lang). In other words, you can specify a normal or status message in French, German and Slovak at the same time. This is a major asset that we intend to use in Libervia.

 

Now let's talk about another essential part: the contact list.

 

It is called "roster" in the XMPP world. You can assign 0, 1 or several groups ("family", "friends", etc.), a name (which is an alias chosen by yourself, not by your contact), and subscription information to every contact you add to your roster.

 

Subscription lets you know whether you have allowed your contact to see your presence information and whether you are allowed to see theirs. Therefore, every time someone adds you to their contact list, your client (e.g. Gajim) asks you whether you wish to grant them access to your presence information. Note that these permissions don't need to be symmetrical: a contact may have been allowed to see your contact information without enabling you to see theirs, and vice versa. It might even be possible that neither of you can see each other's presence information (but I think most clients remove the contact from the roster in that case).

 

Groups are dependent on contacts, not the other way around (it's not a list of groups which contains the contacts): this explains why having an empty group (i.e. without any contact) isn't possible. In my opinion, groups too are underused in the XMPP world, but we'll get back to this.

 

 

That's it for today. I opted to keep the part on extensions for the next post to keep this one lighter.