PLAN DE ACCIÓN O MEJORAMIENTO

Chapter 3 component features that enable server administrators to supplement the core services with additional services, such as gateways to other messaging systems. Such components can introduce greater complexity into a Jabber deployment without sacrificing the simplicity of the core server. Further- more, Jabber does not require such external components to be added or implemented by the core server team.

Flexibility is always a key consideration in the Jabber community. One of the design criteria for Jabber IM systems was that it must be easy to write a client, and the Jabber architecture imposes very few restrictions on clients.

The only things a Jabber client must do are communicate with the Jabber

server over TCP sockets, parse and interpret well-formed XML stanzas over an XML stream, and understand the core Jabber data types. The preference in Jabber is to move complexity from clients to the server. This makes it rel- atively easy to write clients and update them without forcing users to down- load new clients. Many low-level functions of the client are handled by Jabber client libraries. These libraries allow developers to focus on the user interface and let the libraries or server core handle the details that go on behind the screen. Jabber protocols and technologies provide an open alter- native to proprietary services offered by legacy IM vendors. Jabber enables developers to create robust, near-real-time messaging and presence solu- tions for IM.

3.3

Instant Messaging/Presence Protocol—RFC 2779

Presence and IM have recently emerged as a new medium of communica- tions over the Internet. In Chapter 2, we explained that presence is a means for finding, retrieving, and subscribing to changes in the presence informa- tion (e.g., online or offline) of other users. We also described IM as a means for sending small, simple messages that are delivered immediately to online users. Applications of presence and IM currently use independent, non- standard, and noninteroperable proprietary protocols developed by the multitude of IM vendors. The goal of the IETF’s IM and Presence Protocol Working Group (IMPPWG) is to define a standard protocol so that inde- pendently developed IM and/or presence applications can interoperate across the Internet [12]. This working group will eventually define the pro- tocols and data formats necessary to build a cohesive Internet-scale messag- ing system capable of end-user presence awareness/notification, IM, user authentication, message integrity, encryption, and access control. RFC 2779[13] defines a minimal set of requirements that IMPP must meet.

66 3.4 Session Initiation Protocol

The IMPPWG is the standards committee driving the IM world. IMPPWG chief contributors include the likes of AOL, Microsoft, and so on. Much confusion surrounds the efforts to standardize on an IM proto- col. Different IM communities have appeared and, other than some work to make AOL and Microsoft interoperate with ICQ, little progress had been made until recently. IMPPWG has now established requirements for a standard protocol and defined a Common Profile for IM (CPIM) that sets out an architecture (Figure 3.1) and discusses server-to-server interoperabil- ity in a multiprotocol environment. SIP is one of three proposed protocols in the IETF’s IMPPWG—the others are PRIM and APEX (formerly IMXP). SIP is explained in the next section. PRIM and APEX are both designed specifically for the needs of IM, whereas SIP would require some extensions to fulfill the requirements of the IMPPWG. PRIM takes the stance that a standard protocol should be based on existing proprietary architectures for IM. APEX does IM and presence on top of a Blocks Extensible Exchange Protocol (BEEP), which is an XML protocol.

Due to the obvious need for presence to be used in voice communica- tions, SIP is a strong contender as the mechanism by which users and appli- cations communicate their presence data to and from the network. The PRIM group has acknowledged this and allows the possibility of interfacing with SIP for voice applications. The strongest argument for SIP is probably that of convergence, while other initiatives would require an IM-specific infrastructure. SIP, of course, can also be used for many other purposes. Sig- nificant in this respect is the decision by Microsoft to adopt SIP for real- time communications on the .NET framework. The CPIM document shows there is some consensus being reached on this matter. A likely out- come, however, is that each of the groups will pursue their own protocol but will support some sort of base-level interoperability.

3.4

Session Initiation Protocol

The Session Initiation Protocol [14] (SIP) is a fundamental building block that service providers can use to harness the power of the Internet Protocol and transform their traditional revenue streams. The world of networking is undergoing a sea of change: Fixed and mobile networks are converging; computing and communications are becoming inseparable. The ubiquity of IP is transforming the data infrastructure into an all-encompassing commu- nications capability that overshadows the telephone network. At the center of this evolution is SIP: It is the mechanism that unites services across plat- forms, thus creating a multiplicity of new possibilities.