`
`[Search] [txt|html|pdf|bibtex] [Tracker]
`From: draft-ietf-impp-reqts-04
`Network Working Group
`Request for Comments: 2779
`Category: Informational
`
`[WG1 rEmail] [Diff1] rpiff21 [Nits]
`Informational
`M. Day
`Lotus
`S. Aggarwal
`Microsoft
`G. Mohr
`Activerse
`J. Vincent
`Into Networks
`February 2000
`
`Instant Messaging / Presence Protocol Requirements
`Status of this Memo
`This memo provides information for the Internet community. It does
`not specify an Internet standard of any kind. Distribution of this
`memo is unlimited.
`Copyright Notice
`Copyright (C) The Internet Society (2000) . All Rights Reserved.
`Abstract
`Presence and Instant Messaging have recently emerged as a new medium
`of communications over the Internet. Presence is a means for
`finding, retrieving, and subscribing to changes in the presence
`information (e.g. "online" or "offline") of other users. Instant
`messaging is a means for sending small, simple messages that are
`delivered immediately to online users.
`Applications of presence and instant messaging currently use
`independent, non-standard and non-interoperable protocols developed
`by various vendors. The goal of the Instant Messaging and Presence
`Protocol (IMPP) Working Group is to define a standard protocol so
`that independently developed applications of instant messaging and/or
`presence can interoperate across the Internet. This document defines
`a minimal set of requirements that IMPP must meet.
`
`Day, et al.
`
`Informational
`
`[Page 1]
`
`https://datatracker.ietf.org/doc/html/rfc2779[l 1/11/2021 1:11:18 PM]
`
`Epic Games Ex. 1035
`Page 1
`
`
`
`rfc2779
`
`RFC 2779
`
`Instant Messaging/Presence Protocol
`
`February 2000
`
`Table of Contents
`1.. Terminology.................................................... 3.
`2. Shared Requirements............................................ 4
`2.1. Namespace and Administration............................... 5
`2.2. Scalability................................................. 5
`2.3. Access Control.............................................. 6
`2.4. Network Topology............................................ 6
`2.5. Message Encryption and Authentication...................... 7.
`3. Additional Requirements for PRESENCE INFORMATION.............. J_
`3.1. Common Presence Format..................................... 7
`3.2. Presence Lookup and Notification........................... 8
`3.3. Presence Caching and Replication........................... 8
`3.4. Performance................................................. 9.
`4.. Additional Requirements for INSTANT MESSAGES.................. 2.
`4.1. Common Message Format....................................... 9
`4.2. Reliability................................................. 10
`4.3. Performance................................................. 10
`4.4. Presence Format............................................. 10
`1. Security Considerations....................................... 11
`5.1. Requirements related to SUBSCRIPTIONS...................... 11
`5.2. Requirements related to NOTIFICATION....................... 12
`5.3. Requirements related to receiving a NOTIFICATION.......... 13
`5.4. Requirements related to INSTANT MESSAGES................... 13
`.6. References..................................................... 14
`7. Authors' Addresses............................................. 15
`1. Appendix: Security Expectations and Deriving Requirements.... 16
`8.1. Presence Information........................................ 16
`8.1.1. Subscription............................................. 16
`8.1.2. Publication.............................................. 19
`8.1.3. Publication for Notification............................ 19
`8.1.4. Receiving a Notification................................ 20
`8.2. Instant Messaging........................................... 21
`8.2.1. Named Instant Messaging................................. 21
`8.2.2. Anonymous Instant Messaging............................. 23
`8.2.3. Administrator Expectations.............................. 2 4
`Full Copyright Statement.......................................... 2 6
`
`Day, et al.
`
`Informational
`
`[Page 2]
`
`https://datatracker.ietf.org/doc/html/rfc2779[l 1/11/2021 1:11:18 PM]
`
`Epic Games Ex. 1035
`Page 2
`
`
`
`rfc2779
`
`RFC 2779
`
`Instant Messaging/Presence Protocol
`
`February 2000
`
`1. Terminology
`The following terms are defined in [RFC 27781 and are used with those
`definitions in this document:
`ACCESS RULES
`CLOSED
`FETCHER
`INSTANT INBOX
`INSTANT MESSAGE
`NOTIFICATION
`OPEN
`POLLER
`PRESENCE INFORMATION
`PRESENCE SERVICE
`PRESENTITY
`PRINCIPAL
`PROXY
`SERVER
`STATUS
`SUBSCRIBER
`SUBSCRIPTION
`WATCHER
`The terms MUST and SHOULD are used in the following sense while
`specifying reguirements:
`MUST: A proposed solution will have to meet this reguirement.
`SHOULD: A proposed solution may choose not to meet this reguirement.
`Note that this usage of MUST and SHOULD differs from that of RFC
`2119 .
`Additionally, the following terms are used in this document and
`defined here:
`ADMINISTRATOR: A PRINCIPAL with authority over local computer and
`network resources, who manages local DOMAINS or FIREWALLS. For
`security and other purposes, an ADMINISTRATOR often needs or wants to
`impose restrictions on network usage based on traffic type, content,
`volume, or endpoints. A PRINCIPAL'S ADMINISTRATOR has authority over
`some or all of that PRINCIPAL'S computer and network resources.
`DOMAIN: A portion of a NAMESPACE.
`ENTITY: Any of PRESENTITY, SUBSCRIBER, FETCHER, POLLER, or WATCHER
`(all defined in (RFC 2 7781) .
`
`Day, et al.
`
`Informational
`
`[Page 3]
`
`https://datatracker.ietf.org/doc/html/rfc2779[l 1/11/2021 1:11:18 PM]
`
`Epic Games Ex. 1035
`Page 3
`
`
`
`rfc2779
`
`RFC 2779
`
`Instant Messaging/Presence Protocol
`
`February 2000
`
`FIREWALL: A point of administrative control over connectivity.
`Depending on the policies being enforced, parties may need to take
`unusual measures to establish communications through the FIREWALL.
`IDENTIFIER: A means of indicating a point of contact, intended for
`public use such as on a business card. Telephone numbers, email
`addresses, and typical home page URLs are all examples of IDENTIFIERS
`in other systems. Numeric IP addresses like 10.0.0.26 are not, and
`neither are URLs containing numerous CGI parameters or long arbitrary
`identifiers.
`INTENDED RECIPIENT: The PRINCIPAL to whom the sender of an INSTANT
`MESSAGE is sending it.
`NAMESPACE: The system that maps from a name of an ENTITY to the
`concrete implementation of that ENTITY. A NAMESPACE may be composed
`of a number of distinct DOMAINS.
`OUT OF CONTACT: A situation in which some ENTITY and the PRESENCE
`SERVICE cannot communicate.
`SUCCESSFUL DELIVERY: A situation in which an INSTANT MESSAGE was
`transmitted to an INSTANT INBOX for the INTENDED RECIPIENT, and the
`INSTANT INBOX acknowledged its receipt. SUCCESSFUL DELIVERY usually
`also implies that an INBOX USER AGENT has handled the message in a
`way chosen by the PRINCIPAL. However, SUCCESSFUL DELIVERY does not
`imply that the message was actually seen by that PRINCIPAL.
`2. Shared Requirements
`This section describes non-security reguirements that are common to
`both an PRESENCE SERVICE and an INSTANT MESSAGE SERVICE. Section 6
`describes reguirements specific to a PRESENCE SERVICE, while Section
`7 describes reguirements specific to an INSTANT MESSAGE SERVICE.
`Section 8 describes security considerations. The reader should note
`that Section 11 is an appendix that provides historical context and
`aids in tracing the origins of reguirements in Section 8. Section 11
`is not, however, a statement of current IMPP reguirements.
`It is expected that Presence and Instant Messaging services will be
`particularly valuable to users over mobile IP wireless access
`devices. Indeed the number of devices connected to the Internet via
`wireless means is expected to grow substantially in the coming years.
`It is not reasonable to assume that separate protocols will be
`available for the wireless portions of the Internet. In addition, we
`note that wireless infrastructure is maturing rapidly; the work
`undertaken by this group should take into account the expected state
`of the maturity of the technology in the time-frame in which the
`
`Day, et al.
`
`Informational
`
`[Page 4]
`
`https://datatracker.ietf.org/doc/html/rfc2779[l 1/11/2021 1:11:18 PM]
`
`Epic Games Ex. 1035
`Page 4
`
`
`
`rfc2779
`
`RFC 2779
`
`Instant Messaging/Presence Protocol
`
`February 2000
`
`Presence and Instant Messaging protocols are expected to be deployed.
`To this end, the protocols designed by this Working Group must be
`suitable for operation in a context typically associated with mobile
`wireless access devices, viz. high latency, low bandwidth and
`possibly intermittent connectivity (which lead to a desire to
`minimize round-trip delays) , modest computing power, battery
`constraints, small displays, etc. In particular, the protocols must
`be designed to be reasonably efficient for small payloads.
`2.1. Namespace and Administration
`2.1.1. The protocols MUST allow a PRESENCE SERVICE to be available
`independent of whether an INSTANT MESSAGE SERVICE is available, and
`vice-versa.
`2.1.2. The protocols must not assume that an INSTANT INBOX is
`necessarily reached by the same IDENTIFIER as that of a PRESENTITY.
`Specifically, the protocols must assume that some INSTANT INBOXes may
`have no associated PRESENTITIES, and vice versa.
`2.1.3. The protocols MUST also allow an INSTANT INBOX to be reached
`via the same IDENTIFIER as the IDENTIFIER of some PRESENTITY.
`2.1.4. The administration and naming of ENTITIES within a given
`DOMAIN MUST be able to operate independently of actions in any other
`DOMAIN.
`2.1.5. The protocol MUST allow for an arbitrary number of DOMAINS
`within the NAMESPACE.
`2.2. Scalability
`2.2.1. It MUST be possible for ENTITIES in one DOMAIN to interoperate
`with ENTITIES in another DOMAIN, without the DOMAINS having
`previously been aware of each other.
`The protocol MUST be capable of meeting its other functional and
`performance reguirements even when
`-- (2.2.2) there are millions of ENTITIES within a single DOMAIN.
`-- (2.2.3) there are millions of DOMAINS within the single
`NAMESPACE.
`
`Day, et al.
`
`Informational
`
`[Page 5]
`
`https://datatracker.ietf.org/doc/html/rfc2779[l 1/11/2021 1:11:18 PM]
`
`Epic Games Ex. 1035
`Page 5
`
`
`
`rfc2779
`
`RFC 2779
`
`Instant Messaging/Presence Protocol
`
`February 2000
`
`-- (2.2.4) every single SUBSCRIBER has SUBSCRIPTIONS to hundreds
`of PRESENTITIES.
`-- (2.2.5) hundreds of distinct SUBSCRIBERS have SUBSCRIPTIONS to
`a single PRESENTITY.
`-- (2.2.6) every single SUBSCRIBER has SUBSCRIPTIONS to
`PRESENTITIES in hundreds of distinct DOMAINS.
`These are protocol design goals; implementations may choose to place
`lower limits.
`2.3. Access Control
`The PRINCIPAL controlling a PRESENTITY MUST be able to control
`-- (2.3.1) which WATCHERS can observe that PRESENTITY's PRESENCE
`INFORMATION.
`-- (2.3.2) which WATCHERS can have SUBSCRIPTIONS to that
`PRESENTITY's PRESENCE INFORMATION.
`-- (2.3.3) what PRESENCE INFORMATION a particular WATCHER will see
`for that PRESENTITY, regardless of whether the WATCHER gets it
`by fetching or NOTIFICATION.
`-- (2.3.4) which other PRINCIPALS, if any, can update the PRESENCE
`INFORMATION of that PRESENTITY.
`The PRINCIPAL controlling an INSTANT INBOX MUST be able to control
`-- (2.3.5) which other PRINCIPALS, if any, can send INSTANT
`MESSAGES to that INSTANT INBOX.
`-- (2.3.6) which other PRINCIPALS, if any, can read INSTANT
`MESSAGES from that INSTANT INBOX.
`2.3.7. Access control MUST be independent of presence: the PRESENCE
`SERVICE MUST be able to make access control decisions even when the
`PRESENTITY is OUT OF CONTACT.
`2.4. Network Topology
`Note that intermediaries such as PROXIES may be necessitated between
`IP and non-IP networks, and by an end-user's desire to provide
`anonymity and hide their IP address.
`
`Day, et al.
`
`Informational
`
`[Page 6]
`
`https://datatracker.ietf.org/doc/html/rfc2779[l 1/11/2021 1:11:18 PM]
`
`Epic Games Ex. 1035
`Page 6
`
`
`
`rfc2779
`
`RFC 2779
`
`Instant Messaging/Presence Protocol
`
`February 2000
`
`2.4.1. The protocol MUST allow the creation of a SUBSCRIPTION both
`directly and via intermediaries, such as PROXIES.
`2.4.2. The protocol MUST allow the sending of a NOTIFICATION both
`directly and via intermediaries, such as PROXIES.
`2.4.3. The protocol MUST allow the sending of an INSTANT MESSAGE both
`directly and via intermediaries, such as PROXIES.
`2.4.4. The protocol proxying facilities and transport practices MUST
`allow ADMINISTRATORS ways to enable and disable protocol activity
`through existing and commonly-deployed FIREWALLS. The protocol MUST
`specify how it can be effectively filtered by such FIREWALLS.
`2.5. Message Encryption and Authentication
`2.5.1. The protocol MUST provide means to ensure confidence that a
`received message (NOTIFICATION or INSTANT MESSAGE) has not been
`corrupted or tampered with.
`2.5.2. The protocol MUST provide means to ensure confidence that a
`received message (NOTIFICATION or INSTANT MESSAGE) has not been
`recorded and played back by an adversary.
`2.5.3. The protocol MUST provide means to ensure that a sent message
`(NOTIFICATION or INSTANT MESSAGE) is only readable by ENTITIES that
`the sender allows.
`2.5.4. The protocol MUST allow any client to use the means to ensure
`non-corruption, non-playback, and privacy, but the protocol MUST NOT
`reguire that all clients use these means at all times.
`3. Additional Requirements for PRESENCE INFORMATION
`The requirements in section 6 are applicable only to PRESENCE
`INFORMATION and not to INSTANT MESSAGES. Additional constraints on
`PRESENCE INFORMATION in a system supporting INSTANT MESSAGES appear
`in Section 7.4.
`3.1. Common Presence Format
`3.1.1. All ENTITIES MUST produce and consume at least a common base
`format for PRESENCE INFORMATION.
`3.1.2. The common presence format MUST include a means to uniquely
`identify the PRESENTITY whose PRESENCE INFORMATION is reported.
`
`Day, et al.
`
`Informational
`
`[Page 7]
`
`https://datatracker.ietf.org/doc/html/rfc2779[l 1/11/2021 1:11:18 PM]
`
`Epic Games Ex. 1035
`Page 7
`
`
`
`rfc2779
`
`RFC 2779
`
`Instant Messaging/Presence Protocol
`
`February 2000
`
`3.1.3. The common presence format MUST include a means to encapsulate
`contact information for the PRESENTITY's PRINCIPAL (if applicable),
`such as email address, telephone number, postal address, or the like.
`3.1.4. There MUST be a means of extending the common presence format
`to represent additional information not included in the common
`format, without undermining or rendering invalid the fields of the
`common format.
`working group must define the extension and registration
`3.1.5. The
`for presence information schema, including new STATUS
`mechanisms
`and new forms for OTHER PRESENCE MARKUP.
`conditions
`3.1.6. The presence format SHOULD be based on IETF standards such as
`vCard (RFC 24261 if possible.
`3.2. Presence Lookup and Notification
`3.2.1. A FETCHER MUST be able to fetch a PRESENTITY's PRESENCE
`INFORMATION even when the PRESENTITY is OUT OF CONTACT.
`3.2.2. A SUBSCRIBER MUST be able to reguest a SUBSCRIPTION to a
`PRESENTITY's PRESENCE INFORMATION, even when the PRESENTITY is OUT OF
`CONTACT.
`3.2.3. If the PRESENCE SERVICE has SUBSCRIPTIONS for a PRESENTITY's
`PRESENCE INFORMATION, and that PRESENCE INFORMATION changes, the
`PRESENCE SERVICE MUST deliver a NOTIFICATION to each SUBSCRIBER,
`unless prevented by the PRESENTITY's ACCESS RULES.
`3.2.4. The protocol MUST provide a mechanism for detecting when a
`PRESENTITY or SUBSCRIBER has gone OUT OF CONTACT.
`3.2.5. The protocol MUST NOT depend on a PRESENTITY or SUBSCRIBER
`gracefully telling the service that it will no longer be in
`communication, since a PRESENTITY or SUBSCRIBER may go OUT OF CONTACT
`due to unanticipated failures.
`3.3. Presence Caching and Replication
`3.3.1. The protocol MUST include mechanisms to allow PRESENCE
`INFORMATION to be cached.
`3.3.2. The protocol MUST include mechanisms to allow cached PRESENCE
`INFORMATION to be updated when the master copy changes.
`
`Day, et al.
`
`Informational
`
`[Page 8]
`
`https://datatracker.ietf.org/doc/html/rfc2779[l 1/11/2021 1:11:18 PM]
`
`Epic Games Ex. 1035
`Page 8
`
`
`
`rfc2779
`
`RFC 2779
`
`Instant Messaging/Presence Protocol
`
`February 2000
`
`3.3.3 The protocol caching facilities MUST NOT circumvent established
`ACCESS RULES or restrict choice of authentication/encryption
`mechanisms.
`3.4 Performance
`3.4.1 When a PRESENTITY changes its PRESENCE INFORMATION, any
`SUBSCRIBER to that information MUST be notified of the changed
`information rapidly, except when such notification is entirely
`prevented by ACCESS RULES. This reguirement is met if each
`SUBSCRIBER'S NOTIFICATION is transported as rapidly as an INSTANT
`MESSAGE would be transported to an INSTANT INBOX.
`4. Additional Requirements for INSTANT MESSAGES
`The reguirements in section 4 are applicable only to INSTANT MESSAGES
`and not to PRESENCE INFORMATION, with the exception of Section 4.4.
`Section 4.4 describes constraints on PRESENCE INFORMATION that are
`relevant only to systems that support both INSTANT MESSAGES and
`PRESENCE INFORMATION.
`4.1. Common Message Format
`4.1.1. All ENTITIES sending and receiving INSTANT MESSAGES MUST
`implement at least a common base format for INSTANT MESSAGES.
`4.1.2. The common base format for an INSTANT MESSAGE MUST identify
`the sender and intended recipient.
`4.1.3. The common message format MUST include a return address for
`the receiver to reply to the sender with another INSTANT MESSAGE.
`4.1.4. The common message format SHOULD include standard forms of
`addresses or contact means for media other than INSTANT MESSAGES,
`such as telephone numbers or email addresses.
`4.1.5. The common message format MUST permit the encoding and
`identification of the message payload to allow for non-ASCII or
`encrypted content.
`4.1.6. The protocol must reflect best current practices related to
`internationalization.
`4.1.7. The protocol must reflect best current practices related to
`accessibility.
`
`Day, et al.
`
`Informational
`
`[Page 9]
`
`https://datatracker.ietf.org/doc/html/rfc2779[l 1/11/2021 1:11:18 PM]
`
`Epic Games Ex. 1035
`Page 9
`
`
`
`rfc2779
`
`RFC 2779
`
`Instant Messaging/Presence Protocol
`
`February 2000
`
`4.1.8. The working group MUST define the extension and registration
`mechanisms for the message format, including new fields and new
`schemes for INSTANT INBOX ADDRESSES.
`4.1.9. The working group MUST determine whether the common message
`format includes fields for numbering or identifying messages. If
`there are such fields, the working group MUST define the scope within
`which such identifiers are unigue and the acceptable means of
`generating such identifiers.
`4.1.10. The common message format SHOULD be based on IETF-standard
`MIME [RFC 20451 .
`4.2. Reliability
`4.2.1. The protocol MUST include mechanisms so that a sender can be
`informed of the SUCCESSFUL DELIVERY of an INSTANT MESSAGE or reasons
`for failure. The working group must determine what mechanisms apply
`when final delivery status is unknown, such as when a message is
`relayed to non-IMPP systems.
`4.3 Performance
`4.3.1. The transport of INSTANT MESSAGES MUST be sufficiently rapid
`to allow for comfortable conversational exchanges of short messages.
`4.4 Presence Format
`4.4.1. The common presence format MUST define a minimum standard
`presence schema suitable for INSTANT MESSAGE SERVICES.
`4.4.2. When used in a system supporting INSTANT MESSAGES, the common
`presence format MUST include a means to represent the STATUS
`conditions OPEN and CLOSED.
`4.4.3. The STATUS conditions OPEN and CLOSED may also be applied to
`messaging or communication modes other than INSTANT MESSAGE SERVICES.
`
`Day, et al.
`
`Informational
`
`[Page 10]
`
`https://datatracker.ietf.org/doc/html/rfc2779[l 1/11/2021 1:11:18 PM]
`
`Epic Games Ex. 1035
`Page 10
`
`
`
`rfc2779
`
`RFC 2779
`
`Instant Messaging/Presence Protocol
`
`February 2000
`
`5. Security Considerations
`Security considerations are addressed in section 2.3, Access Control,
`and section 2.5, Message authentication and encryption.
`This section describes further security-related requirements that the
`protocol must meet.
`The security requirements were derived from a set of all-encompassing
`"security expectations" that were then evaluated for practicality and
`implementability and translated into requirements. In the appendix,
`we describe the expectations and the process used to transform them
`into requirements. In this section, we simply list the consolidated
`set of derived requirements.
`Note that in the requirements, ADMINISTRATORS may have privileges
`beyond those allowed to PRINCIPALS referred to in the requirements.
`(Unless otherwise noted, the individual expectations specifically
`refer to PRINCIPALS.) It is up to individual implementations to
`control administrative access and implement the security privileges
`of ADMINISTRATORS without compromising the requirements made on
`PRINCIPALS.
`Unless noted otherwise, A,B,C are all names of non-ADMINISTRATOR
`PRINCIPALS.
`5.1. Requirements related to SUBSCRIPTIONS
`When A establishes a SUBSCRIPTION to B's PRESENCE INFORMATION:
`5.1.1. The protocol MUST provide A means of identifying and
`authenticating that the PRESENTITY subscribed to is controlled by B.
`5.1.2. If A so chooses, the protocol SHOULD NOT make A's SUBSCRIPTION
`to B obvious to a third party C.
`5.1.3. The protocol MUST provide B with means of allowing an
`unauthenticated subscription by A.
`5.1.4. The protocol MUST provide A means of verifying the accurate
`receipt of the content B chooses to disclose to A.
`5.1.5. B MUST inform A if B refuses A's SUBSCRIPTION. Note that B may
`choose to accept A's SUBSCRIPTION, but fail to deliver any
`information to it (so-called "polite blocking"). See 5.1.15.
`5.1.6. The protocol MUST NOT let any third party C force A to
`subscribe to B's PRESENCE INFORMATION without A's consent.
`
`Day, et al.
`
`Informational
`
`[Page 11]
`
`https://datatracker.ietf.org/doc/html/rfc2779[l 1/11/2021 1:11:18 PM]
`
`Epic Games Ex. 1035
`Page 11
`
`
`
`rfc2779
`
`RFC 2779
`
`Instant Messaging/Presence Protocol
`
`February 2000
`
`5.1.7. A MUST be able to cancel her SUBSCRIPTION to B's PRESENCE
`INFORMATION at any time and for any reason. When A does so, the
`PRESENCE SERVICE stops informing A of changes to B's PRESENCE
`INFORMATION.
`5.1.8. The protocol MUST NOT let an unauthorized party C cancel A's
`SUBSCRIPTION to B.
`5.1.9. If A's SUBSCRIPTION to B is cancelled, the service SHOULD
`inform A of the cancellation.
`5.1.10. A SHOULD be able to determine the status of A's SUBSCRIPTION
`to B, at any time.
`5.1.11. The protocol MUST provide B means of learning about A's
`SUBSCRIPTION to B, both at the time of establishing the SUBSCRIPTION
`and afterwards.
`5.1.12. The protocol MUST provide B means of identifying and
`authenticating the SUBSCRIBER'S PRINCIPAL, A.
`5.1.13. It MUST be possible for B to prevent any particular PRINCIPAL
`from subscribing.
`5.1.14. It MUST be possible for B to prevent anonymous PRINCIPALS
`from subscribing.
`5.1.15. It MUST be possible for B to configure the PRESENCE SERVICE
`to deny A's subscription while appearing to A as if the subscription
`has been granted (this is sometimes called "polite blocking"). The
`protocol MUST NOT mandate the PRESENCE SERVICE to service
`subscriptions that are treated in this manner.
`5.1.16. B MUST be able to cancel A's subscription at will.
`5.1.17. The protocol MUST NOT reguire A to reveal A's IP address to
`B.
`5.1.18 The protocol MUST NOT reguire B to reveal B's IP address to A.
`5.2. Requirements related to NOTIFICATION
`When a PRINCIPAL B publishes PRESENCE INFORMATION for NOTIFICATION to
`another PRINCIPAL A:
`5.2.1. The protocol MUST provide means of ensuring that only the
`PRINCIPAL A being sent the NOTIFICATION by B can read the
`NOTIFICATION.
`
`Day, et al.
`
`Informational
`
`[Page 12]
`
`https://datatracker.ietf.org/doc/html/rfc2779[l 1/11/2021 1:11:18 PM]
`
`Epic Games Ex. 1035
`Page 12
`
`
`
`rfc2779
`
`RFC 2779
`
`Instant Messaging/Presence Protocol
`
`February 2000
`
`5.2.2. A should receive all NOTIFICATIONS intended for her.
`5.2.3. It MUST be possible for B to prevent A from receiving
`notifications, even if A is ordinarily permitted to see such
`notifications. It MUST be possible for B to, at its choosing, notify
`different subscribers differently, through different notification
`mechanisms or through publishing different content. This is a
`variation on "polite blocking".
`5.2.4. The protocol MUST provide means of protecting B from another
`PRINCIPAL C "spoofing" notification messages about B.
`5.2.5. The protocol MUST NOT reguire that A reveal A's IP address to
`B.
`5.2.6. The protocol MUST NOT reguire that B reveal B's IP address to
`A.
`5.3. Requirements related to receiving a NOTIFICATION
`When a PRINCIPAL A receives a notification message from another
`principal B, conveying PRESENCE INFORMATION,
`5.3.1. The protocol MUST provide A means of verifying that the
`presence information is accurate, as sent by B.
`5.3.2. The protocol MUST ensure that A is only sent NOTIFICATIONS
`from entities she has subscribed to.
`5.3.3. The protocol MUST provide A means of verifying that the
`notification was sent by B.
`5.4. Requirements related to INSTANT MESSAGES
`When a user A sends an INSTANT MESSAGE M to another user B,
`5.4.1. A MUST receive confirmation of non-delivery.
`5.4.2. If M is delivered, B MUST receive the message only once.
`5.4.3. The protocol MUST provide B means of verifying that A sent the
`message.
`5.4.4. B MUST be able to reply to the message via another instant
`message.
`5.4.5. The protocol MUST NOT always reguire A to reveal A's IP
`address, for A to send an instant message.
`
`Day, et al.
`
`Informational
`
`[Page 13]
`
`https://datatracker.ietf.org/doc/html/rfc2779[l 1/11/2021 1:11:18 PM]
`
`Epic Games Ex. 1035
`Page 13
`
`
`
`rfc2779
`
`RFC 2779
`
`Instant Messaging/Presence Protocol
`
`February 2000
`
`5.4.6. The protocol MUST provide A means of ensuring that no other
`PRINCIPAL C can see the content of M.
`5.4.7. The protocol MUST provide A means of ensuring that no other
`PRINCIPAL C can tamper with M, and B means to verify that no
`tampering has occurred.
`5.4.8. B must be able to read M.
`5.4.9. The protocol MUST allow A to sign the message, using existing
`standards for digital signatures.
`5.4.10. B MUST be able to prevent A from sending him messages
`6. References
`[RFC 2778] Day, M. , Rosenberg, J. and H. Sagano, "A Model for
`Presence and Instant Messaging", RFC 2778, February 2000.
`[RFC 2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile",
`RFC 2426, September 1998.
`[RFC 2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
`Extensions (MIME) - Part One: Format of Internet Message
`Bodies", RFC 2045, November 1996.
`[RFC 2119] Bradner, S., "Key Words for Use in RFCs to Indicate
`Reguirement Levels", BCP 14, RFC 2119, March 1997.
`
`Day, et al.
`
`Informational
`
`[Page 14]
`
`https://datatracker.ietf.org/doc/html/rfc2779[l 1/11/2021 1:11:18 PM]
`
`Epic Games Ex. 1035
`Page 14
`
`
`
`rfc2779
`
`RFC 2779
`
`Instant Messaging/Presence Protocol
`
`February 2000
`
`7.. Authors' Addresses
`Mark Day
`SightPath, Inc.
`135 Beaver Street
`Waltham, MA 02452
`USA
`EMail: mday@alum.mit.edu
`(Formerly Mark_Day@lotus.com)
`
`Sonu Aggarwal
`Microsoft Corporation
`One Microsoft Way
`Redmond, WA 98052
`USA
`EMail: sonuag@microsoft.com
`
`Gordon Mohr
`EMail: gojomo@usa.net
`(Formerly gojomo@activerse.com)
`
`Jesse Vincent
`Into Networks, Inc.
`150 Cambridgepark Drive
`Cambridge, MA 02140
`USA
`EMail: jesse@intonet.com
`(Formerly jvincent@microsoft.com)
`
`Day, et al.
`
`Informational
`
`[Page 15]
`
`https://datatracker.ietf.org/doc/html/rfc2779[l 1/11/2021 1:11:18 PM]
`
`Epic Games Ex. 1035
`Page 15
`
`
`
`rfc2779
`
`RFC 2779
`
`Instant Messaging/Presence Protocol
`
`February 2000
`
`8.. Appendix: Security Expectations and Deriving Requirements
`This appendix is based on the security expectations discussed on the
`impp mailing list and assembled by Jesse Vincent. The original form
`of numbering has been preserved in this appendix (so there are
`several different items labeled Bl, for example). The derived
`requirements have new numbers that are consistent with the main body
`of the document. This appendix is included to provide a connection
`from discussions on the list to the requirements of Section 8, but it
`is not intended to introduce any new requirements beyond those
`presented in Sections 5. through 8..
`8.1. PRESENCE INFORMATION
`In the case of PRESENCE INFORMATION, the controlling PRINCIPAL'S
`privacy interests are paramount; we agreed that "polite blocking"
`(denying without saying that the subscription is denied, or providing
`false information) should be possible.
`8.1.1. Subscription
`When a user Alice subscribes to another person, Bob's presence info,
`Alice expects:
`Al. the PRESENTITY's PRINCIPAL, B, is identifiable and authenticated
`Discussion: Stands as a requirement. Note that the protocol
`should provide Alice the capability of authenticating, without
`requiring that Alice authenticate every SUBSCRIPTION. This
`caveat is made necessary by performance concerns, among others,
`and applies to many of the other requirements derived below.
`[Requirement 5.1.1]
`A2. no third party will know that A has subscribed to B.
`Discussion: This is somewhat unreasonable to enforce as is. For
`example, in some topologies, nothing can prevent someone doing
`traffic analysis to deduce that A has subscribed to B. We should
`merely require that the protocol not expose subscription
`information in any obvious manner. [Requirement 5.1.2]
`
`Day, et al.
`
`Informational
`
`[Page 16]
`
`https://datatracker.ietf.org/doc/html/rfc2779[l 1/11/2021 1:11:18 PM]
`
`Epic Games Ex. 1035
`Page 16
`
`
`
`rfc2779
`
`RFC 2779
`
`Instant Messaging/Presence Protocol
`
`February 2000
`
`A3. A has the capability to subscribe to B's presence without B's
`knowledge, if B permits anonymous subscriptions.
`Discussion: An "anonymous subscription" above can have two
`implications - (i) B may allow an unauthenticated subscription by
`A, and (ii) B may be unaware of A's stated identity. Requirement
`(i) is reasonable [Requirement 8.1.3], but (ii) doesn't appear to
`be a core requirement -- it can be adequately simulated via a
`subscription pseudonym.
`A4. A will accurately receive what B chooses to disclose to A
`regarding B's presence.
`Discussion: Stands as a requirement, with the "optional"
`caveat. [Requirement 8.1.4]
`A5. B will inform A if B refuses A's subscription
`Discussion: Stands as a requirement. [Requirement 5.1.5]
`A6. No third party, C can force A to subscribe to B's presence
`without A's consent.
`Discussion: Stands as a requirement. [Requirement 5.1.6]
`A7. A can cancel her subscription to B's presence at any time and for
`any reason. When A does so, she will receive no further information
`about B's presence information.
`Discussion: This essentially stands. However, implementations
`may have to contend with a timing window where A receives, after
`sending her cancellation request, a notification sent by B before
`B received the cancellation request. Therefore, the requirement
`should focus on B's ceasing to send presence information, rather
`than A's ceasing to receive it. [Requirement 5.1.7]
`A8 . no third party, C, can cancel A's subscription to B.
`Discussion: Stands, although the administrative exception does
`apply. [Requirement 5.1.8]
`A9. A is notified if her subscription to B is cancelled for any
`reason.
`Discussion: Although the intent is reasonable, there are a number
`of scenarios (e.g. overburdened server, clogged network, server
`crash) where delivering a notification to A of the cancellation
`is undesirable or impossible. Therefore, the service should make
`
`Day, et al.
`
`Informational
`
`[Page 17]
`
`https://datatracker.ietf.org/doc/html/rfc2779[l 1/11/2021 1:11:18 PM]
`
`Epic Games Ex. 1035
`Page 17
`
`
`
`rfc2779
`
`RFC 2779
`
`Instant Messaging/Presence Protocol
`
`February 2000
`
`an attempt to inform, but this is not required. [Requirement
`5.1.9]
`Bob expects:
`Bl. B will be informed that A subscribed to B's presence information,
`as lonq as A has not subscribed anonymously.
`Discussion: This essentially stands. However, B can also choose
`to determine A's subscription after the fact. [Requirement
`5.1.10]
`B2. A is identifiable and authenticated.
`Discussion: This stands as a requirement. [Requirement 5.1.11]
`B3. B can prevent a particular user, D, from subscribinq.
`Discussion: This stands as a requirement. [Requirement 5.1.12]
`B4. B can prevent anonymous users from subscribinq.
`Discussion: This stands as a requirement. [Requirement 5.1.13]
`B5. B's presence information is not republished by A to a third
`party, E, who does not.
`Discussion: This is practically impossible to enforce, so it is
`omitted from the requirement set.
`B6. B can d