 a set of extensions that would let SIP provide instant mes- saging and presence service. Using SIP with these extensions will meet the requirements outlined by the IMPP working group for every IETF protocol that they might conceivably adopt for this purpose. When various approaches to a problem are under consideration, the minimum require- ment is that all protocols developed for instant messaging and presence interoperate [draft-ietf-impp-cpim]. Presence Architecture Basically, an instant messaging and presence service is implemented using two SIP extensions: the MESSAGE method and the SUBSCRIBE/MODIFY framework. The architecture used for presence consists basically of two nodes: the Presence User Agent (PUA) and a presence server. The Presence User Agent, as we call a SIP UA used for presence services, REGISTERS the user's status with the presence server. Hence when Bob logs off his laptop, Bob's PUA will send a REGISTER reporting that Bob is currently unavailable to the presence server. Remember that a single user might have several PUAs. For instance, Bob has a PUA in his workstation and another one in his laptop. Thus, the presence server gathers REGISTERs from these two devices to keep track of a single user. Suppose another user is interested in Bob's presence information, SO he subscribes to Bob's presence server. After that, every time Bob's presence information changes, the presence server will transmit a NOTIFY request with new status information. Laura is usually interested in what Bob is up to and her PUA receives a NOTIFY saying that Bob has logged off. Laura will see the label on her screen next to Bob's name change from available to unavailable. In Figure 7-4, Bob's two PUAs send presence information through REG- ISTERs to the presence server. Laura SUBSCRIBEs to Bob's presence information for updates on Bob's presence. This example shows how Bob's PUAs send a simple form of presence information: available or unavailable. However, SIP can furnish much more information than this. Bob might be unwi