LIBRO DE TEXTO ACOMPAÑANTE DE LAS PRÁCTICAS LECTORAS

Chapter 3 and resource identifiers, as well as an updated protocol for end-to-end object encryption. A meeting of the XMPP Working Group was held on March 17, 2003, where a draft for using Session Description Protocol (SDP) over XMPP was also published. The SDP provides a mechanism for describing multimedia sessions, which are advertised and negotiated over the Internet. This document described how to use SDP to build a frame- work for media stream/session initiation and negotiation between Jabber entities. In particular, SDP [2] over XMPP [3] is used to provide a semantic framwork for signaling call setup (similar to the semantics provided by the Session Initiation Protocol [SIP] as defined in RFC 3261 [4]). The resulting mechanism was called the “Transport for Initiating and Negotiating Sessions,” or TINS.

In 2004, the IESG approved XMPP core and XMPP IM specifications as proposed standards on January 29 and February 5, respectively. The XMPP-CPIM Mapping specification was approved on May 19, 2004, and it was approved on July 26, 2004. In October 2004, these documents were published as the following RFCs:

RFC 3920: Extensible Messaging and Presence Protocol (XMPP):

Core

RFC 3921: Extensible Messaging and Presence Protocol (XMPP):

Instant Messaging and Presence

RFC 3922: Mapping the Extensible Messaging and Presence Protocol

(XMPP) to Common Presence and Instant Messaging (CPIM)

RFC 3923: End-to-End Signing and Object Encryption for the Exten-

sible Messaging and Presence Protocol (XMPP)

Upon publication of the XMPP RFCs, the IETF announced the conclu- sion of the XMPP Working Group. However, the XMPP WG mailing list remains active, and development of further XMPP extensions is being pur- sued through the Jabber Enhancement Proposals (a.k.a., JEP Series) pro- duced by the Jabber Software Foundation.

RFC 3920

RFC 3920 [5] defines the core features of XMPP, a protocol for streaming Extensible Markup Language (XML) elements in order to exchange struc- tured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging

56 3.1 Extensible Messaging and Presence Protocol—RFC 2778

XML data, it is used mainly to build IM and presence applications that meet the requirements of RFC 2779. XMPP is an open XML protocol for near-real-time messaging, presence, and request-response services. The basic syntax and semantics were developed originally within the Jabber open- source community, mainly in 1999. In 2002, the XMPP WG was chartered with developing an adaptation of the Jabber protocol that would be suitable as an IETF IM and presence technology. As a result of work by the XMPP WG, the current memo defines the core features of XMPP 1.0; the exten- sions required to provide the IM and presence functionality as defined in RFC 2779 are specified in the XMPP: IM and presence document.

RFC 3921

RFC 3921 [6] describes extensions to and applications of the core features of the XMPP that provide the basic IM and presence functionality as defined in RFC 2779. XMPP is a protocol for streaming XML elements in order to exchange messages and presence information in close to real time. The core features of XMPP are defined in XMPP: Core. These features— mainly XML streams, use of TLS and SASL, and the <message/>, <pres- ence/>, and <iq/> children of the stream root—provide the building blocks for many types of near-real-time applications, which may be layered on top of the core by sending application-specific data qualified by particular XML namespaces. This memo describes extensions to and applications of the core features of XMPP that provide the basic functionality expected of an IM and presence application as defined in RFC 2779.

RFC 3922

RFC 3922 [7] describes a mapping between the XMPP and the Common Presence and Instant Messaging (CPIM) specifications. The IM and Pres- ence Protocol (IMPP) Working Group has defined an abstract framework for interoperability among IM and presence systems that are compliant with various other XMPP protocols. This framework is commonly called Common Presence and IM, or CPIM. The CPIM family of specifications

includes a Common Profile for IM (also called CPIM), a Common Profile

for Presence (CPP), a CPIM Message Format, and a Common Presence Information Data Format [8].

RFC 3922 describes how the XMPP-CORE and XMPP-IM map to the abstract model contained in the CPIM specifications. This is used mainly for establishing gateways between XMPP services and non-XMPP services that conform to IMP-REQS. Such a gateway, referred to herein as an “XMPP-CPIM gateway,” may be established to interpret the protocols of

3.1 Extensible Messaging and Presence Protocol—RFC 2778 57

Chapter 3 one service and translate them into the protocols of the other service. We can visualize this relationship as illustrated in Figure 3.1.

RFC 3922 defines a mapping for use by a gateway that translates between XMPP and a non-XMPP protocol via the CPIM specifications. Such a gateway is not an intermediate hop on a network of non-XMPP servers (whose native formats may or may not be defined by the CPIM specifications), but a dedicated translator between XMPP and a non-XMPP protocol, where the CPIM specifications define the common formats into which the protocols are translated for purposes of interworking. The map- ping defined in RFC 3922 applies to instant messages and presence infor- mation that are not encrypted or signed for end-to-end security. For information about secure communications to or from an XMPP service through an XMPP-CPIM gateway, refer to the XMPP-E2E proposal. This document defines a method for end-to-end object signing and encryption in the XMPP.

RFC 3923

RFC 3923 [9] defines methods of end-to-end signing and object encryp- tion for the XMPP. The method specified herein enables a sender to sign and/or encrypt an instant message sent to a specific recipient, sign and/or encrypt presence information that is directed to a specific user, and sign and/or encrypt any arbitrary XMPP stanza directed to a specific user. This memo thereby helps the XMPP specifications meet the requirements speci- fied in the IMP-REQS.

3.1.1

Jabber and the IM Community

The noun Jabber is attached to many things in the IM world. Not only does

it represent This is Jabber, Inc., the commercial software company based in

Denver, Colorado, but it also represents other areas related to both IM and Jabber Inc. Jabber, Inc. delivers a presence, messaging, and XML routing infrastructure for powering real-time applications, systems, and services. This infrastructure includes enterprise IM (EIM), conversational trading systems, and presence-enabled customer service applications. As a sponsor Figure 3.1

XMPP-CPIM service.

58 3.2 Jabber Protocol and XMPP

of the Jabber Software Foundation, Jabber, Inc. also embraces the spirit of freedom that drives the worldwide open-source community.

Jabber is based upon XMPP, an open, XML-based protocol for IM and other presence-powered applications. XMPP is the only Internet Engineer- ing Task Force (IETF)–approved protocol for real-time messaging and pres- ence. The Jabber community is a growing, global body of developers that create Jabber-based solutions. Finally, there is the Jabber Software Founda- tion (JSF), which is a not-for-profit membership organization that manages the Jabber protocol and is also known as jabber.org [10]. Figure 3.2 illus- trates this relationship among entities working with the Jabber protocol.

3.2

Jabber Protocol and XMPP

The term Jabber is widely used to refer to a set of open protocols for stream- ing XML elements between any two points on a network and to the tech- nologies built using those protocols [11]. The architecture of Jabber IM systems is similar to that of the most time-tested messaging system on the planet: e-mail. While there are some key differences, if you think of Jabber as “instant e-mail,” you would not be making a bad assumption.

So how does it really work? To understand how, let’s first look at a quick example of how John and Lois might use Jabber in the workplace. Lois doesn’t send a message directly (peer to peer) to John, at least not in the Jab- Figure 3.2

Illustration of the Jabber world.