CHATTERJEE LAYOUT 4/20/05
`
`4:38 PM Page 2
`
`
`
`
`
`Instant Messaging and Presence
`Techno/ogies for Co//ege Campuses
`
`Samir Chatteriee, Tarun Abhichandani, Haiqing Li, and Bengisu 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/reiect a brief chat session. Various proprietary IM and
`presence (IM&P) solutions are currently on the market, and standards are emerg-
`ing. There are interoperability problems between the two dominant standards (SIM-
`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-
`ization work being done within IETF, and present an overall architecture of emerg-
`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 Iig t 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 EL.
`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), ICQTM (“1 Seek You”), MSNTM or
`WindowsXPTM Messenger, and YahooTM Messenger [2].
`Instant messaging, by making us able to know the availabili-
`ty of our peers, provides us with improved communication
`compared to other technologies. We can send an email mes-
`sage at any time and get a reply at the recipient’s conve-
`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-
`cations and providing presence information [3]. This new phe-
`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-
`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-
`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-
`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-
`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-
`ever, it is important to also note that as yet no definitive stan-
`dard has emerged across the industry. Second, we identify
`motivations for IM and presence (IM&Pl) usage, survey the
`higher education community regarding the use of IM&P, and
`present preliminary results of the data analysis. Third, we dis-
`cuss implications for using IM&P technology and services
`based on our preliminary data interpretation. This could be
`very helpful to information technoloy (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
`
`I This acronym has been adoptedfrom
`http://www.ietf. org/him].chaners/simple-chartenhtml
`
` 2
`
`0890-8044/05/$20.00 © 2005 IEEE
`
`IEEE Network 0 May/June 2005
`
`Page 1 of 11
`
`Sarnsung Exhibit 1030
`
`fie
`
`Page 1 of 11
`
`Samsung Exhibit 1030
`
`

`

`CHATTERJEE LAYOUT 4/20/05
`
`4:38 PM Page 3
`
`
`
`Public services
`
`
`
`Private services
`
`Available to anybody; often free; use a central-
`ized third—party server to relay messages
`
`IM systems designed for enterprise and corpo-
`rate use; secure IM, message logging, enterprise-
`class service, corporate control
`
`IM solutions
`Characteristics
`
`Vendor examples
`
`AOL Instant Messenger”, MSN Messenger“, Yahoo!
`
`Messenger“
`
`AOL Enterprise AIM'", Yahoo Messenger Enterprise”,
`Microsoft Messenger Connect for Enterprise”, IBM
`Lotus Sametime'"
`
`
`
`
`
`
`
`
`
`
`Open source tools
`Based on open source XMPP standard
`Jabber Inc., Jabber.0rg
`
`
`I Table l . Instant messaging systems.
`
`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 lnc,. DynamicSoft Inc., FaceTime
`Communications, Invertix Corp., NotePage Inc., Pres-
`enceWorks Inc., Vayusphere Inc.
`
`with a brief history followed by a generic model and architec-
`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-
`sent results of our initial survey. We discuss implications for
`practitioners and researchers. Finally, we conclude this article.
`
`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-
`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.
`
`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-
`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-
`tional capability among users who were connected to a public
`network anywhere in the world [5]. IRC offered an environ-
`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-
`tiate a private communication between two users.
`ICQ (“1 Seek You”) beta version was released in Novem-
`ber 1996 by Mirabilis. ICQ utilized peer-to-peer communica-
`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-
`prietary code, which were not interoperable. In 1998, Jabber
`
`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
`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-
`sentities and watchers. Presentities provide presence informa-
`tion to be stored and distributed, whereas watchers receive
`presence information from the service. Watchers can be fetch-
`ers or subscribers. Fetchers pull the value of presence informa-
`tion for a specific presentity from the presence service. If a
`fetcher is fetching information on a regular basis, it is called a
`puller. 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-
`ment, Status, and two optional elements, Communication
`Address and Other Presence Markup. The Status field is
`2 Peter SaintAndre ofJabberprovided an interesting thread to this on the
`defined to have at least two states: open and closed. In the
`Internet 2 Working Group Integrated Infrastructure for Instant Messaging
`former state, IMs will be accepted, and in the latter state they
`(121M) mailing list.
`will not. Other possible values for Status may be busy, away,
`
`IEEE Network - May/June 2005
`
`Page 2 of 11
`
`a
`
`Page 2 of 11
`
`

`

`CHATTERJEE LAYOUT 4/20/05
`
`4:38 PM Page 4
`
`
`
`
`
`Watcher
`user agent
`
`
`
`Principal
`(user)
`
`Watcher
`
`
`
`-
`
`
`
`Notification
`
`
`
`Instant messaging and presence client
`
`
`message
`serVIce
`
`I Figure l .A generic modelforpresence and instant messaging.
`
`do not disturb, and so on (these statuses are further extended
`in SIMPLE and XMPP). The Communication Address ele—
`ment is composed of Communication Means and Contact
`Address fields, enabling a user to utilize various types of com-
`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 inbaxes. 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.
`
`and Application Exchange (APEX). Working groups for these
`alternative standards follow different principles for imple-
`menting IM&P services. SIMPLE builds on the SIP infras-
`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-
`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 [fl] provides mechanisms for session-oriented
`communication but not for presence and IMs. The SIMPLE
`working group (henceforth referred to as SIMPLE) has been
`Understanding SIMPLE and XMPP Open Standards
`chartered to provide extensions for SIP that can be used for
`Within IETF, IMPP was the first working group formed to
`implementing IM&P services. The standards prescribed by
`define protocols and data formats so that disparate applica-
`SIMPLE use SIP as a signaling protocol and describe the
`tions can interoperate across the Internet. In addition, there
`usage of SIP for subscription and notifications for presence. It
`were various standards that provided alternative solutions for
`supports various models for IM&P applications [3, 11] and
`IM&P — SIMPLE, Presence and Instant Messaging (PRIM),
`
`
`Presence subsystem
`
`Upload presence
`°Collocation
`- Register method
`°Update documents
`
`(PUA)
`
`Presence agent (PA)
`(proxy/registra r)
`
`Subscribe
`
`
`
`essage/open session Presence user agent
`
`Instant messaging subsystem
`
`I Figure 2. SIMPLE components.
`
`IEEE Network 0 May/June 2005
`
`Page 3 of 11
`
`a
`
`Presentity
`
`Presence
`information
`
`d
`
`Presence
`user agent
`
`
`
`
`
`
`
`
`
`
`
`"Iii:naming;''
`
`
`Presence
`serVIce
`
`
`
`Fetcher
`
`
`(roller)
`
`uetsw-_____.__________________ Suifiessaw
`
`
` Instant
`
`
`Page 3 of 11
`
`

`

`CHATTERJEE LAYOUT 4/20/05
`
`4:38 PM Page 5
`
`
`
`Server-to-server
`
`CIient—to-server
`
`Jabber server 1
`
`Foreign IM
`ateway
`Jabber to SIP)
`
`Session
`manager
`
`SIMPLE
`client
`
`SIMPLE
`client
`
`
`
`
`
`
`
` Resolver
`
`I 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-
`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-
`tion for a presentity. There can be multiple PUAs for a pre-
`sentity, using many devices [E]. 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 [fl]: 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-
`er sends a SUBSCRIBE request to a PA. Once the subscrip-
`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.
`
`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-
`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
`The architecture, presented in
`Fig. 3, depicts three different components in a cohesive net-
`work of IM&P: Jabber servers, Jabber clients, and non-Jabber
`servers. Furthermore, the illustration details an internal work-
`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-
`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
`The network packet was captured on the source machine
`between authorized clients, servers, and other entities [g]. In
`Jabber architecture, features such as streams, stream authenti-
`— here, for example, on Alice’s machine using Ethereal Net-
`cation, and encryption provide building blocks for many types
`work Protocol Analyzer available at http://www.ethereal.com.
`The packet is not an exact illustration of all the details. It just
`of near-real-time applications
`XML streams, between
`gives an overview of how the information is stored and trans-
`two entities (clients or servers), involve creating a persistent
`ferred on the network.
`connection for exchanging XML data elements or XML stan-
`However, there is no facility for offline messaging in SIP.
`zas. An XML stanza, as defined in [1_7], is an unambiguous
`Since SIP UAs exchange IMs directly without the help of a
`unit of structured information that has a start (e.g., <conver-
`sati0n>) and an end (e.g., <conversation/>). There are three
`SIP server, SIMPLE could provide scalability for IM services.
`predefined XML stanzas in XMPP: message, used for
`However, it is difficult to monitor the message exchanges and
`exchanging instant messages between clients through one or
`apply security policies to protect the transmission of confiden-
`tial information.
`more servers; presence, used for notifying clients about the
`Prior to IETF’s initiation of solving issues such as interop-
`status of a client; and iq (Info/Query), used for request-
`response interaction between entities. All of these stanzas
`erability, Jabber came into existence [16]. Jabber technology is
`
`IEEE Network - May/June 2005
`
`Page 4 of 11
`
`fie
`
`Page 4 of 11
`
`

`

`CHATTERJEE LAYOUT 4/20/05
`
`4:38 PM Page 6
`
`4%
`
`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-
`sion of IP, type of
`protocol
`
`Session Initiation Protocol (404 bytes) —
`mm
`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
`mm
`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.)
`
`User Datagram
`Protocol (8
`bytes) — Source
`port, destination
`
`port, checksum
`
`I Box 1 .
`
`
`
` Frame — Time of packet arrival, total size in bytes (311 bytes).
`
`Internet Protocol
`(20 bytes) — Ver-
`sion of IP, type of
`protocol
`
`Ethernet (14
`bytes) — MAC
`addresses of the
`destination and
`source
`
`Jabber XML Messaging (257 bytes) —
`Transmission
`<message type='chat' to= 'bob@foobar.com'> <x
`Control Proto-
`xmlns='jabber:x:event'> <composing/> </x> < body>
`col (20 bytes)
`Hello! </body><html xmlns='httpzlfiabber.org/protocol/xhtml-
`— Source port,
`im'> <body xmlns='http://www.w3.org/ 1999/xhtml'>Hel|o!</body>
`destination port,
`</htm|> </message>
`window size,
`checksum
`(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.)
`
`I Box 2.
`
`share a set of common attributes: to, from, id, type, and
`xmlzlang. Accordingly, network packet containing message
`“Hello!” from Alice@foobar.com to Bob@foobar.com will be
`as shown in Box 2.
`According to M], Jabber provides chat, error, groupchat,
`headline, and normal as types of message for IM, and unavail-
`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-
`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-
`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-
`tion. There are various types of subscription services described
`in m, E].
`SIP/SIMPLE and Jabber/XMPP are very different tech-
`nologies and are currently in different stages of development.
`Table 2 compares the characteristics of these two open stan-
`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-
`oration between various industry participants increase, as evi-
`dent in recent initiatives (http://www.microsoft.com/presspass/
`press/2004/julO4/0715EnterpriseIMConnectivityPR.asp)
`between Microsoft”, YahooTM and AOL”. XMPP architec-
`ture is more stable now and widely deployed through Jabber.
`However, it has limited capability to connect various devices
`as compared to SIMPLE.
`
`the campus. Most students do not have office space but usual-
`ly carry a cell phone or laptop computer. Wireless Internet
`access on campuses is on the rise and students use their lap-
`tops to work on projects, assignments and exams. If all stu-
`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-
`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-
`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-
`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-
`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,
`Motivations for Implementing Instant
`distance learning, and cyber classrooms. However, this emerg-
`Messaging System on Campus
`ing phenomenon of IM within college campuses is not yet
`
`IM&P can provide a point of connection for each student on fully understood.
`
`IEEE Network 0 May/June 2005
`
`Page 5 of 11
`
`fie
`
`Page 5 of 11
`
`

`

`CHATTERJEE LAYOUT
`
`4/20/05
`
`4:38 PM Page 7
`
`
`
`
`
`Criteria
`
`SIP/SIMPLE
`
`Working Group
`
`SIP/SIMPLE (IETF)
`
`XMPP
`
`Jabber/XMPP (IETF)
`
`
`
`SignalingBase technology Data transport (roots in open source community)
`
`
`
`Instant messaging method
`
`Peer-to-peer
`
`Client/server
`
`Text-based negotiable formats for IM, XML for
`XML
`
`Message format
`presence attributes
`
`In operation since 1999
`Under development
`Technical development
`
`- 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
`0 Support of Microsoft (built in function of
`Windows XP)
`
`0 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
`
`Extensible to other media types such as telephony,
`Video
`
`- 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)
`
`- Asynchronously transports of XML content
`- Need to develop various client devices for
`XMPP
`- Server may overload with the presence and
`instant messaging (implementation dependent)
`
`Use XML streaming technology for data
`exchange, integration to applications and sys-
`tems
`
`Advantage
`
`Disadvantage
`
`Media support
`
`NAT/firewall issues
`
`
`
`
`
`
`
`As a signaling technology, SIP passes IP addresses
`The application layer does not need to be ana—
`which are a problem for NATs. Also Firewalls have
`lyzed in XMPP. Addressing in XMPP/Jabber is
`to allow ports for media passing. These ports tend
`always logical and not physical. XMPP requires
`to be dynamic which is a problem in SIP. (MIDCOM
`the opening of two ports in firewalls (5222 for
`and Interactive Connectivity Establishment [ICE] are
`client-server and 5269 for sewer-sewer).
`emerging solutions.)
`
`
`Feature completeness:
`Yes
`Yes
`Les m fess.)
`On/off presence
`Yes
`Yes
`9
`'
`Extended presence
`Yes
`In W ress
`Single message
`Yes
`Yes
`9
`Chat sessions
`Contact lists
`Yes
`In progress
`Group chat
`
`
`IndUStry IObby
`
`Pledged support from Microsoft, IBM, Sun, SGPP,
`Open Mobile Alliance
`
`Investments and support from HP, Intel, Sony,
`Hitachi, Oracle
`
`I Table 2. Comparisons of SIP/SIMPLE and Jabber/XMPP.
`
`Survey, Data, and Analysis
`
`The total number of valid responses received from the sam-
`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
`In an attempt to better understand the higher education com-
`managers or administrative staff. As illustrated in Table 3,
`munity in relation to IM&P, we designed a Web-based survey
`there was a nearly even distribution of full-time students and
`to gather responses from users. This Web-based survey was
`full-time working individuals. 45.9 percent of the respondents
`conducted from July to September 2004. The sample was
`were from universities with more than 5000 students, 28.7 per-
`made up of students from an undergraduate college and a
`cent from universities with between 1000 and 2500 students.
`graduate university, and from two mailing lists with members
`from around the world who are active in the area of IM&P
`16.7 percent from universities with less than 1000 students,
`and 9.3 percent from universities with 2500—5000 students.
`and VoIP. The questions were segregated into three different
`groups: overview information relating to the occupation of the
`Most of the respondents (91.6 percent) were from universities
`with average class size of less than 50 students. Most of the
`respondent and the field in which they are involved, current
`students or faculty belonged to arts and humanities, business
`usage of IM&P, and future use and role of IM&P.
`
`
`IEEE Network - May/June 2005
`
`Page 6 of 11
`
`fie
`
`Page 6 of 11
`
`

`

`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
`
`File transfer
`
`MSN
`Messenger
`AOL IM
`Y h
`Messé‘né’e‘l‘Other
`Jabber client
`XP Messenger
`M Lotus
`ametlme
`roove
`Wor‘lispace
`
`Which features of IM client do you mainly use?
`
`Where do you use IM for school purposes?
`
`82
`
`On campus
`
`0n the move
`
`Campus policy dtifitated
`
`For what purpose do you use IM on campus?
`
`Why did you choose the particular client(s)?
`
`Chat w friends
`
`afil’e'é'él‘lé'!
`Share notes
`Other
`Research
`Co m w
`pro essors
`Prepare for exams
`
`5°
`
`Friends use it
`| find this is the est
`c lent
`Other
`Ican otre llw.
`I
`c ose tchaat clllgnt
`e use
`
`
`
`
`
`
`
`I Figure 4. Overview information gatheredfrom respondents.
`
`Respondents chose text as the most used feature in messaging
`management, IT, politics and economics, or science and engi-
`followed by file transfer. Most of the users utilized IM for
`neering as a major.
`exchanging IMs with friends or colleagues; few of them used
`Out of 111 respondents, only 74.8 percent were currently
`it for communicating with professors or preparing for exams.
`using IM technologies. Among these current IM users, 63.1
`Most of the respondents used IM at home, but using IM in an
`percent had three or more years of experience in using IM,
`office or on campus did not seem unusual. Respondents used
`27.4 percent between one and three years, and 9.5 percent
`a particular IM application since it was being used by their
`less than one year. 76.8 percent of current IM users made use
`peers or friends.
`of one to three different IM clients, 15.9 percent used three to
`Referring to Table 4, among the responses from IT man-
`six different clients, and only 7.3 percent used more than six
`agers, 88.4 percent indicated that their university did not
`clients. Furthermore, referring to Table 3, 84.8 percent of the
`implement any policy for IM usage on campus. 92.7 percent
`respondents did not receive an IM account upon registration
`indicated lack of budget for IM infrastructure. Also, more
`with the college, indicating lack of IM infrastructure in the
`than half indicated that the existing systems should not be
`colleges. 31.3 percent of the respondents used IM for formal
`integrated with IM services.
`communication. This falls far short of IM usage for informal
`Table 5 enumerates the responses received in relation to
`communication, which was 100 percent. 43.2 percent of the
`future use and role of IM&P. Interpretations from these
`respondents were somehow involved in the IT decision mak-
`responses follow. Using IM increases efficiency and productiv-
`ing process.
`As illustrated in Fig. 4, users who did not use IM, 28 of the
`ity if it is ubiquitous (i.e., available on the cell phone and used
`extensively on campus, but not part of every class). However,
`total 111 respondents, used email as their most preferred
`all kinds of communication need not be through IM. It need
`alternate technology. However, it was not the dominant alter-
`not be the primary tool for collaboration activities like
`native. Other methods involved using telephones, face-to-face
`research or replace existing technologies such as email. Users
`meetings, or cell phones. Among IM clients, MSN Messen-
`like being informed about campus and college or university
`ger” was the dominant technology for IM followed by AIM “"
`correspondence through other channels, which could be tradi-
`and then Yahoo Messenger”. Furthermore, there were cer-
`
`tain other messaging technologies indicated by respondents. tional or innovative. Although IM