11
`
`The GSM cellular telephony system, and the Personal Mobile Telecommunications option of
`the Japanese cellular telephony system (PDC) support personal mobility within their respective
`networks by separating the subscriber’s identity from the device he uses. However, it is unlikely
`that people will use only one type of network in the future. Therefore, these systems cannot provide
`the full personal mobility support that MPA aims to provide.
`Mobile IP [Per96] enables a mobile host to be addressed by a well-known, static IP address and
`to receive communication regardless of its current point of attachment to the Internet. However, it
`provides only host mobility and only within the Internet.
`Iceberg [JBK98] aims at integrating cellular telephony networks with the Internet. It shares with
`MPA the view that people will continue to use multiple devices for communication. However, Iceberg
`approaches the problem primarily at the network layer, rather than the people layer. Moreover,
`it does not provide location privacy. We believe location privacy is a key goal when supporting
`personal mobility.
`A related project is NINJA [GWBC99], which focuses on providing an infrastructure for the
`construction of flexible and adaptable services in a clustered environment. This infrastructure
`could provide a solid foundation for new, pluggable Application Drivers in our Personal Proxy.
`The Presence Information Protocol [ADM98] (PIP) and the IDentity Infrastructure Protocol [FM98]
`(IDIP) provide some support for personal online identities and tracking of people. Both allow peo­
`ple to advertise dynamic information about their online presence and to exchange instant messages
`with each other. IDIP goes a step further, by permitting more specific negotiation of multimedia
`communication formats. Neither of the two approaches addresses location privacy.
`
`VII. Conclusions
`People-centric communication is the next big step for mobile computing. Whereas existing mech­
`anisms have addressed mobility in the network, none has fully addressed the issue of providing
`mobility support to people, who are the ultimate and most important endpoints of communication.
`We propose an architecture called the Mobile People Architecture (MPA), which provides support
`for instant and convenient communication between people, as they move from place to place and
`make use of multiple heterogeneous communication devices, including laptops, PDAs, or cellular
`phones. MPA makes it possible for people to protect their location privacy and for application
`designers to facilitate the deployment of their applications within this framework. We identify
`the key components within this architecture and their corresponding functionalities. Finally, we
`illustrate a potential prototype design of the system.
`People cannot be the outsiders in the communication landscape any longer. We firmly believe
`that with the help of the mobile computing research community, this challenge will be met.
`
`VIII. Persistent Mobile Data
`
`A. Design Issues
`While MPA mainly focuses on delivering messages, it is important to consider what happens to
`a message once it arrives at the recipient’s device. Most people do not simply throw messages away
`after reading or hearing them; some people diligently categorize and archive all their messages,
`while others just let them pile up in an “inbox.” Email and voicemail systems currently fulfill this
`need by allowing users to manage archives of their messages. However, they don’t allow users to
`keep one consistent message archive that may be distributed among multiple devices. Instead, they
`force users to act as the consistency mechanism between multiple message archives.
`
`Epic Games Ex. 1029
`Page 122
`
`

`

`12
`
`We propose a personal distributed file system (DFS) that allows people to locate, access and
`manage their personal data—including message archives—regardless of where they are or what
`devices they use.
`Multi-user constraints of earlier DFS systems (see Section VI) are relaxed in the personal DFS
`case. This is because one person is unlikely to be modifying two copies of a file at the exact same
`time, or at least by nature, avoids doing so.
`In a personal DFS, users will have data and files spread over several devices, and should be able
`to control which subsets are propagated where. Some devices are more resource-poor than others.
`For example, a palmtop device is unlikely to have the same amount of computational power and
`storage as a laptop. Therefore, users will want to store or view only a subset of all their personal
`data on each device.
`A persistent mobile data mechanism could be used to synchronize a user’s message store, as well
`as his or her files.
`While the personal DFS does not have the multi-user constraints of previous systems, it does
`present other challenges, because:
`• not all hosts are up and running and connected.
`• not all devices run on the same platform or share the same principal file system.
`• there may be no general mechanism to guide the data traversal from device to device. Sometimes
`we will need application-specific mechanisms to do this.
`A.O.a Rumor. Rumor[GRR+98), from UCLA’s File Mobility Group, is a software package that
`allows users to keep multiple copies of their files synchronized on different machines automatically.
`For example, Rumor would allows a user to keep one copy of her files on her desktop machine at
`work, a second copy on a portable machine, and a third copy on a machine at home. Rumor could
`also be used at different sites to share files, with each site storing its own local copy. It detects
`changes made to any files under its control and propagates the changes made at any replica to all
`other replicas. Rumor permits users to update any of their replicas freely, while guaranteeing that
`the updates will be properly propagated to all replicas.
`A.O.b Distributed File Systems. Existing distributed file system protocols (e.g. NFS, AFS, SMB,
`Coda) have unnecessarily strict consistency requirements, and treat disconnected operation as a
`special case. They also force a distinction between clients and servers.
`Coda at least allows replication of data among several servers. Coda has the best support for
`disconnected operation: clients record a log of all file system calls while disconnected, which is then
`replayed upon reconnection.
`Some of the key differences in motivation between traditional distributed file systems and our
`work can be found in the Coda paper: “Servers are like public utilities...they are carefully monitored
`and administered by professional staff.” “Disconnected operation...represents a temporary deviation
`from normal operation.” We expect that neither of these assertions will hold true in the future.
`
`IX. Acknowledgements
`We would like to thank Ichiro Okajima, of NTT DoCoMo, for providing us with valuable questions
`and suggestions during our MPA discussions, Trevor Holt of Nortel Networks for bringing to our
`attention related work on PIP and IDIP, and Armando Fox for his encouragement.
`This research has been supported by a gift from NTT Mobile Communications Network, Inc.
`(NTT DoCoMo), a grant from the Keio Research Institute at SFC, Keio University and the
`Information-technology Promotion Agency in Japan, and a grant from the Okawa Foundation.
`
`Epic Games Ex. 1029
`Page 123
`
`

`

`13
`
`References
`[ADM98] S. Aggarwal, M. Day, and G. Mohr. Presence Information Protocol Requirements, August 1998.
`http://search.ietf.org/internet-drafts/draft-aggarwal-pip-reqts-OO.txt.
`[Arne) America Online, Inc. AOL Instant Messenger, http://www.aol.com/aim/.
`(ATT) AT&T Easy ReachSM 500 Service, http://www.att.com/easyreach500/.
`[FM98] S. Fujimoto and D. Marvit. The IDentity Infrastructure Protocol, August 1998.
`http://search.ietf.org/internet-drafts/draft-fujimoto-idip-00.txt.
`[GRR+98] Richard Guy, Peter Reicher, David Ratner, Michial Gunter, Wilkie Ma, and Gerald Popek. Rumor:
`Mobile Data Access Through Optimistic Peer-to-peer Replication. In Proceedings: ER’98 Workshop on
`Mobile Data Access, 1998.
`[GWBC99] S. D. Gribble, M. Welsh, E. A. Brewer, and D. Culler. The MultiSpace: an Evolutionary Platform for
`Infrastructure Services. In Proceedings of the Usenix Annual Technical Conference, June 1999.
`[ICQ] ICQ, Inc. How to Use ICQ. http://www.icq.com/icqtour/quicktour.html.
`[JBK98] A. D. Joseph, B. R. Badrinath, and R. H. Katz. The Case for Services over Cascaded Networks. In
`Proceedings of WOMMOM ’98, October 1998.
`|Per96] Charles Perkins. IP Mobility Support - RFC2000, 1996.
`[WKH97] M. Wahl, S. Kille, and T. Howes. Lightweight Directory Access Protocol (v3) - RFC 2251, 1997.
`*ld: TochReport. tex.v 1.9 1999/03/14 00:35:57 l«lk Exp t
`
`Epic Games Ex. 1029
`Page 124
`
`

`

`draft-rosenberg-sip-pip-OO.txt
`Internet Engineering Task Force
`WG
`Internet Draft
`J.Rosenberg,H.Schulzrinne
`draft-rosenberg-sip-pip-OO.txt
`U.
`November 13, 1998
`Expires: May 1999
`
`pipr
`
`Bell Laboratories.Columbia
`
`SIP For Presence
`
`STATUS OF THIS MEMO
`
`This document is an Internet-Draft. Internet-Drafts are working
`documents of the Internet Engineering Task Force (IETF), its areas,
`and its working groups. Note that other groups may also distribute
`working documents as Internet-Drafts.
`
`Internet-Drafts are draft documents valid for a maximum of six months
`and may be updated, replaced, or obsoleted by other documents at any
`time. It is inappropriate to use Internet-Drafts as reference
`material or to cite them other than as "work in progress'1.
`
`To learn the current status of any Internet-Draft, please check the
`'' 1 id-abst racts. txt'' listing contained in the Internet -Draf ts Shadow
`Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
`munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
`ftp.isi.edu (US West Coast).
`
`Distribution of this document is unlimited.
`
`ABSTRACT
`
`Epic Games Ex. 1029
`Page 125
`
`

`

`We describe an extension to SIP for subscription,
`notification, fetching, and indication of presence
`events. The extensions consist of two new methods,
`SUBSCRIBE and NOTIFY.
`
`1 Introduction
`
`An event notification service allows a user (called the subscriber)
`to subscribe to some entity. Associated with the entity is some
`state. The subscription is a request to be informed about changes to
`the state. When state changes occur, a notification is delivered
`asynchronously to the subscriber. The applicability of the service is
`extremely broad; events could include things like network management
`events, presence information, device status, system failures, etc.
`Subscriptions can be as simple as "notify me when person X logs in"
`
`J.Rosenberg,H.Schulzrinne
`1]
`
`Internet Draft
`1998
`
`[Page
`
`SIP Presence
`
`November 13,
`
`or as complicated as "notify me when event X in state machine Y
`occurs if the day is Tuesday and the temperature in Zimbabwe is 85
`degrees fahrenheit".
`
`Furthermore, different events and subscriptions will vary in their
`requirements for reliability, scalability (in terms of number of
`subscribers for some event), timeliness (in terms of the latency
`between an event and delivery of the notification to the
`subscribers), and control (in terms of the complexity of the
`description of events which may be subscribed to). For example,
`subscribing to a service which notifies you when concert tickets
`become available requires a supporting protocol to be scalable, and
`may mandate multicast. However, reliability is not a concern. On the
`
`Epic Games Ex. 1029
`Page 126
`
`

`

`other hand, subscribing to a service which notifies you when the
`temperature in the nuclear reactor hits some threshold requires
`absolute reliability, but scalability is less of a concern.
`
`Due to this breadth of requirements, we do not believe it practical
`to develop a broad, all-encompassing notification service in the
`context of the current Internet. Our focus, however, is to solve the
`problem in the more restrictive context of presence.
`
`We define presence (or presence information) as the means of
`communication a user is capable or willing to take part in, and may
`also include contact or address information for those means,
`preferences about which means to use and when, and state about
`availability at those means.
`
`A presence event occurs when a user logs in or out of a computer,
`changes their preferences about reachability at some location, such
`as a phone or pager, or changes their status at some location. More
`generally, a presence event is any event which changes the current
`presence information.
`
`Note that this definition is broader than just "logged in" or "logged
`out”.
`
`2 Architecture
`
`An infrastructure for presence can be broken into three elements and
`several protocol components. The elements are:
`
`o The Subscriber: an element which asks for notification of the
`presence of another user. Usually a subscriber is a human.
`
`o The Publisher: The user who has been subscribed to.
`
`o The presence server: a server which performs notification of
`
`Epic Games Ex. 1029
`Page 127
`
`

`

`J.Rosenberg,H.Schulzrinne
`2]
`
`Internet Draft
`1998
`
`[Page
`
`SIP Presence
`
`November 13,
`
`presence, and receives subscription requests. This element may
`or may not be co-resident with the machine on which the
`publisher is located. For reasons of reliability and
`availability, a separate server may perform the actual
`notifications and subscription processing, but this is not
`requi red.
`
`The presence server is a key element in a notification system. By
`allowing it to be a physically separate entity, a number of
`advantages are gained. The server can perform a number of services
`for the users it represents, such as proxy encryption, access control
`and authentication, notification routing, logging, firewalling, and
`so on. In effect, a presence server is a proxy for the publisher. It
`is natural to have several presence servers along the protocol
`message paths. For example, notification requests may pass through a
`server at both the subscriber and publisher domains. This allows for
`policy and logging operations to be provided by administrators in
`both domains.
`
`The server also plays a critical role in providing naming and call
`routing services. This is discussed in more detail below.
`
`The protocol components in the presence system are:
`
`o Subscription component: a mechanism for conveying the
`subscription from the subscriber to the presence server. The
`subscription names the publisher, and may contain additional
`information about under what conditions the subscriber would
`like to be notified about presence information related to the
`publisher. For example, the subscriber may only wish to know
`when the publisher can be contacted via video.
`
`Epic Games Ex. 1029
`Page 128
`
`

`

`o Fetching component: a mechanism al lowing a user to request the
`current status of another user, without actually instantiating
`a subscription. This is effectively a poll, whereas a
`subscription sets up an asynchronous notification.
`
`o Publication component: When the publisher and presence server
`are not co-resident, some means is required for informing the
`presence server about changes in state of the publisher.
`
`o Access Control component: The publisher needs to provide input
`about how subscription requests for it will be processed.
`These preferences may restrict the set of users which may
`subscribe, cause only select pieces of information to be
`reported, or potentially even cause false information to be
`reported based on the subscriber. A means is needed to express
`and convey these preferences from the publisher to the
`
`[Page
`
`SIP Presence
`
`November 13,
`
`J.Rosenberg,H.Schulzrinne
`3]
`
`Internet Draft
`1998
`
`presence server.
`
`o Notification component: When there is a change in the presence
`state of a user, it needs to be conveyed to the subscribers of
`that user.
`
`We further believe that each of these components is separable into
`transport and content. The general problem of transport is to provide
`delivery of the given information in a manner appropriate for the
`service. The notion of content depends on the task. For subscription,
`the content should describe the event to be subscribed to. This
`
`Epic Games Ex. 1029
`Page 129
`
`

`

`should effectively define the conditions under which a notification
`is delivered to the subscriber, and the desired content of that
`notification. For both notification and publishing, the content is a
`description of the event which has occured.
`
`The overall architecture is depicted in Figure 1.
`
`..................... A -
`subscriber l--->l
`I
`I
`I
`i
`IC---I
`----------- c -
`
`server
`
`- A -
`
`I
`I
`
`I
`I
`
`- c -
`
`............... B
`server
`l<........
`
`I<........
`- D
`
`■I publisher
`I
`I
`• I
`
`II
`
`E
`
`IDB, policy I
`I server I
`
`A = subscription
`B = access control
`C = not i ficat ion
`D = publi shing
`E = database and policy protocols
`
`Figure 1: Architecture of Presence System
`
`In the architectural diagram, there are two servers acting as
`proxies. In a real system there may be any number, including zero,
`along the message path. We focus our discussion on the case of two
`servers, one run by the subscriber's service provider, and the other
`by the publisher's service provider.
`
`Epic Games Ex. 1029
`Page 130
`
`

`

`J.Rosenberg,H.Schulzrinne
`4]
`
`Internet Draft
`1998
`
`[Page
`
`SIP Presence
`
`November 13,
`
`Note that our definition of service provider is NOT the same as ISP.
`The service provider is any organization which is making its presence
`servers available to customers. Just as a user can have separate ISP
`and mail services, a user may have its presence services by yet
`another organization.
`
`3 Naming, Addressing and Routing
`
`A key component of a presence system is naming. Subscribers must be
`named, and subscription requests delivered to them, or to the
`presence servers which represent them. It is critical that the
`publisher be able to log in to the network with different IP
`addresses, and for the system to still function. It is also critical
`that the subscriber be unaware as to whether subscription requests
`are actually delivered to the publisher directly, or through a chain
`of presence servers.
`
`The publisher must also be named, so that the presence server of the
`publisher can perform access control based on this name. The
`publisher must also provide location information, so that
`notification requests can be delivered to it. As these are two
`seperate functions, the subscription protocol must provide a means
`for indicating the canonical name of the subscriber and the address
`for delivery of notifications as separate components.
`
`We observe that these requirements for naming are, in fact, identical
`to those for email and the Session Initiation Protocol (SIP) [1], As
`a result, we propose that naming be performed using URLs constructed
`by email-like identifiers. In cases where a users mail provider and
`
`Epic Games Ex. 1029
`Page 131
`
`

`

`presence provider are the same, the identifiers can also be the same.
`For example, a user whose email address is jack@mailcompany.com would
`have a presence URL of the form pip:jack@hotmai1 company.com. This
`saves space on business cards, and allows database queries to be
`based on a consistent naming structure. As presence notifications
`(such as "I'm online now") are often the precursor to actual
`communications, using the same names simplifies integration.
`
`As a result, a key function of a presence server is the routing of
`notification and subscription requests based on this URL. Since users
`are often known by different email identifiers within different
`scopes, a presence server is also responsible for translation of
`names. For example, a user, Jack, might publish the address
`jack@company.com. A user sending a subscription for Jack would use
`the domain portion of the URI (looking up a pip.udp or pip.tcp SRV
`record, for example) to forward the subscription to the main presence
`server for the company. This server might perform some access
`control, and then, as a result of a lookup in a corporate database,
`translate the name to j .smith@sales.company.com, an internal address.
`
`J.Rosenberg,H.Schulzrinne
`5]
`
`Internet Draft
`1998
`
`[Page
`
`SIP Presence
`
`November 13,
`
`The domain name portion of this address is also looked up in the DNS,
`and the subscription request forwarded to the presence server for the
`sales department. This server then notes that j.smith is a local
`user, and it accepts the subscription.
`
`In the example above, the subscriber for Jack won't be aware of the
`translation or the alternate sales server. As an alternate means of
`processing the subscription request, a server may elect to redirect.
`In this scenario, the company's main server would inform the
`
`Epic Games Ex. 1029
`Page 132
`
`

`

`subscriber to contact the server at sales.company.com directly.
`
`In the example above, the main server for the company used a
`corporate database for the name translation. We observe that any
`number of means, in fact, can be used for the name translation,
`including LDAP [2], finger [3], whois [4], whois-H- [5], or even
`multicast queries, with the choice being a purely local matter.
`
`This system of name translation and call routing provides
`flexibility. Administrators can instantiate any kind of translation
`logic at servers. Basing the logic on time of day or subscriber
`preferences enables perrsonal mobility services. For example, a user
`can publish a single identifier for their presence, such as
`pip:jdrosen@ieee.org. They can dynamically register new addresses
`with the IEEE server as they move to new locations, just as is done
`for emai1 and SIP.
`
`We observe that this system for naming, addressing, and routing are
`identical in every regard with those used in SIP.
`
`4 SIP For Presence
`
`The discussion so far has presented a general framework for a
`presence system. We have observed that this architecture is nearly
`identical to SIP. The presence servers discussed here serve the same
`purpose as SIP servers - name translation, lookup, routing, logging,
`access control, and firewalling. SIP provides the same addressing and
`call routing architecture as proposed. SIP separates content from
`transport, which fits well with the presence application. This
`similarity is due to the fact that session initiation and presence
`subscription are nearly identical functions.
`
`This section demonstrates how the various protocol components
`required in a presence system are easily implemented with just a few
`new SIP methods, and no new headers. Almost all of the existing SIP
`headers are applicable. In the discussion below, all of the syntax
`and semantics of the headers are the same as in SIP, unless noted
`otherwise.
`
`Epic Games Ex. 1029
`Page 133
`
`

`

`[Page
`
`SIP Presence
`
`November 13,
`
`J.Rosenberg,H.Schulzrinne
`6]
`
`Internet Draft
`1998
`
`4.1 Subscription
`
`The subcription function is accomplished by sending a SIP message
`from the subscriber, addressed to the publisher. The message is a
`standard SIP message, but uses a new method, SUBSCRIBE. The message
`is forwarded until it reaches the server or end user which is
`performing notifications for the named user. The response to the
`request follows the standardSIP response codes. 200-class responses
`indicate success, 300 redirection to an alternate server, 400 client
`error, 500 server error, and 600 global failure. A 200-class response
`contains the current presence status for the user, as if it had been
`fetched.
`
`The request message must contain To, From, Cal 1-ID, Via, and CSeq
`fields. The To field contains the address of the publisher, and the
`From field contains the address of the subscriber. The Cal 1-ID field
`is a unique identifier which groups transactions associated with the
`subscription. All messages, including notifications from the server,
`and changes or updates to the subscription, will use the same Ca 11 -
`ID. In this sense, the Call-ID is a "presence session" identifier.
`The CSeq field provides ordering among messages for the same Cal 1 - ID.
`The Via field is used for routing responses to requests.
`
`A user may resubscribe or update the subscription at any time. In
`this regard, subscription requests are idempotent, as are SIP
`requests in general. Subscriptions are cancelled by sending a new
`SUBSCRIBE with an Expires: 0 in the header.
`
`Epic Games Ex. 1029
`Page 134
`
`

`

`There are a number of optional headers which may be included in a
`SUBSCRIBE request. The most important are Contact, which provides a
`contact address where notifications should be sent by the server, and
`Expires, which indicates when the subscription expires. All of the
`other SIP general headers, Date, Encryption, Record-Route, and
`Timestamp, may be present and retain the same meaning as they do in
`SIP.
`
`There are a number of request headers are relevant for transporting
`the presence information. In particular, Accept, Accept-Encoding, and
`Accept-Language, specify the allowable presence formats which are
`understood by the subscriber. The response to the request will
`contain a body that conveys the presence information. This body will
`be in one of the formats specified by the Accept header in the
`request. Basic presence information can be expressed in SIP without
`need for any body, using the Contact headers, exactly as in the call
`control extensions [6], These extensions allow for expression of
`various addresses that the user can be reached at, and for each one,
`statements of preferences and attributes.
`
`J.Rosenberg,H.Schulzrinne
`7]
`
`Internet Draft
`1998
`
`[Page
`
`SIP Presence
`
`November 13,
`
`Most of the remaining request headers - Hide, Max-Forwards,
`Organization, Priority, Proxy-Authorization, Proxy-Require, Route,
`Response-Key, have the same semantics as in SIP. The Subject header
`makes less sense for the SUBSCRIBE method. The Require header is used
`to indicate extensions which must be understood by the server. For
`presence, the token org.ietf.presence should be included in the
`Require header.
`
`Epic Games Ex. 1029
`Page 135
`
`

`

`The subscribe message will normally not contain a body, and thus the
`entity headers are not required. However, future versions of the
`presence extensions might allow a body. The body might contain more
`complex subscriptions, such as "notify me when the user logs in to a
`cell phone, but no other times".
`
`An example SUBSCRIBE message is depicted in Figure 2.
`
`SIP/2.0 SUBSCRIBE pip:jdrosen@bell-labs.com
`Via: SIP/2.0/UDP erlang.bell-phone.com:5060
`To: pip:jdrosen@bell-labs.com
`From: pip:hgs@cs.columbia.edu
`Ca11 - ID: 098y0na08fy0h@l12.33.58.22
`Contact: pip:hgs@play.cs.columbia.edu:488
`Accept: text/presence
`Organization: Bell Laboratories
`Content-Length: 0
`
`Figure 2: Example SUBSCRIBE message
`
`This message then traverses some number of servers, eventually
`arriving at the one which handles presence subscriptions for jdrosen.
`A success response might look like Figure 3.
`
`The im URL is just illustrative, and reflects what an address for
`Instant Messaging might look like.
`
`Note that the response includes the currently available presence
`information for the publisher. The basic information is presented
`using the SIP Contact header and the call control extensions.
`Alternatively, the response could contain a body with presence
`information, as shown in Figure 4.
`
`Epic Games Ex. 1029
`Page 136
`
`

`

`The presence format listed is just an example - text/presence is not
`
`J.Rosenberg,H.Schulzrinne
`8]
`
`Internet Draft
`1998
`
`[Page
`
`SIP Presence
`
`November 13,
`
`200 OK SIP/2.0
`Via: SIP/2.0/UDP proxy.bell-labs.com,
`SIP/2.0/UDP er1ang.bell-phone.com:5060
`To: pip:jdrosen@bel1 -1abs.com;tag=98asbd987
`From: pip:hgs@cs.columbia.edu
`Ca11 - ID: 098y0na08fy0h@l12.33.58.22
`Contact: mai1 to:jdrosen@bel1-labs.com;q=0.8
`Contact: im:jdrosen@cs,columbia.edu;q=0.7;mobi1ity=fixed
`Contact: sip: jdrosen@alum.mit.edu;q=0.6
`Content-Length: 0
`
`Figure 3: Example SUBSCRIBE response
`
`200 OK SIP/2.0
`Via: SIP/2.0/UDP proxy.bell-labs.com,
`SIP/2.0/UDP erlang.bei 1-phone.com:5060
`To: pip:jdrosen@bel1 - labs.com;tag=98asbd987
`From: pip:hgs@cs.columbia.edu
`Cal 1 - ID: 098y0na08fy0h@l12.33.58.22
`Content-Length: 58
`
`Epic Games Ex. 1029
`Page 137
`
`

`

`Content-Type: text/presence
`
`mail-address = jdrosen@bell-labs.com
`phone-address = 555-1212
`phone-status = busy
`im-address = jdrosen@cs.columbia.edu
`
`Figure 4: Response to SUBSCRIBE with body
`
`defined. Various new formats can be defined, or existing formats,
`such as the VCard XML format [7] can be used.
`
`4.2 Notification and Publication
`
`The publication component allows a publisher to inform the
`notification server about its updated contact and presence
`information. We believe that there are many possible ways in which
`publication can take place. For example, a system can be co-resident
`with a Network Access Server (NAS), and presence can be represented
`as simply logged in or logged out. In this case, there is no separate
`protocol for conveying publication of presence information. It is
`done as a natural consequence of logging into the server.
`
`].Rosenberg,H.Schulzrinne
`9]
`
`Internet Draft
`1998
`
`[Page
`
`SIP Presence
`
`November 13,
`
`Other mechanisms include SIP registrations, H.323 gatekeeper
`registrations, telnets, picking up the phone, sensors in the door (or
`in the chair) of someones office. All of these are valid means to
`convey some form of presence to the notification server.
`
`Epic Games Ex. 1029
`Page 138
`
`

`

`We propose that if an explicit publication means is needed, it should
`use the notification messages. This is because publication is really
`a form of notification, with the notification is between the
`publisher and the notification server. This is a natural extension of
`the serverless case, where the publisher would be responsible for
`sending the notification requests to the subscriber. It also makes
`simple notification servers easy. They can effectively proxy, without
`modification, a notification request from the subscriber. The only
`change needed is to modify the request URI and fork the request. This
`is a normal operation for a SIP server.
`
`The process of publication is supported through the NOTIFY method, a
`new method added to SIP for this purpose. A notification request is
`sent by a publisher, and targeted to the notification server just as
`a SIP register message is targeted to a registrar (there is no
`username). No additional header fields are needed to support
`publications and notifications through SIP.
`
`The mandatory headers are To, From, Call-ID, and CSeq. The To field
`is set the same way as in a SIP REGISTER message - it is the address
`of the entity whose information is being updated, NOT the target of
`the registration. The From field is the entity actually sending the
`notification (this need not be the same as the To field). The Cal 1-ID
`is the same as the one in the SUBSCRIBE which triggered it. Cseq is
`randomly chosen, but must be larger than the CSeq in a previous
`message from the server with the same Call-ID.
`
`As with the response to the SUBSCRIBE request, the NOTIFY request may
`either contain a payload which describes the current presence state
`of the user, or this information may be conveyed in the Contact
`headers. A presence server may need to translate any presence bodies
`if some of the subscribers don't understand the format used by the
`publisher. The entire state, not pieces of it, are always sent.
`
`The request URI of a publication contains just the address of the
`notification server. The notification server will’ fork the
`notification (after any appropriate modifications), and send copies
`to each of the subscribers by changing the request URI in each of the
`
`Epic Games Ex. 1029
`Page 139
`
`

`

`copies. The Request URI contains the value from the Contact header
`received in each registration.
`
`The Expires header may be used in notifications to indicate that the
`information has a finite lifetime.
`
`J.Rosenberg,H.Schulzrinne
`10]
`
`Internet Draft
`1998
`
`[Page
`
`SIP Presence
`
`November 13,
`
`The remaining request header fields have their standard meanings.
`Note that the Requires header is needed here as well.
`
`The response to a NOTIFY is a 200-class response if it has been
`received correctly. A 400-class response is returned if a subscriber
`receives a notification, but it had never subscribed to that user.
`
`An example notification sent from a publisher to its notification
`server is depicted in Figure 5.
`
`SIP/2.0 NOTIFY pip:dnrc.bei 1 - labs.com
`To: pip:jdrosen@be11 - labs.com
`From: pip:jdrosen@dnrc.be1 1 - labs.com
`Call-ID: 098n08ayfp@10.0.0.1
`CSeq: 0
`Via: SIP/2.0/UDP machine.dnrc.bell-labs.com
`Contact: sip:jdrosen@bel1-labs.com:5061;expires=3600
`
`Figure 5: Example NOTIFY request
`
`Epic Games Ex. 1029
`Page 140
`
`

`

`This