I CHATTERJEE LAYOUT
`
`4 / 20 / 05 4:38 PM Page 2
`
`+
`
`Instant Messaging and Presence
`Technologies for College Campuses
`
`Samir Chatterjee, Tarun Abhichandani, Haiqing Li, and Ben isu Tulu
`Claremont Graduate University
`Jongbok Byun, Point Loma Nazarene University
`
`Abstract
`Instant messaging is an application that enables networked users to send and
`receive short messages. Presence provides information about users' reachability
`and willingness to accept/reject a brief chat session . Various proprietary IM and
`presence (IM&P) solutions are currently on the market, and standards are emerg(cid:173)
`ing . There are interoperability problems between the two dominant standards (SIM(cid:173)
`PLE and XMPP); as a result, this important application is finding difficulty in
`widespread deployment within college campuses and businesses. We describe a
`brief history of the development of IM&P technology, discuss the current standard(cid:173)
`ization work being done within IETF, and present an overall architecture of emerg(cid:173)
`ing standards . We provide a comparison between the SIP/SIMPLE and
`Jabber/XMPP standards. We also present data and its analysis from a survey of
`campus organizations that sheds light into the main issues of deploying, managing
`and provisioning of IM&P services on college campus.
`
`nstant messaging (IM) is an application that enables
`short message exchanges between online users. It enables
`these exchanges in real time independent of locale fl1
`This feature of real-time differentiates IM from email
`systems. IM systems, with the ability of providing presence
`information, enables a user to know the availability of other
`users. By using presence information, an IM system enables us
`to search for a specific user, check the user's status, and send
`short messages. Popular IM applications include AOL=
`Instant Messenger (AIM), ICQ '" ("I Seek You"), MSN'" or
`WindowsXP'" Messenger, and Yahoo'" Messenger [2].
`Instant messaging, by making us able to know the availabili(cid:173)
`ty of our peers, provides us with improved communication
`compared to other technologies. We can send an email mes(cid:173)
`sage at any time and get a reply at the recipient's conve(cid:173)
`nience. But there are times when we may need an instant
`response from one of a group of users. It takes a while just to
`find one of the users in that group, who might be available or
`not. In IM applications, if we have that group of users on our
`"buddy list," we can tell at a glance if any of them are logged
`onto the network, and whether they have been active recently.
`We are also aware, in this case, whether or not the user is
`open to communicating at this time. If they are, we can send a
`quick IM and communicate further. Although IM started as a
`consumer-grade technology, it was quickly adopted by many
`businesses that saw its advantages in enabling quick communi(cid:173)
`cations and providing presence information [3]. This new phe(cid:173)
`nomenon is now impacting schools and college campuses.
`However, this emerging phenomenon and its potential value
`as a campus technology is not well understood. How can high(cid:173)
`er education and campuses develop strategies and policies to
`deploy, manage, and support IM programs?
`At this time, a large number of IM systems exist in various
`
`Internet communities, illustrated in Table 1. Every system, in
`Table 1, has unique features and separate user communities.
`After AOL rolled out their service, Yahoo and MSN intro(cid:173)
`duced their own products that enabled users to communicate
`with AIM servers. However, AOL soon managed to shut them
`out, and the result for the past several years has been a plural(cid:173)
`ity of competing products that cannot interoperate with each
`other [3]. Similarly, in standard organizations like the Internet
`Engineering Task Force (IETF) there have been alternative
`standards that present a hindrance to interoperability and
`homogeneity.
`The goals of this article are threefold. First, we want to
`clearly explain how this technology works especially with
`respect to the emerging standards. There are several Internet(cid:173)
`drafts (I-Ds) and requests for comments (RFCs), which is
`overwhelming for anyone not part of the standards activities.
`We discuss the state of standardization work done to date
`within IETF and compare the two alternative protocols. How(cid:173)
`ever, it is important to also note that as yet no definitive stan(cid:173)
`dard has emerged across the industry. Second, we identify
`motivations for IM and presence (IM&P1) usage, survey the
`higher education community regarding the use of IM&P, and
`present preliminary results of the data analysis. Third, we dis(cid:173)
`cuss implications for using IM&P technology and services
`based on our preliminary data interpretation. This could be
`very helpful to information technology (IT) managers as well
`as researchers who wish to implement IM&P on their campus
`or create new IM&P systems.
`The rest of the article is structured as follows . We start
`
`1 This acronym has been adopted from
`http://www.ietf.org/html.charters/simple-charter.html
`
`2
`
`0890-8044/05/$20.00 © 2005 IEEE
`
`IEEE Network • May/June 2005
`
`$
`
`+
`
`

`

`I CHATTERJEE LAYOUT
`
`4 / 20 / 05 4: 38 PM Page 3
`
`+
`
`IM solutions
`
`Characteristics
`
`Vendor examples
`
`Public services
`
`Available to anybody; often free; use a central-
`ized third-party server to relay messages
`
`AOL Instant Messenger'", MSN Messenger'", Yahoo!
`Messenger'"
`
`Private services
`
`IM systems designed for enterprise and corpo-
`rate use; secure IM, message logging, enterprise-
`class service, corporate control
`
`AOL Enterprise AIM'" , Yahoo Messenger Enterprise™,
`Microsoft Messenger Connect for Enterprise••, IBM
`Lotus Sametime'"
`
`Collaboration tools
`
`These collaborative systems include presence
`technology
`
`IBM Lotus Sametime™, Groove Network Inc's Groove
`Workspace'", Microsoft's Window Server 2003'"
`
`Carrier/network services
`
`Convergence products that are now IM&P-
`enabled
`
`Bantu Inc, Comverse Inc,. DynamicSoft Inc., FaceTime
`Communications, lnvertix Corp., NotePage Inc., Pres-
`enceWorks Inc., Vayusphere Inc.
`
`Open source tools
`
`Based on open source XMPP standard
`
`Jabber Inc., Jabber.Org
`
`■ Tobie 1 . Instant messaging systems.
`
`I
`
`with a brief history followed by a generic model and architec(cid:173)
`ture of IM&P. We also explain the two emerging standards
`(SIMPLE and XMPP) and compare them. We then discuss
`motivations of implementing IM&P within campuses. We pre(cid:173)
`sent results of our initial survey. We discuss implications for
`practitioners and researchers. Finally, we conclude this article.
`Presence and Instant Messaging Services
`A Brief History2
`The early usage of IM&P started with the introduction of the
`UNIX operating system. Users were able to get the limited
`presence information and send instant messages using "FIN(cid:173)
`GER" and "TALK" commands respectively in the UNIX
`environment. The presence information was limited to the last
`time a user accessed the account and the location. The instant
`messaging capabilities were limited to plain text messaging. In
`UNIX systems, users were able to manage the information
`they wished to share as response to a "FINGER" query. They
`also had the control over accepting or rejecting a talk request
`[4].
`Internet relay chat (IRC) was introduced to the online
`community in 1988 in order to provide real time, conversa(cid:173)
`tional capability among users who were connected to a public
`network anywhere in the world [5]. IRC offered an environ(cid:173)
`ment where multiple users can join and leave a chat room at
`anytime. It also eliminated the basic restriction of being on
`the same network to chat while still offering the means to ini(cid:173)
`tiate a private communication between two users.
`ICQ ("I Seek You") beta version was released in Novem(cid:173)
`ber 1996 by Mirabilis. ICQ utilized peer-to-peer communica(cid:173)
`tion clients and enabled users to chat simultaneously over the
`Internet without joining a chat room. By January 1997, ICQ
`had 27,000 users with a growth rate of 100 percent per week.
`Meanwhile, America Online's (AOL) Instant Messenger
`(AIM) increased its subscribers to ten million users. In mid
`1998, America Online (AOL) acquired ICQ, which had
`achieved more than ten million users by that time. Microsoft
`MSN Messenger and Yahoo Messenger were both released
`within a year after that acquisition. With the introduction of
`AIM, ICQ, Yahoo! Messenger, and MSN Messenger IM
`became a field where large corporations were developing pro(cid:173)
`prietary code, which were not interoperable. In 1998, Jabber
`
`2 Peter Saint Andre of Jabber provided an interesting thread to this on the
`Internet 2 Working Group Integrated Infrastructure for Instant Messaging
`(I2!M) mailing list.
`
`project was initiated to build an IM client and server that
`could interact with the various proprietary systems by using a
`superset of all of the major consumer IM systems [6]. As with
`any other open source software (OSS), Jabber was born as a
`result of a programmer, Jeremy Miller, scratching a personal
`itch of a programmer.
`To overcome the lack of interoperability and other con(cid:173)
`cerns in im, such as security, authentication, scalability and
`integration with other business applications, IETF formed two
`working groups focusing on instant messaging and presence at
`different points in time. Following sections will examine the
`generic model as well as the standards prescribed by the SIP
`for IM&P Leveraging Extensions (SIMPLE) and Extensible
`Messaging and Presence Protocol (XMPP) working groups.
`There is another emerging IM&P standard known as the
`wireless village initiative. Ericsson, Motorola, and Nokia have
`recognized the need for an industry standard for mobile
`IM&P services (IMPS). The wireless village service has four
`components: presence, IM, groups, and shared content. We
`do not discuss this initiative in detail here but instead point
`the reader to [7] for further information.
`Generic Model for Presence and Instant Messaging
`In an effort to develop a standard architecture for IM&P
`applications, the IETF IM&P Protocol (IMPP) Working
`Group proposed a generic model for providing a common
`vocabulary for future work Ifil. Figure 1 illustrates the generic
`model and the proposed entities.
`A presence service accepts, stores, and distributes presence
`information. It communicates through two distinct clients: pre(cid:173)
`sentities and watchers. Presentities provide presence informa(cid:173)
`tion to be stored and distributed, whereas watchers receive
`presence information from the service. Watchers can be fetch(cid:173)
`ers or subscribers. Fetchers pull the value of presence informa(cid:173)
`tion for a specific presentity from the presence service. If a
`fetcher is fetching information on a regular basis, it is called a
`poller. Subscribers, on the other hand, subscribe to presentity
`information on the presence service. The presence service
`transmits information to the subscriber via notifications when
`a change occurs in the presence information of the subscribed
`presentity.
`Presence information is composed of one or more presence
`tuples . Each presence tuple consists of one mandatory ele(cid:173)
`ment, Status, and two optional elements, Communication
`Address and Other Presence Markup . The Status field is
`defined to have at least two states: open and closed. In the
`former state, !Ms will be accepted, and in the latter state they
`will not. Other possible values for Status may be busy, away,
`
`IEEE Network • May/June 2005
`
`3
`
`$
`
`+
`
`

`

`I CHATTERJEE LAYOUT
`
`4 / 20 / 05 4:38 PM Page 4
`
`~-
`
`Principal
`(user)
`
`Presence
`user agent
`
`Presentity
`
`Watcher
`user agent
`
`Sender
`
`Sender
`user agent
`
`lnbox
`user agent
`
`Instant
`inbox
`
`Instant messaging and presence client
`
`Presence
`information
`
`Notification
`
`IM
`
`IM
`
`.--,
`,.., ,
`:~:
`'
`'
`:@ :
`,.,,,
`:a:
`,--+:
`·-~~
`,n '
`,O'
`•=·
`,::,,
`'"''
`: S-:
`,::,,
`•3:
`:m:
`•o,,
`:~.:
`,::,,
`:(0:
`:s:
`:g:
`
`·-~J
`
`Presence
`service
`
`Instant
`message
`service
`
`■ Figure 1 . A generic model for presence and instant messaging.
`
`+
`
`do not disturb, and so on ( these statuses are further extended
`in SIMPLE and XMPP). The Communication Address ele(cid:173)
`ment is composed of Communication Means and Contact
`Address fields, enabling a user to utilize various types of com(cid:173)
`munication means. The presence information adheres to a
`standard prescribed by IETF, "Presence Information Data
`Format (PIDF)" [9].
`The IM service is responsible for accepting and delivering
`IMs to other entities (Fig. 1). It communicates through two
`distinct clients, senders and instant inboxes. The sender is
`responsible for sending IMs to the IM service, which is
`responsible for delivering them to the instant inbox with the
`corresponding instant inbox address.
`Understanding SIMPLE and XMPP Open Standards
`Within IETF, IMPP was the first working group formed to
`define protocols and data formats so that disparate applica(cid:173)
`tions can interoperate across the Internet. In addition, there
`were various standards that provided alternative solutions for
`IM&P - SIMPLE, Presence and Instant Messaging (PRIM),
`
`and Application Exchange (APEX). Working groups for these
`alternative standards follow different principles for imple(cid:173)
`menting IM&P services. SIMPLE builds on the SIP infras(cid:173)
`tructures, APEX implements the service as store-and forward
`or email, and PRIM builds protocols over TCP. XMPP came
`to the IETF quite late (July 2002). The main reason for creat(cid:173)
`ing an XMPP WG was that it was open source and had a big
`community of developers. Due to commonality of platform
`(XML), APEX can be considered as a first incarnation of
`XMPP in some sense. Subsequent content in this section
`examines the standards prescribed by the SIMPLE and XMPP
`working groups.
`Baseline SIP llQl provides mechanisms for session-oriented
`communication but not for presence and IMs. The SIMPLE
`working group (henceforth referred to as SIMPLE) has been
`chartered to provide extensions for SIP that can be used for
`implementing IM&P services. The standards prescribed by
`SIMPLE use SIP as a signaling protocol and describe the
`usage of SIP for subscription and notifications for presence. It
`supports various models for IM&P applications [3, 11] and
`
`+
`
`Presence subsystem
`
`l""'_t----,~
`__J
`ll.__ __ (p_r_oxy._fr_e_gi_st_r_ar~)-----'I
`
`Presence agent (PA)
`
`Upload presence
`• Collocation
`• Register method
`•Update documents
`
`~ Presence user agent
`
`(PUA)
`.__________.
`
`Noti
`
`I
`
`Subscribe
`
`= . . .!.. ............ ~~~~·~·~·~·············L ······································· .
`
`Instant messaging subsystem
`~---I_M ___ ~---------------1~.i~I ____ I_M ____ ~
`-
`Message/open session
`-
`
`■ Figure 2. SIMPLE components.
`
`4
`
`IEEE Network • May/June 2005
`
`$
`
`

`

`I CHATTERJEE LAYOUT
`
`4 / 20 / 05 4: 38 PM Page 5
`
`+
`
`Jabber
`server 2
`
`Jabber
`server 3
`
`SIP server
`
`Server-to-server
`
`Jabber server 1
`
`Router
`
`Foreign IM
`gateway
`(Jabber to SIP)
`
`SIMPLE
`client
`
`SIMPLE
`client
`
`Client-to-server
`
`Resolver
`
`Session
`manager
`
`Jabber
`client
`
`Jabber
`client
`
`■ Figure 3. Jabber architecture.
`
`adheres to standards such as Common Profile for Instant
`Messaging (CPIM) [12], Common Profile for Presence (CPP)
`[13], and PIDF [9]. By introducing SIP extensions, MES(cid:173)
`SAGE, SUBSCRIBE, and NOTIFY methods [11], SIP can
`deliver presence information and IMs. Interaction of different
`components for SIMPLE is illustrated in Fig. 2.
`A presence user agent (PUA) provides presence informa(cid:173)
`tion for a presentity. There can be multiple PU As for a pre(cid:173)
`sentity, using many devices lli] . A presence agent (PA)
`responds to SUBSCRIBE requests received and generates
`notifications for presence state of a presentity. Watchers, as
`explained before, are parties interested in knowing presence
`information of other presentities. Each of these SIMPLE
`components registers with the SIMPLE provider to send and
`receive messages. According to Fig. 2, the PUA uploads the
`presence information to the PA. Presence information can be
`exchanged in three ways L!i]: collocating PA with PUA, using
`the REGISTER method of SIP, or updating documents for
`presence. When users add contacts to their list, they subscribe
`to these contacts' presence information. In this case, a watch(cid:173)
`er sends a SUBSCRIBE request to a PA. Once the subscrip(cid:173)
`tion has been made, any change to the contact's presence
`information is conveyed to the user who added the contact.
`This is done by transferring a NOTIFY message using SIP
`from PA to watcher [15]. A user can send a MESSAGE to a
`user in the contact list once he/she finds him/her online. In
`SIMPLE, the network packet with message Hello! sent from
`Alice@foobar.com to Bob@foobar.com is represented in Box
`1.
`
`The network packet was captured on the source machine
`- here, for example, on Alice's machine using Ethereal Net(cid:173)
`work Protocol Analyzer available at http://www.ethereal.com.
`The packet is not an exact illustration of all the details. It just
`gives an overview of how the information is stored and trans(cid:173)
`ferred on the network.
`However, there is no facility for offline messaging in SIP.
`Since SIP UAs exchange IMs directly without the help of a
`SIP server, SIMPLE could provide scalability for IM services.
`However, it is difficult to monitor the message exchanges and
`apply security policies to protect the transmission of confiden(cid:173)
`tial information.
`Prior to IETF's initiation of solving issues such as interop(cid:173)
`erability, Jabber came into existence [16]. Jabber technology is
`
`an IM system focused on privacy, security, ease of use, access
`from anywhere using any device, and Web-based services. It
`uses XML, a universal format for structured documents and
`data on the Web. Jabber, through its architecture (Fig. 3),
`uses a distributed network utilizing many interconnected
`servers. Jabber technologies offer several key advantages such
`as open standards, decentralized architecture, a secured
`infrastructure, and extensibility of application, flexibility, and
`diverse services.
`XMPP, a core protocol for Jabber IM&P technology, is an
`XML-based protocol for exchanging IM&P information in
`real time. Most XMPP-based IM&P applications are imple(cid:173)
`mented via a client-server architecture that requires a client to
`establish a session on a server in order to engage in the
`expected IM&P activities ll1]. The architecture, presented in
`Fig. 3, depicts three different components in a cohesive net(cid:173)
`work of IM&P: Jabber servers, Jabber clients, and non-Jabber
`servers. Furthermore, the illustration details an internal work(cid:173)
`ing of a Jabber server labeled Jabber server 1. The router is
`the central component in a Jabber server. All the components
`communicate with the router to resolve the paths to be adopt(cid:173)
`ed for exchange of XML streams.
`A Jabber infrastructure includes three entities: Jabber
`clients, Jabber servers, and a gateway that translates between
`Jabber and other protocols, like SIP, used on a non-Jabber
`messaging network. Clients connect to a server over TCP and
`use XMPP that contains XML streams to access services
`offered by a server. A Jabber server, apart from storing
`clients' information and their contact list, routes XML streams
`between authorized clients, servers, and other entities ll1]. In
`Jabber architecture, features such as streams, stream authenti(cid:173)
`cation, and encryption provide building blocks for many types
`of near-real-time applications ill]. XML streams, between
`two entities ( clients or servers), involve creating a persistent
`connection for exchanging XML data elements or XML stan(cid:173)
`zas. An XML stanza, as defined in ill] , is an unambiguous
`unit of structured information that has a start ( e.g., <conver(cid:173)
`sation>) and an end (e.g., <conversation/>). There are three
`predefined XML stanzas in XMPP: message, used for
`exchanging instant messages between clients through one or
`more servers; presence, used for notifying clients about the
`status of a client; and iq (Info/Query), used for request(cid:173)
`response interaction between entities. All of these stanzas
`
`IEEE Network • May/June 2005
`
`5
`
`$
`
`+
`
`

`

`I CHATTERJEE LAYOUT 4/20/05 4: 38 PM Page 6
`
`+
`
`I
`
`Frame - Time of packet arrival, total size in bytes (446 bytes).
`
`Ethernet (14
`bytes)-MAC
`addresses of the
`Destination and
`Source
`
`Internet Protocol
`(20 bytes) - Ver(cid:173)
`sion of IP, type of
`protocol
`
`User Datagram
`Protocol (8
`bytes) - Source
`port, destination
`port, checksum
`
`Session Initiation Protocol (404 bytes) -
`Request-Line:
`MESSAGE sip:10.1.1.2:5060; transport=udp SIP/2.0
`Message Header:
`From: <sip: Alice@foobar.com>
`To: <sip: Bob@foobar.com>
`Content-Type: text/plain; charset=UTF-8
`Message Body:
`Line-based text data : text/plain
`Hello!
`(If this message is prefixed with "emoticon" of smile it will be represented
`as - ":-) Hello" and the total number of bytes will increase by 3.)
`
`■ Box 1.
`
`I
`
`Frame - Time of packet arrival, total size in bytes (311 bytes).
`
`Ethernet (14
`bytes)-MAC
`addresses of the
`destination and
`source
`
`Internet Protocol
`(20 bytes) - Ver(cid:173)
`sion of IP, type of
`protocol
`
`Transmission
`Control Proto(cid:173)
`col (20 bytes)
`- Source port,
`destination port,
`window size,
`checksum
`
`Jabber XML Messaging (257 bytes) -
`<message type='chat' to= 'bob@foobar.com'><x
`xmlns='jabber:x:event'> <composing/> </x> < body>
`Hello! </body>< html xmlns='http://jabber.org/protocoVxhtml-
`im'> <body xmlns='http://www.w3 .org/ 1999/xhtml'>Hello! </body>
`</html> </message>
`(If this message is prefixed with "emoticon" of smile it will be represented
`as - ":-) Hello" and the total number of bytes will increase by 3.)
`
`■ Box 2.
`
`share a set of common attributes : to, from, id, type, and
`xml:lang. Accordingly, network packet containing message
`"Hello!" from A1ice@foobar.com to Bob@foobar.com will be
`as shown in Box 2.
`According to I!l), Jabber provides chat, error, groupchat,
`headline, and normal as types of message for IM, and unavail(cid:173)
`able, subscribe, subscribed, unsubscribe, unsubscribed, probe,
`and error as various statuses for presence. For IM a client
`requests a session with a server, and a server responds by cre(cid:173)
`ating that session. After the session has been created, entities
`exchange messages and presence information using XML
`stanzas. As mentioned before, a server is responsible for deliv(cid:173)
`ering the messages to the recipient's server or the client. A
`contact list for an entity or a "buddy list," as it is popularly
`known, is called a roster. A contact in the roster item indicates
`that the user has subscribed to the contact's presence informa(cid:173)
`tion. There are various types of subscription services described
`in 1!1.!fil.
`SIP/SIMPLE and Jabber/XMPP are very different tech(cid:173)
`nologies and are currently in different stages of development.
`Table 2 compares the characteristics of these two open stan(cid:173)
`dards. SIMPLE has more promising features than XMPP
`since SIMPLE can be connected to other services through
`SIP. However, there have been fewer deployable IM solutions
`than in Jabber/XMPP. This might change gradually as collab(cid:173)
`oration between various industry participants increase, as evi(cid:173)
`dent in recent initiatives (http://www.microsoft.com/presspass/
`press/2004/j ul 04/07 lSEn terpriseIM Connectivity PR. asp)
`between Microsoft= , Yahoo'" and AOL'". XMPP architec(cid:173)
`ture is more stable now and widely deployed through Jabber.
`However, it has limited capability to connect various devices
`as compared to SIMPLE.
`
`Motivations for Implementing Instant
`Messaging System on Campus
`IM&P can provide a point of connection for each student on
`
`the campus. Most students do not have office space but usual(cid:173)
`ly carry a cell phone or laptop computer. Wireless Internet
`access on campuses is on the rise and students use their lap(cid:173)
`tops to work on projects, assignments and exams. If all stu(cid:173)
`dents, staff, and faculty are connected to the IM&P service,
`we can distribute various information including emergency
`news, campus events, and other important announcements.
`Students and faculty can engage in real-time discussions that
`can take learning out of a classroom setting. With voice over
`IP (VoIP) and IM&P services widely deployed, everybody on
`campus will be reachable through these new technologies.
`IM&P service is more media-rich than traditional applica(cid:173)
`tions such as mail, phone, and email. By using IM&P, we can
`deliver voice, video, and data together to various endpoints.
`We can integrate the delivered messages with existing systems
`and infrastructure. For example, we can share presentation
`files during videoconferencing sessions. We can search for
`images from our database and transmit them through IM&P
`services. This feature will save both time and money for cam(cid:173)
`puses.
`IM&P also enables online social networking. It can be used
`to create communities for different purposes. Students can
`form study groups; faculty can utilize this technology for
`research collaboration with students and/or other faculty
`members. Current IM&P services provide functionality that
`can help users in managing different buddy lists for different
`projects, and storing, processing, and archiving shared com(cid:173)
`munication as a knowledge repository for later use. IM&P
`services can improve decision making quality by reducing
`response time and providing instant decisions. It can be inte(cid:173)
`grated with other middleware services such as calendaring and
`project management, which can help to improve the entire
`decision making process. Other interesting applications would
`include campus security, disaster and emergency control,
`career services, online community, social clubs, volunteering,
`distance learning, and cyber classrooms. However, this emerg(cid:173)
`ing phenomenon of IM within college campuses is not yet
`fully understood.
`
`6
`
`IEEE Network • May/June 2005
`
`$
`
`+
`
`

`

`I CHATTERJEE LAYOUT 4/20/05 4: 38 PM Page 7
`
`+
`
`Criteria
`
`SIP/SIMPLE
`
`XMPP
`
`Working Group
`
`SIP/SIMPLE (IETF)
`
`Jabber/XMPP (IETF)
`
`Base technology
`
`Signaling
`
`Data transport (roots in open source community)
`
`Instant messaging method
`
`Peer-to-peer
`
`Client/server
`
`Message format
`
`Text-based negotiable formats for IM, XML for
`presence attributes
`
`XML
`
`Technical development
`
`Under development
`
`In operation since 1999
`
`Advantage
`
`Disadvantage
`
`• Provide converged and unified messaging
`• Text-based protocol and easy to develop
`applications
`• Clients can be integrated with other applications
`• Smart clients and simple core
`• Connects seamlessly to SIP and VoIP telephony
`world
`• Support of Microsoft (built in function of
`WindowsXP)
`
`• Stable technology
`• Small message size compare to SIMPLE
`• Standardized documentation technology (XML)
`can be combined with other technologies
`• Transparent message exchange (able to appl
`security policies)
`
`• Not matured yet
`• Complex architecture with various servers
`• Difficult to apply security policies due to the lack
`of server capability to check the message contents
`
`• Asynchronously transports of XML content
`• Need to develop various client devices for
`XMPP
`• Server may overload with the presence and
`instant messaging (implementation dependent)
`
`Media support
`
`Extensible to other media types such as telephony,
`video
`
`Use XML streaming technology for data
`exchange, integration to applications and sys-
`terns
`
`NAT/firewall issues
`
`Feature completeness:
`On/off presence
`Extended presence
`Single message
`Chat sessions
`Contact lists
`Group chat
`
`Industry lobby
`
`As a signaling technology, SIP passes IP addresses
`which are a problem for NATs. Also Firewalls have
`to allow ports for media passing . These ports tend
`to be dynamic which is a problem in SIP. (MIDCOM
`and Interactive Connectivity Establishment [ICE] are
`emerging solutions.)
`
`The application layer does not need to be ana-
`lyzed in XMPP. Addressing in XMPP/Jabber is
`always logical and not physical. XMPP requires
`the opening of two ports in firewalls (5222 for
`client-server and 5269 for server-server).
`
`Yes
`In progress?
`Yes
`In progress
`Yes
`In progress
`
`Yes
`Yes
`Yes
`Yes
`Yes
`Yes
`
`Pledged support from Microsoft, IBM, Sun, 3GPP,
`Open Mobile Alliance
`
`Investments and support from HP, Intel, Sony,
`Hitachi, Oracle
`
`I
`
`I
`
`I
`I
`
`I
`
`I
`
`■ Table 2. Comparisons of SIP/SIMPLE and Jabber/XMPP.
`
`Survey, Data, and Analysis
`
`In an attempt to better understand the higher education com(cid:173)
`munity in relation to IM&P, we designed a Web-based smvey
`to gather responses from users. This Web-based survey was
`conducted from July to September 2004. The sample was
`made up of students from an undergraduate college and a
`graduate university, and from two mailing lists with members
`from around the world who are active in the area of IM&P
`and VoIP. The questions were segregated into three different
`groups: overview information relating to the occupation of the
`respondent and the field in which they are involved, current
`usage of IM&P, and future use and role of IM&P.
`
`The total number of valid responses received from the sam(cid:173)
`ple was 111. Of those, 51.4 percent were students, 5.4 percent
`were faculty, 23.4 percent were IT staff, and the rest were
`managers or administrative staff. As illustrated in Table 3,
`there was a nearly even distribution of full-time students and
`full-time working individuals. 45.9 percent of the respondents
`were from universities with more than 5000 students, 28.7 per(cid:173)
`cent from universities with between 1000 and 2500 students.
`16.7 percent from universities with less than 1000 students,
`and 9.3 percent from universities with 2500-5000 students.
`Most of the respondents (91.6 percent) were from universities
`with average class size of less than 50 students. Most of the
`students or faculty belonged to arts and humanities, business
`
`IEEE Network • May/June 2005
`
`7
`
`$
`
`+
`
`

`

`I CHATTERJEE LAYOUT
`
`4 / 20 / 05 4: 38 PM Page 8
`
`What alternate technology do you use?
`
`Which IM clients do you use?
`
`Email
`
`Telephone
`
`Face-to-face
`
`Cell phone
`
`Snail mail
`
`28
`
`26
`
`25
`
`Messe~J~
`AOLIM
`Yahoo
`Messenger
`Other
`Jabber client
`XP Messenger
`~~kfl~i
`Wo~ig~~
`
`20
`
`11
`
`so
`
`45
`
`39
`
`24
`
`7
`
`0
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`0
`
`10
`
`20
`
`30
`
`40
`
`Which features of IM client do you mainly use?
`
`Where do you use IM for school purposes?
`
`Text
`
`File transfer
`
`Audio
`
`Video
`
`Home
`
`On campus
`
`Work
`
`On the move
`
`so
`
`60
`
`62
`
`0
`
`20
`
`40
`
`60
`
`80
`
`100
`
`0
`
`10
`
`20
`
`30
`
`40
`
`so
`
`60
`
`70
`
`For what purpose do you use IM on campus?
`
`Why did you choose the particular client(s)?
`
`Chat w friends
`
`caiPe'1'B/,~
`Share notes
`Other
`Research
`pf6'fe1sTo~
`Prepare for exams
`
`-
`•
`0
`
`8
`s
`10
`
`23
`
`17
`16
`
`66
`
`so
`
`Friends use it
`I find this is th~f.i~t
`
`Other
`
`1 canc'l,"ot,~egUt"tP.X~t
`
`8
`
`Campus policy dJW~~~
`
`22
`
`21
`
`56
`
`20
`
`30
`
`40
`
`so
`
`60
`
`70
`
`0
`
`10
`
`20
`
`30
`
`40
`
`so
`
`60
`
`+
`
`■ Figure 4. Overview information gathered from respondents.
`
`+
`
`management, IT, politics and economics, or science and engi(cid:173)
`neering as a major.
`Out of 111 respondents, only 74.8 percent were currently
`using IM technologies. Among these current IM users, 63.1
`percent had three or more years of experience in using IM,
`27.4 percent between one and three years, and 9.5 percent
`less than one year. 76.8 percent of current IM users made use
`of one to three different IM clients, 15.9 percent used three to
`six different clients, and only 7.3 percent used more than six
`clients. Furthermore, referring to Table 3, 84.8 percent of the
`respondents did not receive an IM account upon registration
`with the college, indicating lack of IM infrastructure in the
`colleges. 31.3 percent of the respondents used IM for formal
`communication. This falls far short of IM usage for informal
`communication, which was 100 percent. 43.2 percent of the
`respondents were somehow involved in the IT decision mak(cid:173)
`ing process.
`As illustrated in Fig. 4, users who did not use IM, 28 of the
`total 111 respondents, used email as their most preferred
`alternate tec