These actions require that metadata be passed to the
`appropriate gateways and resources in each network so that
`the call can be re-routed.
`One significant aspect of cross-system service handoff
`is the decision-making process. The process may include
`network-based handover and mobile device-based handoff
`decisions. The key is that the overall process is controlled
`by users and services.
`
`3.3 Customized Information Collection, Delivery and Dis­
`semination
`There are many cases where the infrastructure can be lever­
`aged to route information in a dynamic, timely fashion. For
`example, a salesperson who has multiple end devices or end
`devices with multiple network interfaces could receive im­
`mediate notification when someone tries to contact them or
`the salesperson could have an service agent monitoring the
`availability of a particular product, etc. When triggered by
`the appropriate condition, the agent would then contact the
`salesperson using the best possible mode, as specified by the
`salesperson.
`Another example is distributing the same information
`to multiple users on the same or different networks (e.?.,
`sending one message to users , with cellular phones, pagers,
`voicemail, E-mail, etc.). Consider being able to type a mes­
`sage and have it delivered to a list of users, where the list
`not only contains e-mail addresses, but also contains cellular
`phone numbers, office numbers, pager numbers, voice mail
`numbers, etc. and the infrastructure transparently converts
`the message to the appropriate format as selected by the re­
`cipient of the message. This service simplifies and optimizes
`information delivery both for senders and recipients.
`Sensor fusion is an example of information collection.
`Consider the problem of aggregating information from sen­
`sors in different networks (e.g., a passive IR detector con­
`nected to an IP network and a video camera connected to
`a digital cellular network). The infrastructure must collect
`and correlate information from very different types of de­
`vices. This problem is similar to the problem of personal
`information management for a user (e.g., voicemail, e-mail,
`pages, faxes, etc.), where the information has many different
`representations.
`
`Novel Ideas in the Iceberg Architecture
`4
`There are several novel aspects to the Iceberg architecture
`that distinguish it from previous research in this area. The
`architecture provides support for the following features across
`cascaded networks: a carefully structured architecture for
`services, service transformations (not just bit transforma­
`tions), and the ability to pass service- and entity-specific
`metadata across cascaded networks
`
`4.1 Structured Architecture for Services Across Cascaded
`Networks
`The Iceberg architecture addresses more than just one-to-
`one connections between networks [1, 2, 8]. The architec­
`ture includes the notion of cascaded networks, where there
`may be multiple paths between two networks, in addition to
`or in lieu of direct connections between the networks, and
`multiple places for services to execute within the networks.
`The architecture is not intended as a special-purpose or one-
`of architecture for interconnecting some existing networks,
`rather our intention is that the architecture is sufficiently
`
`broad enough that it can incorporate many existing and up­
`coming networks.
`The traditional view of a network core is that the core
`services and resources should not be exposed to end users (or
`should be exposed only in a tightly controlled static man­
`ner). In the Iceberg architecture, we take the opposite view
`and provide secure, authenticated mechanisms for allowing
`service- and entity-specific policies to be injected into the
`network infrastructure.
`Injecting code into the network is not something to be
`taken lightly, it requires support for secure execution and au­
`thentication of policies and entities. It also requires a careful
`structuring of the interfaces to resources the infrastructure.
`The Iceberg architecture gives entities control over the path
`that their data takes through the infrastructure and the re­
`sources that are used, but does not give them control over
`the flow of other entities’ data or resources. The Iceberg ar­
`chitecture supports network-specific resource management,
`authentication, policies, billing, etc. to allow such policies
`to be controlled and enforced.
`
`4.2 Not Just Bit Transformations, but Service Transfor­
`mation
`In addition to including more than just, one-to-one network
`interconnections, the Iceberg architecture is also more than
`just bit-level transformations and simple network routing.
`The Iceberg architecture addresses service transforma­
`tions which involve decision making about: what bit-level
`transformations to perform, where to perform the trans­
`formations, high-level transformations to address deficien­
`cies (e.g., in the networks, network interfaces, and bit-level
`transformations), and how to route data across multiple net­
`works, especially when there are multiple paths between net­
`works.
`Entities in the system are a key component of the archi­
`tecture, especially the use of contextual information about
`them: who they are, what services they are using, where
`they are, and the capabilities or limitations of the available
`end devices and networks. This information directly affects
`the choice and placement of bit-level transformations.
`Users may also have specific requirements (e.g., cost, de­
`livery latency, or QoS) for cross-network information. The
`network gateways and end devices may have a limited set
`of bit-level transformations, as such, it may be necessary to
`for end-devices, services, and network gateways to negotiate
`the particular bit-le.vel transformation to use. Furthermore,
`the negotiation process may take place across or involve cas­
`caded networks.
`Routing is another example of a function that cannot
`simply be considered on a one-to-one basis, instead routing
`must be considered as a cascaded network function. The
`locally optimal choice of routing may not be the globally
`optimal function. For example, consider a call being placed
`between a user using VoIP on a computer in San Francisco
`and GSM user London. Routing the call over IP links might
`be optimal in the local area case, but could introduce exces­
`sive jitter and delay in the wide area case.
`The Iceberg architecture is not trying to reinvent bit­
`level transformations or routing protocols. Instead, the ar­
`chitecture leverages off of existing services and management
`functionality in each network. Our concern is with the level
`of operation and scope of decision-rhaking.
`Many of networks are multi-modal, in that they can
`carry many different forms of information. This modality
`can be used as a benefit by cross-network coordination of
`
`Epic Games Ex. 1029
`Page 162
`
`

`

`where transformations should be located. However, reach­
`ing a global optimum in cascaded networks will require co­
`operation and communication between routing entities in
`multiple networks. Only in this manner, will it be possible
`to use high-level transformations, in addition to low-level
`transformations, to overcome the limitations of a given set
`of networks or their interfaces.
`Also, networks contain many of the resource needed by
`services, although not in an abstract manner. For exam­
`ple, all networks have some form of naming and authenti­
`cation. The Iceberg architecture unifies such mechanisms
`across the networks by providing an abstract naming and
`authentication mechanism that resolves to and relies upon
`network-specific mechanisms at the lowest level.
`
`4.3 Propagation of Service- and Entity-Specific Metadata
`Across Cascaded Networks
`As outlined earlier, service handoff requires the propaga­
`tion of service- and entity-specific metadata across cascaded
`networks. The information must be propagated to the com­
`putational resources in each network that are involved in
`carrying the data associated with the particular service.
`The Iceberg architecture provides these propagation paths
`by providing logically or physically separate bi-directional
`metadata and data paths.
`The Iceberg architecture provides infrastructure for spec­
`ifying metadata in the form of XML descriptions. These
`descriptions are used during the creation or modification of
`a path (e.g., during service handoff) between the requestor
`and requested service to choose which transcoders to use,
`where to place them, and how to route between them.
`
`5
`
`Related work
`
`5.1 Domain Naming Service
`The Internet’s Domain Naming Service (DNS) by itself is
`not an acceptable naming protocol for the Iceberg architec­
`ture. DNS’ name to address or information mappings are
`relatively static and limited amounts and types of informa­
`tion can be returned (e.g., objects can’t be returned).
`DNS only provides timeouts for controlling the caching
`of mappings in servers and clients. Servers have no way
`of dynamically flushing or changing cached mappings. For
`example, implementing call forwarding using DNS would fail
`to work properly for an indeterminate amount of time after
`a user changed the forwarding mapping.
`DNS supports one to many mappings, but does not spec­
`ify a policy of which mapping a particular client should
`prefer or use. Instead the choice is left up to clients who
`typically have inconsistent policies.
`Finally, DNS provides addresses, but does not specify
`the routes that should be used between hosts. Such infor­
`mation is managed by separate network routing protocols
`(e.g., OSPF, RIP, etc).
`
`5.2 Signaling System 7 (SS7)
`Signaling System 7 (SS7) is the internetworking protocol
`used in telephone systems (i.e., PSTN and digital cellular).
`SS7 provides a transport for building services with reliable
`message delivery and automatic failure recovery. SS7 en­
`ables telephone service providers to deploy many of the ser­
`vices discussed earlier in this paper. Such services, like dy­
`namic call forwarding and routing, are being used as a basis
`for other services, like dynamic forwarding of calls to 800
`
`numbers to local operators and local number portability, re­
`spectively.
`The question is: should SS7 be used as the internet­
`working protocol for the Iceberg architecture? We believe
`the answer is no, for several reasons. SS7 is a very heavy­
`weight solution and many services, like datagram delivery,
`do not require the overhead imposed by SS7. Also, SS7
`was designed for closed networks and has limited security
`and authentication support. Security and authentication
`are strong requirements for an architecture that allows user
`code to execute in the network core.
`The networking environment in Iceberg is very different
`from a traditional SS7 environment. The Iceberg architec­
`ture includes cascaded networks and routing and connectiv­
`ity change on a very dynamic basis, both of these architec­
`tural aspects are outside the domain of SS7.
`Ail of the negative aspects aside, SS7 has an important
`role in the Iceberg architecture. Interoperability between
`Iceberg and SS7 services and protocols is a requirement;
`as such, we will encapsulate SS7 services behind Iceberg
`services. This abstraction will serve to hide SS7’s complexity
`from Iceberg developers.
`
`5.3 Gateway Location Protocols
`Gateway location (e.g., for IP telephony [1, 6, 7]) is a re­
`quirement for the Iceberg architecture. However, our focus
`is on leveraging existing gateway location services as a com­
`ponent of a more abstract service discovery service.
`
`5.4 Service Transformation
`As with gateway location protocols, we intend to reuse ex­
`isting solutions, but add a layer of indirection. Entities
`specify that they want a particular service between two
`cross-network endpoints and the Iceberg architecture han­
`dles the construction of the path by relying upon network­
`specific service location and transformation protocols and a
`language-independent means of specifying service interfaces.
`
`6
`
`Design of the Iceberg Architecture
`
`The key principals in the Iceberg architecture are: entities
`and services. The task of the Iceberg architecture is to pro­
`vide services between entities located in different or the same
`networks.
`
`6.1 Entities
`Entities are users, callers and callees, or agents acting on
`each other’s behalf. Associated with each entity is a glob­
`ally unique, non-domain-specific Universal Name that pro­
`vides a mechanism for entities to refer to other entities in
`an abstract manner.
`
`6.2 Services Architecture
`Service information delivery requirements span a wide spec­
`trum from real-time, interactive requirements (e.g., a mul­
`timedia conversation), to information that can be deliv­
`ered asynchronously. In addition, some information may
`have non-real-time delay bounds on delivery (e.g., stock
`quotes). These delivery requirements are metadata that
`must be passed across network interfaces.
`
`Epic Games Ex. 1029
`Page 163
`
`

`

`Iceberg Access Point
`
`Callee: Anthony.D.Joseph.Berkeley.CA.US
`Caller: B.R.Badrinat.Berkeley.CA.US
`Interactive? Yes
`Network: PSTN
`
`System State
`
`IDNP Server
`
`Calllee’s
`Policy
`
`Callee’s Profile
`
`Office: 510-555-1212
`PCS: 510-555-1313
`IP: 10.0.0.1:444
`SMS: 510-555-1414
`E-mail: adj@cs.berkely.edu
`.____ _______ >
`Fax: 510-555-1515
`
`Figure 3: Iceberg Inter-Domain Naming Protocol example.
`
`An interactive service may be based upon an information
`delivery mechanism that is connection-based or datagram­
`based. The underlying implementation is hidden from t.he
`user.
`
`6.2.1 Service transformation
`Iceberg Access Points (IAPs) are gateways located in each
`network that provide the interconnections between networks.
`To allow networks to connect to one another, the IAPs per­
`form the link layer and bit transformations and they may
`also perform service-level transcoding. An IAP may be as
`simple as an H.323 gateway or it may be much more com­
`plicated, for example, providing metadata transport in ad­
`dition to data transport.
`The IAP may itself perform a data transcoding operation
`that has been requested by a service or it may choose to
`offload the operation to local computational resources in the
`network.
`The IAP is usually the point where cross-domain (network­
`specific) signaling information is collected from an incoming
`network and potentially from the outgoing network. Such
`information includes authentication and identification infor­
`mation (e.g., a PSTN caller's telephone number).
`
`6.2.2 Cross-domain name resolution
`An important requirement, for service handoff is cross-domain
`name resolution, which allows users to provide a single glob­
`ally unique name (Universal Name) and have it dynami­
`cally, resolved in any network to a domain-specific name
`using entity- or service-specific policies. Name resolution is
`
`handled by servers using the Iceberg Inter-Domain Naming
`Protocol (IDNP).
`Iceberg Inter-Domain Naming Protocol (IDNP) servers
`map Universal Names to domain-specific names using three
`information elements: an entity profile that specifies the
`entity’s domain-specific names, system state (for reachabil­
`ity information about an entity), and the entity’s policy for
`mapping Universal Names to domain-specific names.
`The entity profile is a list of domain-specific names for
`each of the end devices used by the entity. The entity profile
`changes on the order of weeks to months — basically when
`the entity acquires a new device.
`System state or reachability information is domain-specific
`information about each domain-specific name. For exam­
`ple, for a PCS or digital cellular phone it might include
`cost, whether the phone is registered with a network (t.e.,
`reachable). While for a wireless LAN, it might include reg­
`istration information and currently available QoS and band­
`width. System state usually varies on the order of minutes
`or hours, depending upon the entity’s activities.
`The entity’s policy is the key difference between the Ice­
`berg architecture and systems like the PSTN-based call rout­
`ing approaches. The policy gives entities the ability to pro­
`vide code that dynamically evaluates several variables and
`makes routing decisions. The policy is used once at call
`setup and again if system state information changes. Poli­
`cies usually vary on the order of days to weeks.
`Typical variables that are used in decision-making are:
`what is the caller’s network, what is the cost for using each of
`the callee’s available end devices, what QoS or bandwidth
`is available, who is the caller, is the service interactive or
`non-interactive, and any other entity- or service-specific in­
`formation.
`
`Epic Games Ex. 1029
`Page 164
`
`

`

`Labs - R.e.search, NOS DAV 1998, July 1998.
`|2) Sandesh Goel, Partho Mishra, Huzur Saran, and Cormac
`Sreenan. Design and evaluation of a platform for mobile
`packet telephony. In AT&T Labs - Research, NOSDAV
`1998, July 1998.
`[3] David J. Goodman. Wireless Personal Communication
`Systems. Addison-Wesley Longman, Inc., Berkeley, CA,
`1997.
`[4] Rajan Kuruppillai, Main Dontamsetti, and Fil J.
`Cosentino. WireZe.s.5 PCS. McGraw-Hill, San Francisco,
`CA, 1997.
`[5] Charles E. Perkins, Mobile IP: Design Principles and
`Practices. Addison-Wesley Longman, Inc., Berkeley, CA,
`1997.
`[6] Jonathan Rosenberg and Henning Schulzrinne. A com­
`parison of SIP and H.323 for internet telephony. In Bell
`Laboratories, Lucent Technologies / Columbia Univer­
`sity, NOSDAV 1998, July 1998.
`[7] Jonathan Rosenberg and Henning Schulzrinne. Internet
`telephony gateway location. In Conference on Computer
`Communications (IEEE Infocom), San Francisco, Cali­
`fornia, March/April 1998.
`[8] Henning Schulzrinne and Jonathan Rosenberg. Internet
`telephony: Architecture and protocols. Computer Net­
`works and ISDN Systems, March/April 1998.
`
`Entity-specific police.« provide dynamic control over how
`an IDNP server maps Universal Names to specific domain­
`specific names. Figure 3 provides an example of a mapping.
`Privacy is an important consideration; as such, the expo­
`sure of domain-specific names is under the control of entities.
`An entity's policy can specify that a domain-specific name
`should be returned to a caller or it can specify that the name
`should be hidden, in which case, the IDNP server informs
`the IAP that it should forward the call or message to the
`domain-specific name.
`The IDNP executes on servers located in each network
`using portals provided by the network into the network’s
`IDNP servers. For example, a special telephone number
`would be used in PSTN and digital cellular networks.
`Information replication and caching are open questions
`in our design. Clearly, both are needed for scalability and
`reduced setup latency. We are experimenting with a num­
`ber of different strategies. However, the maximum tolerable
`propagation delay is basically a function of the expected rate
`of change of information and the frequency of service con­
`nections being established to a particular universal name.
`The rate of change for the information depends upon
`the information. Entity profiles change on the slowest, time
`scale, followed by entity policies. System state or domain­
`specific reachability, however, may change very rapidly over
`the course of a few minutes or hours, as a function of user
`and terminal mobility.
`IDNP servers cache information elements so that they
`can support low latency decision making. This means that
`the information may be replicated and cached at multiple
`IDNP servers and changes will need to be propagated to
`those servers in a timely and secure manner.
`Wherever possible duplication of effort by IDNP will be
`avoided. In particular, name resolution will leverage off of
`each network’s existing infrastructure. This means, for ex­
`ample, that the profile should contain a device’s mobile IP
`home address rather than its current wireless IP address.
`
`7 Summary
`
`In this paper, we have described an architecture for provid­
`ing services over cascaded networks. The need for service
`handoff across cascaded networks arises from the fact that
`users tend to carry multiple devices each of which may have
`multiple network interfaces; thus, the best network to reach
`a user may depend upon several factors.
`The design of services over these networks requires a de­
`tailed consideration of the problems of interoperability over
`cascaded networks. We provide several examples of different
`classes of services over cascaded networks and discuss how
`the separation of control metadata from data helps with the
`construction of these services.
`The Iceberg project is deploying a large-scale testbed
`consisting of GSM digital cellular, wired and wireless IP,
`and PSTN networks and we are beginning to experiment
`with cross-domain services. The Iceberg testbed and the
`services we develop on top of it will help validate the re­
`search, both through the demonstration of ease of service
`construction and deployment, and through the utility pro­
`vided to students and the UC Berkeley community by such
`services and infrastructure.
`
`References
`
`[1) N. Anerousis et al. Architecture for signaling, directory
`services and transport, for packet telephony. In AT&T
`
`Epic Games Ex. 1029
`Page 165
`
`

`

`INTERNET-DRAFT
`
`Dusseault
`
`Expires: August 1998
`Corporation
`
`Calsyn &
`
`Microsoft
`
`Presence Information Protocol Requirements
`draft-dusseau11- pipr-00.txt
`
`1.
`
`Status of this Memo
`
`(IETF),
`
`This document is an Internet-Draft. Internet-Drafts are
`working documents of the Internet Engineering Task Force
`
`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 -
`Draf t s as reference material or to ci te them other than as "work
`in progress."
`
`To learn the current status of any Internet-Draft, please check
`the "lid-abstracts.txt" listing contained in the
`Internet-Draf t s
`Shadow Directories on ds.internic.net (US East Coast),
`nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
`munnari.oz.au (Pacific Rim).
`
`2. Abstract
`
`Online users have demonstrated a desire to know instantly
`
`whether
`
`Epic Games Ex. 1029
`Page 166
`
`

`

`These
`
`usual ly
`
`another individual is online, to be notified when another
`individual arrives online, and to send instant messages.
`
`applications currently use independent, non-standard and
`
`non-interoperable protocols. The goal is to define a standard
`protocol so that independently written client and server
`implementations can participate in a global network of
`
`''online''
`
`users.
`
`This draft outlines requirements for a Presence Information
`Protocol to support these applications.
`
`comments
`
`Distribution of this document is unlimited. Please send
`
`to the RVP discussion list at rvp@iastate.edu, which may be
`joined by sending a message wi th subj ect ''subscribe1' to rvp-
`request@iastate.edu. Archives of past messages are available.
`Send the single word help to rvp-request@iastate.edu for
`
`more
`
`information.
`
`Calsyn & Dusseault
`
`[Page 1]
`
`Epic Games Ex. 1029
`Page 167
`
`

`

`INTERNET-DRAFT
`
`PIP Requirements
`
`Feb.
`
`9, 1998
`
`3. Contents
`
`1. Status of this
`Memo..........................................................................1
`2.
`Abstract...............................................................................................1
`3.
`Contents..............................................................................................2
`4.
`Int roduct ion......................................................................................3
`4.1. Purpose of a Presence Information
`Protocol......................3
`4.2. Desired
`Characteristics........................................................4
`4.3.
`Def ini t ions............................................................................... 4
`5. Detailed
`Requirements...................................................................... 5
`5.1. Security
`Requirements............................................................5
`5.1.1.
`Confidential i ty.............................................................. 5
`5.1.2.
`Privacy............................................................................ 5
`5.1.3.
`Authentication............................................................... 6
`5.2. Addressing
`Requirements.........................................................6
`5.2.1. Naming
`Format.................................................................. 6
`5.2.2. Locating a
`Server...........................................................7
`
`Epic Games Ex. 1029
`Page 168
`
`

`

`5.3. Container Schema
`Requi rements............................................ 7
`5.3.1. User Schema
`Requi rements............................................ 7
`5.3.2. Group Schema
`Requirements............................................7
`5.4. Other
`Requi rements..................................................................7
`5.4.1. Control over peer-to-peer
`messaging.........................7
`5.4.2. Nature of Instant
`Messaging....................................8
`5.4.3. Media
`Types......................................................................8
`5.4.4. Location
`Independence..................................................8
`5.4.5. One to many or group
`messaging..................................8
`6.
`Goals....................................................................................................9
`6.1.
`Scalable.....................................................................................9
`6.2.
`Flexible....................................................................................9
`6.3.
`Efficient..................................................................................9
`7. Protocol Implementation
`Issues.................................................. 10
`7.1. Transport-Protocol
`Neut ral................................................ 10
`7.2.
`Text -based............................................................................... 10
`7.3. Supports
`Versioning...............................................................10
`7.4. Minimal
`State..........................................................................10
`7.5.
`Encryption............................................................................... 10
`
`Epic Games Ex. 1029
`Page 169
`
`

`

`7.6.
`Au then t icat ion........................................................................10
`7.7.
`Fi rewal Is................................................................................ 11
`7.8. Content
`types..........................................................................11
`8.
`Non-Goals...........................................................................................11
`8.1. Presence Information and
`Ema i 1..........................................11
`8.2. Presence Information and
`LDAP........................................... 12
`8.3. Peer-to-peer vs.
`cl ient - to-server.................................... 12
`9. Discussion
`Group..............................................................................12
`10.
`REFERENCES.........................................................................................12
`11. Authors’
`Addresses..........................................................................12
`
`Calsyn & Dusseault
`
`[Page 2]
`
`INTERNET-DRAFT
`
`PIP Requirements
`
`Feb.
`
`9, 1998
`
`Epic Games Ex. 1029
`Page 170
`
`

`

`4.
`
`Introduction
`
`4.1. Purpose of a Presence Information Protocol
`
`Users want to know instantly when a friend or colleague logs
`
`and to be able to send this acquaintance a quick message. The
`desired functionality includes both the ability to subscribe
`
`instant notifications of remote events, such as a friend
`
`on, and the ability to send instant messages to others.
`
`Also note that in early discussions on the problem there has
`
`on,
`
`to
`
`logging
`
`been
`
`agreement that a client-only solution is not feasible. Users
`wish to be notified when another user comes online. When the
`target user is offline, there must be another entity
`responsible
`for taking subscription requests. The protocol must specify
`
`how:
`
`@ a client requests or subscribes to dynamic user status
`information,
`
`@ a server responds to queries and subscriptions,
`
`@ a client sends instant messages, and
`
`@ a server forwards instant messages to recipients.
`
`Besides being able to subscribe to on 1 ine status, users may also
`be able to subscribe to other propert ies of users or propert ies
`of non-user objects.
`
`Users and administrators must be able to set access control
`
`Epic Games Ex. 1029
`Page 171
`
`

`

`a
`
`be
`
`levels on queryable objects and properties.
`
`Interest-based messaging, in which a user sends a message to
`
`group of individuals which share some characteristics, should
`
`supported by the protocol. This group of individuals or
`aggregate entity may be handled by the server much like email
`distribution lists.
`
`Examples of existing presence information systems include:
`
`@ Act iverse s Ding!
`
`@ AOL s Instant Messenger
`
`@ IChat s IChat Pager
`
`@ Flash Communications s Flash Communicator
`
`@ Mi rabi1i s s ICQ
`
`@ MSN s Friends Online
`
`@ PeopleLink s People Link
`
`Calsyn & Dusseault
`
`[Page 3]
`
`INTERNET-DRAFT
`
`PIP Requirements
`
`Feb.
`
`9, 1998
`
`Epic Games Ex. 1029
`Page 172
`
`

`

`a
`
`a
`
`4.2. Desired Characteristics
`
`This section briefly outlines the desired characteristics of
`
`presence information system. Requirements and goals of the
`protocol are discussed in more detail in sections 5 and 6.
`
`Protocol Characteristics:
`
`1. Can scale to support number of users on internet within
`foreseeable future
`
`2. Provides rich extensibility
`
`3. Globally unique human-readable address can be assigned to
`
`user without consulting a central authority
`
`4. Server is not required to store messages long-term
`
`User Features:
`
`5. Standard way to find the address of a user
`
`6. Standard way to see if a user is online
`
`7. Supports 1-to-l, 1-to-many and interest-classified
`
`messaging
`
`8. Supports acknowledgements of received instant messages
`
`9. Supports a subscription and notification model
`
`10. Responsive: quick notifications of status changes
`
`Epic Games Ex. 1029
`Page 173
`
`

`

`11. Provides maximum flexibility for message content
`
`12. Supports media negotiation and session initiation: users
`
`can
`
`peer-to-peer)
`
`switch to another application (server-based or
`
`13. The target of subscriptions can list who initiated those
`subscript ions
`
`14. Supports non-humans on either end (or both) of a
`subscription,
`
`query or message
`
`15. Supports location independence
`
`Secur i ty Features:
`
`16. Supports reverse-lookup to find out who has asked for
`informat ion
`
`17. Provides endpoint to endpoint security
`
`18. Support firewal1-friendly deployment
`
`to
`
`19. Supports access control, at minimum who can read or write
`
`any object, object property, or list of objects.
`
`20. Allows users to maintain privacy by blocking others
`
`4.3. Definitions
`
`This specification uses a number of terms to refer to the roles
`of participants and the kinds of messages passed between them.
`
`Epic Games Ex. 1029
`Page 174
`
`

`

`Client: An application program that establishes connections to
`the server for the purpose of registering to be online or
`
`Calsyn & Dusseault
`
`[Page 4]
`
`INTERNET-DRAFT
`Feb. 9, 1998
`
`PIP Requi rements
`
`requesting information on another client or group. Clients
`
`or may not interact directly with a human user.
`
`Server: A program that accepts connections from clients and
`
`is responsible for maintaining online/off1ine state.
`
`Request: A request is a subscription to a property or a query
`for a property value, or the setting of the property.
`
`Response: A response is a message from a server to a client
`
`has made a query or who has an active subscription.
`
`Subscription: A subscription is a request from a client to be
`notified when a property changes or to receive all instant
`messages on a channel. Commonly, a subscription from user A
`
`user B will be for the purpose of notifying user A when user
`
`may
`
`that
`
`who
`
`to
`
`B's
`
`Epic Games Ex. 1029
`Page 175
`
`

`

`Status changes to "online".
`
`Property: Presence information and other information should
`accessed as properties, or name/value pairs.
`
`Property Container: A property container can represent a
`
`world object which has properties queryable through the
`
`real -
`
`Presence
`
`Information Protocol. -
`
`5. Detai led Requirements
`
`5.1. Security Requirements
`
`5.1.1.
`
`Confidentiality
`
`Users MUST be able to protect information about themselves.
`
`requirement should be considered met by a system which allows
`users to set fine-grained access control levels on client or
`server held objects and properties.
`
`5.1.2.
`
`Privacy
`
`Access