Aunque la funcionalidad de entrega de mensajes y presencia ya existía en el protocolo Jabber original, las extensiones principales de XMPP incluyen funcionalidades de autenticación, seguridad, privacidad y control de acceso según dictamina el RFC2779.
XMPP también soporta el Modelo de M.I. y Presencia del RFC2778 (A Model for Presence and Instant Messaging). También cubre problemas de localización e internacionalización y además extiende las características de los RFC2778 y RFC2779 para, por ejemplo, lograr chatrooms.
La arquitectura XMPP consiste en servidores XMPP, clientes XMPP y gateways para sistemas externos (no-XMPP), cada servidor entrega mensajes a través de una red de servidores XMPP y/o Gateways hacia los clientes, adicionalmente al servicio de ruteo de mensajes y de administración de conexiones, los servidores XMPP ofrecen a los clientes servicios de almacenamiento de información inherentes al cliente como ser listas de contactos (llamados Roosters en XMPP).
La conexión entre servidores (o componentes de servidores), gateways y clientes es sobre TCP/IP, (aunque no es un requerimiento necesario el de utilizar mensajería sobre TCP/IP, es el único método de transporte que hace referencia la especificación).
Los Gateways traducen XMPP al protocolo de dicha red de mensajería externa y también la información de dicha red externa a XMPP. Estos protocolos no-XMPP pueden ser por ejemplo IRC (Internet Relay Chat RFC1459), SMS (Short Message Service), SIMPLE, SMTP, AIM, ICQ, MSN, Yahoo, etc.
Figura 3: Arquitectura XMPP – Nota: si bien en la figura vemos que el servicio de Gateway corre dentro de uno de los servidores donde se encuentra un servidor XMPP, el gateway puede encontrarse también en otro equipo
XMPP define el concepto de una entidad alcanzable en cualquier punto final de una red XMPP llamada JID (Jabber ID) la cual obtiene su nombre del protocolo original Jabber, está compuesto por un nodo, un dominio y un recurso, el uso típico es para representar usuarios o chatrooms:
jid = < nodo"@" dominio"/" recurso>
Ej: edemberg_gutierrez@xmpp-srv-01.fing.edu.uy/GAIM
chatroom_consultas_IO@dpto_IO.fing.edu.uy
XMPP se construye en base a 2 conceptos fundamentales: XML Streams y XML Stanzas (elementos XMPP). La idea bajo XML Streams es el que en vez de enviar documentos XML separados en una conexión, se crea una especie de conexión persistente entre dos entidades y por donde se envían elementos en forma de XML Stanzas, los streams son unidireccionales, en caso de que se requiera una conexión bidireccional se utiliza otro XML Stream.
Los XML Streams son comenzados por el tag <stream>, una vez que se establece el flujo, se esta listo para enviar las XML Stanzas, para cerrar el flujo se utiliza el tag </stream>
Un ejemplo de conversación unidireccional entre dos nodos A y B (cliente y servidor por ejemplo) sería :
1-A abre conexión TCP hacia B
2-A inicia el flujo XMPP con <stream>
3-A envía elementos XMPP por el flujo
4-A cierra flujo XMPP con </stream>
5-A cierra conexión TCP con B
Si se requiere una respuesta de B, se debe abrir un flujo de XMPP de B hacia a, se utiliza la misma conexión TCP.
En caso de problemas en los Streams se aplican las siguientes reglas:
Cualquier error a nivel de stream se considera como irrecuperable y cuando se es detectado un error la entidad que detecta dicho error es responsable de enviar un elemento <error></error> y luego inmediatamente </stream> y finalmente cerrar la conexión
Si el error sucede cuando se quiere establecer el flujo de deben enviar los siguientes tags : <stream> – <error></error> (el elemento error contiene puede contener un tag <text></text> que tenga la descripción del error) – <stream/> y luego finalizar la conexión TCP.
Luego que el flujo fuera comenzado empieza el intercambio de XML stanzas
XMPP : core predefine tres XML Stanzas:
message
presence
iq (info/query)
Todas las Stanzas comparten un conjunto de atributos comunes:
to:
especifica hacia que JID debe ir la Stanza
from:
especifica el JID del que envía la Stanza (si el cliente quiere utilizar un JID falso en el atributo from o el stream de dicho JID no ha sido autenticado aún, el servidor debe generar un error)
id:
atributo opcional que puede ser utilizado para el rastreo de XML Stanzas en un flujo dado
type:
especifica información detallada acerca del propósito de la Stanza
xml:lang:
atributo opcional que especifica el lenguaje por defecto del contenido en las Stanzas
Se describen a continuación las tres Stanzas:
Message Stanza: es utilizada para enviar mensajes de una entidad XMPP a otra, por ejemplo, un cliente XMPP utiliza una Message Stanza para enviar un mensaje instantáneo a otro cliente XMPP a través de uno o más servidores XMPP, el servidor coteja el atributo 'to' de la Stanza y rutea apropiadamente el elemento, en caso de no encontrar una ruta válida , el servidor debe enviar un mensaje de error al cliente que generó el mensaje.
Presence Stanza: se considera como una forma básica de broadcast desde una entidad a múltiples recipientes subscritos, generalmente el atributo 'to' no se utiliza, sin embargo si quien envía la Stanza especifica información en el campo 'to', el servidor debe entregar la Stanza de presencia solo al receptor especificado.
Info/Query Stanza: es una interacción en la cual una entidad pide información a otra entidad. El atributo 'type' juega un papel fundamental en una iq Stanza, ya que es utilizado para especificar la operación de la misma. Estas pueden ser: get, set, result o error.
El XMPP: Core especifica las funciones fundamentales del núcleo del protocolo XMPP como ser XML Streaming, seguridad en los canales, autenticación y las XML Stanzas generales pero no especifica el uso para alguna aplicación o tecnología, en particular para la mensajería instantánea, para ello existe la especificación XMPP: I.M. & P. la cual describe las extensiones de XMPP: Core para poder lograr servicios básicos de mensajería instantánea y manejo de presencia.
XML Stanzas para Mensajería Instantánea y Presencia
Anteriormente se presento la Message Stanza así como en la especificación XMPP: Core , en la especificación XMPP: I.M. & P. dicha Stanza es extendida para cubrir tipos y elementos específicos a la mensajería instantánea en si.
Básicamente se extienden los valores del atributo 'type' con las siguientes opciones: chat, groupchat, headline, normal o error. Los tipos de mensaje 'chat' son utilizados para conversaciones uno a uno, los 'groupchat' para conversaciones uno a muchos como chatrooms o IRC, 'headlines' son para hacer broadcast de mensajes como por ejemplo “mensaje del día” a todos los usuarios, el tipo de mensaje 'normal' son para mensajes que no entran en categoría de chat o groupchat y el tipo 'error' es utilizado cuando ocurre un error en algún intercambio de mensajes anterior.
Adicionalmente las I.M. Stanzas especifican un conjunto de elementos “hijos” para mensajería (subject, body y thread)
Ejemplo de I.M. Stanza:
<message
from='editorial@XMPP-servidor.com'
to='WilliamSh@XMPP-servidor-2.com'
type='chat'
xml:lang='es'>
<subject>Estimado Señor William</subject>
<body>He visto su trabajo, no está del todo mal. Hay tensión, fantasía, sentido dramático...¿es la primera vez que escribe? </body>
<body xml:lang='en'>I've seen your work, it isn't bad at all. There's tension, fantasy, a dramatic sense...this is the first time you write??</body>
</message>
<message
from='WilliamSh@XMPP-servidor-2.com'
to='editorial@XMPP-servidor-2.com'
type='chat'
xml:lang='en'>
<subject>Dear Editorial Manager</subject>
<body>No, I've written another tragedy, is the story of two lovers from Verona that...</body>
<body xml:lang='es'>No, he escrito otra tragedia, es la historia de dos amantes de Verona que...</body>
</message>
En el ejemplo anterior vemos como puede ser utilizada la internacionalización en la M.I., el mensaje puede tener varios tags <subject></subject> y <body></body>, cada uno con un lenguaje distinto.
Así como la I.M. Stanza, dentro de la extensión para M.I. la Stanza de presencia puede ser de los siguientes tipos: unavailable, suscribe, suscribed, unsuscribe, unsuscribed, proo error.
El tipo 'unavailable' significa que la entidad ya no esta disponible, utilizando una Stanza de presencia de tipo 'suscribe' se utiliza típicamente para agregarse como un contacto a un repositorio de otra entidad, si dicha entidad responde con una stanza de tipo 'suscribed' significa que la suscripción fue autorizada, si la Stanza es de tipo 'unsuscribed', la suscripción es denegada, si el tipo de la Stanza es 'unsuscribe' se utiliza típicamente para eliminar la presencia del repositorio de contactos de una entidad. El tipo 'probe' es utilizado para obtener la presencia actual de una entidad y el tipo 'error' es enviado si ocurre un error en el envío de stanzas de Presencia.
Una Stanza de Presencia también implementa los siguientes elementos:
show, status y priority. El primero especifica el estado de disponibilidad de la entidad, sus valores pueden ser : away (la entidad esta temporalmente no disponible), chat (entidad esta activa para entablar una conversación), dnd (no molestar “del inglés do not disturb”), xa (del inglés 'extended away' , significa que la entidad no estará disponible por un largo tiempo). Los valores de el elemento <show></show> no fueron creados para lectura humana, se manejan internamente entre las entidades , para ello puede utilizarse el elemento <status></status> . La prioridad puede utilizarse para manejo de prioridades de las Presence Stanzas.
Ejemplos:
Una entidad con JID “Sancho@La-Mancha.com” suscribe otra entidad con JID “Quijote@La-Mancha.com” la cual previamente envía el pedido de registro:
<presence to='Sancho@La-Mancha.com' type='suscribe'/>
Sancho ahora acepta el registro del Quijote
<presence to='Quijote@La-Mancha.com' type='suscribed/>
ejemplo de entidad que especifica su presencia como el de 'no molestar'
<presence xml:lang='es'>
<show>dnd</show>
<status>estoy en medio de un brete con el gerente</status>
<status xml:lang='latin'>habemus embarradum gerentae</status>
<priority>1</priority>
</presence>
Son utilizadas generalmente en M.I. para manejo de listas de contactos o para obtener información de presencia, para mantener privacidad sobre los usuarios u otras entidades, la información de presencia y disponibilidad puede ser restringida solo a entidades que el usuario ha autorizado.
Por medio de iq Stanzas un cliente puede obtener su lista de contactos del servidor
Ejemplo:
<iq from='el_pepeMu@xmpp-uruguay.com' type='get' id='roster1'>
<query xmlns='jabber:iq:roster'/>
</iq>
el servidor responde
<iq to='el_pepe@xmpp-uruguay.com' type='result' id='roster1'>
<query xmlns='jabber:iq:roster'>
<item jid='el_ñato@xmpp-uruguay.com/GAIM'
name='Eleuterio'
subscription='both'>
<group>compañeros</group>
</item>
<item jid='el_horno@chatrooms.xmpp-uruguay.com'
name='El Horno del XMPP'
subscriptio='from'>
<group>ChatRooms</group>
</item>
</query>
</iq>
El grupo de trabajo de IMPP en la IETF especificó un framework interoperable en forma abstracta para M.I. llamado Common Presence and Instant Messaging (CPIM). Para lograr interoperabilidad entre distintas especificaciones de mensajería instantánea, cada una de dichas especificaciones debe definir un sistema de mapeo entre si misma y CPIM.
CPIM esta basado en la definición de mensajes mediante dos tipos de contenido MIME : “Message/CPIM” y “aplication/pidf+xml”.
La especificación del RFC3922 especifica como las XML Stanzas son mapeadas en los tipos MIME de CPIM , el mapeo es bidireccional.
Para no entrar en detalle de los algoritmos y las reglas de mapeo entre los dos protocolos se presenta a continuación como ejemplo el mapeo de un mensaje sencillo, para poder tener una idea más clara:
XMPP XML Stanza:
from='daniel@tortuga.fing.edu.uy'
to='mario@tortuga.fing.edu.uy'>
<body>Hola, que tal ??</subjec>
CPIM MIME
Content-type: text/plain; charset=utf-8
Content-ID: <xyz@tortuga.fing.edu.uy>
From: daniel <im:daniel@tortuga.fing.edu.uy>
To: mario <im:mario@tortuga.fing.edu.uy>
Subject: Hola
Hola, que tal ??
El RFC3923 define como las XML Stanzas pueden ser firmadas digitalmente y encriptadas. La idea esta basada en el mapeo XMPP-CPIM descrito anteriormente. Tampoco entraremos en detalle acerca del esquema de encripción del RFC, pero nuevamente, para tener idea del funcionamiento, el procedimiento para firma y encriptación consiste en:
1-Generar un objeto CPIM MIME de la XML Stanza
2-Encriptar y/o firmar el contenido y los cabezales del objeto CPIM generado
3-Poner el objeto encriptado resultante dentro en un elemento <e2e></e2e> dentro de un Message Stanza para enviar.
Los protocolos SASL y TSL son fundamentales en XMPP para autenticación y utilización de canales seguros, respectivamente.
La especificación de XMPP recomienda que tanto en comunicaciones cliente-servidor como en servidor-servidor, se debe utilizar TLS para la fase de negociación en el momento de establecer una conexión. Dicha negociación es previa a la autenticación de la entidad, que debe hacerse utilizando SASL.
El procedimiento general de una negociación TLS/SASL exitosa se describe a continuación:
1- el cliente abre una conexión TCP con el servidor y comienza un XML Stream
2- el servidor envía una extensión STARTLS al cliente y describe los mecanismos de autenticación que soporta
3- el cliente responde con STARTLS
4- el servidor informa al cliente que puede proceder
5- el cliente y el servidor establecen el canal seguro utilizando TLS sobre la conexión TCP
6- si el paso anterior fue exitoso. El cliente inicia un nuevo XML Stream con el servidor
7- el servidor responde con otro stream enviando los mecanismos de autenticación (como en el paso 2)
8- el cliente selecciona el mecanismo de autenticación adecuado
9- el servidor envía un desafío codificado [Base64] al cliente
10- el cliente responde el desafío también de forma codificada [Base64] (le provee las credenciales adecuadas al servidor)
11- en caso de éxito, el servidor envía otro desafío codificado[Base64] (le envía un “ticket o certificado de sesión”)
12- el cliente responde el desafío
13- en caso de éxito, el servidor informa al cliente que la autenticación de realizó de forma exitosa
14- el cliente comienza un XML Stream hacia el servidor para comenzar a enviar las XML Stanzas específicas de la aplicación.
Si bien Jabber se podría ver como el padre de XMPP (o XMPP versión 0.9), y existen una gran cantidad de implementaciones de servidores basados en Jabber, la IETF explica detalladamente las diferencias fundamentales entre XMPP y Jabber en el RFC3920 ya que la idea es que los desarrolladores tengan en cuanta dichas diferencias y sea más fácil lograr el soporte de XMPP 1.0 en nuevas versiones de los servidores y clientes, a nivel de XMPP: Core las diferencias son siete y a nivel de XMPP: M.I. & P., las diferencias son dos.
1- Encripción de canales
En Jabber, es muy común la utilización de canales encriptados mediante SSL en los puertos 5223 y 5270, en XMPP la encriptación de canales se realiza mediante TLS sobre puertos registrados por IANA (Internet Assigned Numbers Authority) como “xmpp-client” y “xmpp-server” la especificación recomienda que sean los puertos 5222 y 5269 (contrariamente, dichos puertos en la implementación de Jabber original son los puertos para conexiones no-seguras).
2- Autenticación
La autenticación cliente-servidor en Jabber se realiza mediante una iq Stanza, y no implementa una autenticación para conexiones servidor-servidor. XMPP define la utilización de SASL en la autenticación de ambos.
3- Manejo de Errores
En Jabber, los errores referentes a XML Stream son manejados de manera muy simple enviando un texto dentro de un tag <stream:error></stream>. XMPP define un manejo de errores mejor desarrollado y extensible con sub-elementos dentro de un elemento <error></error>.
En Jabber los errores relacionados con las Stanzas son manejados códigos de error en un estilo HTTP. XMPP implementa un mecanismo más elegante y completo a través de Stanzas de error.
4- Internacionalización
XMPP utiliza el atributo “xml:lang” para soporte multi-lenguaje.
Las otras 3 diferencias tratan sobre la forma de asignación de recursos, proceso de JID's y el atributo 'Versión' de un stream XML (esto es para saber las características del XML Stream según la versión).
1- Forma de establecer una sesión
El protocolo de autenticación cliente-servidor desarrollado en la comunidad Jabber, asume que cada cliente es un cliente de M.I. y por tanto inicia una sesión de mensajería instantánea per sei. XMPP mantiene una separación estricta entre las funcionalidades del núcleo y las de las extensiones para M.I. y P, entonces una sesión de M.I. no es creada hasta que el cliente especifique que ese será el cometido de la sesión.
2- Listas Privadas
Si bien la comunidad Jabber comenzó a trabajar en un mecanismo para bloqueo de comunicaciones (llamadas listas privadas) en el 2001, una vez formado el grupo para XMPP, la comunidad Jabber decidió esperar a la implementación de este grupo de la IETF.
Estudio del Open/Free (GNU/Linux) como plataforma de servicios de red en entornos empresariales
Daniel Caraballo - Mario Madera - Marcelo Odin
Tutor: Ariel Sabiguero Yawelak
2004 - 2005.