As per Relevance of the word presence, we have this rfc below:
Network Working Group M.
Request for Comments: 2779
Category: Informational S.
G.
J.
Into
February 2000
Instant Messaging / Presence Protocol
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
Presence and Instant Messaging have recently emerged as a new
of communications over the Internet. Presence is a means
finding, retrieving, and subscribing to changes in the
information (e.g. "online" or "offline") of other users.
messaging is a means for sending small, simple messages that
delivered immediately to online users
Applications of presence and instant messaging currently
independent, non-standard and non-interoperable protocols
by various vendors. The goal of the Instant Messaging and
Protocol (IMPP) Working Group is to define a standard protocol
that independently developed applications of instant messaging and/
presence can interoperate across the Internet. This document
a minimal set of requirements that IMPP must meet
Day, et al. Informational [Page 1]
RFC 2779 Instant Messaging/Presence Protocol February 2000
Table of
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.............. 7
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.................. 9
4.1. Common Message Format...................................... 9
4.2. Reliability................................................ 10
4.3. Performance................................................ 10
4.4. Presence Format............................................ 10
5. 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
8. 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.............................. 24
Full Copyright Statement......................................... 26
Day, et al. Informational [Page 2]
RFC 2779 Instant Messaging/Presence Protocol February 2000
1.
The following terms are defined in [RFC 2778] and are used with
definitions in this document
ACCESS
INSTANT
INSTANT
PRESENCE
PRESENCE
The terms MUST and SHOULD are used in the following sense
specifying requirements
MUST: A proposed solution will have to meet this requirement
SHOULD: A proposed solution may choose not to meet this requirement
Note that this usage of MUST and SHOULD differs from that of
2119.
Additionally, the following terms are used in this document
defined here
ADMINISTRATOR: A PRINCIPAL with authority over local computer
network resources, who manages local DOMAINS or FIREWALLS.
security and other purposes, an ADMINISTRATOR often needs or wants
impose restrictions on network usage based on traffic type, content
volume, or endpoints. A PRINCIPAL's ADMINISTRATOR has authority
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
(all defined in [RFC 2778]).
Day, et al. Informational [Page 3]
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
unusual measures to establish communications through the FIREWALL
IDENTIFIER: A means of indicating a point of contact, intended
public use such as on a business card. Telephone numbers,
addresses, and typical home page URLs are all examples of
in other systems. Numeric IP addresses like 10.0.0.26 are not,
neither are URLs containing numerous CGI parameters or long
identifiers
INTENDED RECIPIENT: The PRINCIPAL to whom the sender of an
MESSAGE is sending it
NAMESPACE: The system that maps from a name of an ENTITY to
concrete implementation of that ENTITY. A NAMESPACE may be
of a number of distinct DOMAINS
OUT OF CONTACT: A situation in which some ENTITY and the
SERVICE cannot communicate
SUCCESSFUL DELIVERY: A situation in which an INSTANT MESSAGE
transmitted to an INSTANT INBOX for the INTENDED RECIPIENT, and
INSTANT INBOX acknowledged its receipt. SUCCESSFUL DELIVERY
also implies that an INBOX USER AGENT has handled the message in
way chosen by the PRINCIPAL. However, SUCCESSFUL DELIVERY does
imply that the message was actually seen by that PRINCIPAL
2. Shared
This section describes non-security requirements that are common
both an PRESENCE SERVICE and an INSTANT MESSAGE SERVICE. Section 6
describes requirements specific to a PRESENCE SERVICE, while
7 describes requirements specific to an INSTANT MESSAGE SERVICE
Section 8 describes security considerations. The reader should
that Section 11 is an appendix that provides historical context
aids in tracing the origins of requirements in Section 8. Section 11
is not, however, a statement of current IMPP requirements
It is expected that Presence and Instant Messaging services will
particularly valuable to users over mobile IP wireless
devices. Indeed the number of devices connected to the Internet
wireless means is expected to grow substantially in the coming years
It is not reasonable to assume that separate protocols will
available for the wireless portions of the Internet. In addition,
note that wireless infrastructure is maturing rapidly; the
undertaken by this group should take into account the expected
of the maturity of the technology in the time-frame in which
Day, et al. Informational [Page 4]
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
suitable for operation in a context typically associated with
wireless access devices, viz. high latency, low bandwidth
possibly intermittent connectivity (which lead to a desire
minimize round-trip delays), modest computing power,
constraints, small displays, etc. In particular, the protocols
be designed to be reasonably efficient for small payloads
2.1. Namespace and
2.1.1. The protocols MUST allow a PRESENCE SERVICE to be
independent of whether an INSTANT MESSAGE SERVICE is available,
vice-versa
2.1.2. The protocols must not assume that an INSTANT INBOX
necessarily reached by the same IDENTIFIER as that of a PRESENTITY
Specifically, the protocols must assume that some INSTANT INBOXes
have no associated PRESENTITIES, and vice versa
2.1.3. The protocols MUST also allow an INSTANT INBOX to be
via the same IDENTIFIER as the IDENTIFIER of some PRESENTITY
2.1.4. The administration and naming of ENTITIES within a
DOMAIN MUST be able to operate independently of actions in any
DOMAIN
2.1.5. The protocol MUST allow for an arbitrary number of
within the NAMESPACE
2.2.
2.2.1. It MUST be possible for ENTITIES in one DOMAIN to
with ENTITIES in another DOMAIN, without the DOMAINS
previously been aware of each other
The protocol MUST be capable of meeting its other functional
performance requirements even
-- (2.2.2) there are millions of ENTITIES within a single DOMAIN
-- (2.2.3) there are millions of DOMAINS within the
NAMESPACE
Day, et al. Informational [Page 5]
RFC 2779 Instant Messaging/Presence Protocol February 2000
-- (2.2.4) every single SUBSCRIBER has SUBSCRIPTIONS to
of PRESENTITIES
-- (2.2.5) hundreds of distinct SUBSCRIBERS have SUBSCRIPTIONS
a single PRESENTITY
-- (2.2.6) every single SUBSCRIBER has SUBSCRIPTIONS
PRESENTITIES in hundreds of distinct DOMAINS
These are protocol design goals; implementations may choose to
lower limits
2.3. Access
The PRINCIPAL controlling a PRESENTITY MUST be able to
-- (2.3.1) which WATCHERS can observe that PRESENTITY's
INFORMATION
-- (2.3.2) which WATCHERS can have SUBSCRIPTIONS to
PRESENTITY's PRESENCE INFORMATION
-- (2.3.3) what PRESENCE INFORMATION a particular WATCHER will
for that PRESENTITY, regardless of whether the WATCHER gets
by fetching or NOTIFICATION
-- (2.3.4) which other PRINCIPALS, if any, can update the
INFORMATION of that PRESENTITY
The PRINCIPAL controlling an INSTANT INBOX MUST be able to
-- (2.3.5) which other PRINCIPALS, if any, can send
MESSAGES to that INSTANT INBOX
-- (2.3.6) which other PRINCIPALS, if any, can read
MESSAGES from that INSTANT INBOX
2.3.7. Access control MUST be independent of presence: the
SERVICE MUST be able to make access control decisions even when
PRESENTITY is OUT OF CONTACT
2.4. Network
Note that intermediaries such as PROXIES may be necessitated
IP and non-IP networks, and by an end-user's desire to
anonymity and hide their IP address
Day, et al. Informational [Page 6]
RFC 2779 Instant Messaging/Presence Protocol February 2000
2.4.1. The protocol MUST allow the creation of a SUBSCRIPTION
directly and via intermediaries, such as PROXIES
2.4.2. The protocol MUST allow the sending of a NOTIFICATION
directly and via intermediaries, such as PROXIES
2.4.3. The protocol MUST allow the sending of an INSTANT MESSAGE
directly and via intermediaries, such as PROXIES
2.4.4. The protocol proxying facilities and transport practices
allow ADMINISTRATORS ways to enable and disable protocol
through existing and commonly-deployed FIREWALLS. The protocol
specify how it can be effectively filtered by such FIREWALLS
2.5. Message Encryption and
2.5.1. The protocol MUST provide means to ensure confidence that
received message (NOTIFICATION or INSTANT MESSAGE) has not
corrupted or tampered with
2.5.2. The protocol MUST provide means to ensure confidence that
received message (NOTIFICATION or INSTANT MESSAGE) has not
recorded and played back by an adversary
2.5.3. The protocol MUST provide means to ensure that a sent
(NOTIFICATION or INSTANT MESSAGE) is only readable by ENTITIES
the sender allows
2.5.4. The protocol MUST allow any client to use the means to
non-corruption, non-playback, and privacy, but the protocol MUST
require that all clients use these means at all times
3. Additional Requirements for PRESENCE
The requirements in section 6 are applicable only to
INFORMATION and not to INSTANT MESSAGES. Additional constraints
PRESENCE INFORMATION in a system supporting INSTANT MESSAGES
in Section 7.4.
3.1. Common Presence
3.1.1. All ENTITIES MUST produce and consume at least a common
format for PRESENCE INFORMATION
3.1.2. The common presence format MUST include a means to
identify the PRESENTITY whose PRESENCE INFORMATION is reported
Day, et al. Informational [Page 7]
RFC 2779 Instant Messaging/Presence Protocol February 2000
3.1.3. The common presence format MUST include a means to
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
to represent additional information not included in the
format, without undermining or rendering invalid the fields of
common format
3.1.5. The working group must define the extension and
mechanisms for presence information schema, including new
conditions and new forms for OTHER PRESENCE MARKUP
3.1.6. The presence format SHOULD be based on IETF standards such
vCard [RFC 2426] if possible
3.2. Presence Lookup and
3.2.1. A FETCHER MUST be able to fetch a PRESENTITY's
INFORMATION even when the PRESENTITY is OUT OF CONTACT
3.2.2. A SUBSCRIBER MUST be able to request a SUBSCRIPTION to
PRESENTITY's PRESENCE INFORMATION, even when the PRESENTITY is OUT
CONTACT
3.2.3. If the PRESENCE SERVICE has SUBSCRIPTIONS for a PRESENTITY'
PRESENCE INFORMATION, and that PRESENCE INFORMATION changes,
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
PRESENTITY or SUBSCRIBER has gone OUT OF CONTACT
3.2.5. The protocol MUST NOT depend on a PRESENTITY or
gracefully telling the service that it will no longer be
communication, since a PRESENTITY or SUBSCRIBER may go OUT OF
due to unanticipated failures
3.3. Presence Caching and
3.3.1. The protocol MUST include mechanisms to allow
INFORMATION to be cached
3.3.2. The protocol MUST include mechanisms to allow cached
INFORMATION to be updated when the master copy changes
Day, et al. Informational [Page 8]
RFC 2779 Instant Messaging/Presence Protocol February 2000
3.3.3 The protocol caching facilities MUST NOT circumvent
ACCESS RULES or restrict choice of authentication/
mechanisms
3.4
3.4.1 When a PRESENTITY changes its PRESENCE INFORMATION,
SUBSCRIBER to that information MUST be notified of the
information rapidly, except when such notification is
prevented by ACCESS RULES. This requirement is met if
SUBSCRIBER's NOTIFICATION is transported as rapidly as an
MESSAGE would be transported to an INSTANT INBOX
4. Additional Requirements for INSTANT
The requirements in section 4 are applicable only to INSTANT
and not to PRESENCE INFORMATION, with the exception of Section 4.4.
Section 4.4 describes constraints on PRESENCE INFORMATION that
relevant only to systems that support both INSTANT MESSAGES
PRESENCE INFORMATION
4.1. Common Message
4.1.1. All ENTITIES sending and receiving INSTANT MESSAGES
implement at least a common base format for INSTANT MESSAGES
4.1.2. The common base format for an INSTANT MESSAGE MUST
the sender and intended recipient
4.1.3. The common message format MUST include a return address
the receiver to reply to the sender with another INSTANT MESSAGE
4.1.4. The common message format SHOULD include standard forms
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
identification of the message payload to allow for non-ASCII
encrypted content
4.1.6. The protocol must reflect best current practices related
internationalization
4.1.7. The protocol must reflect best current practices related
accessibility
Day, et al. Informational [Page 9]
RFC 2779 Instant Messaging/Presence Protocol February 2000
4.1.8. The working group MUST define the extension and
mechanisms for the message format, including new fields and
schemes for INSTANT INBOX ADDRESSES
4.1.9. The working group MUST determine whether the common
format includes fields for numbering or identifying messages.
there are such fields, the working group MUST define the scope
which such identifiers are unique and the acceptable means
generating such identifiers
4.1.10. The common message format SHOULD be based on IETF-
MIME [RFC 2045].
4.2.
4.2.1. The protocol MUST include mechanisms so that a sender can
informed of the SUCCESSFUL DELIVERY of an INSTANT MESSAGE or
for failure. The working group must determine what mechanisms
when final delivery status is unknown, such as when a message
relayed to non-IMPP systems
4.3
4.3.1. The transport of INSTANT MESSAGES MUST be sufficiently
to allow for comfortable conversational exchanges of short messages
4.4 Presence
4.4.1. The common presence format MUST define a minimum
presence schema suitable for INSTANT MESSAGE SERVICES
4.4.2. When used in a system supporting INSTANT MESSAGES, the
presence format MUST include a means to represent the
conditions OPEN and CLOSED
4.4.3. The STATUS conditions OPEN and CLOSED may also be applied
messaging or communication modes other than INSTANT MESSAGE SERVICES
Day, et al. Informational [Page 10]
RFC 2779 Instant Messaging/Presence Protocol February 2000
5. Security
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
protocol must meet
The security requirements were derived from a set of all-
"security expectations" that were then evaluated for practicality
implementability and translated into requirements. In the appendix
we describe the expectations and the process used to transform
into requirements. In this section, we simply list the
set of derived requirements
Note that in the requirements, ADMINISTRATORs may have
beyond those allowed to PRINCIPALs referred to in the requirements
(Unless otherwise noted, the individual expectations
refer to PRINCIPALs.) It is up to individual implementations
control administrative access and implement the security
of ADMINISTRATORs without compromising the requirements made
PRINCIPALs
Unless noted otherwise, A,B,C are all names of non-
PRINCIPALS
5.1. Requirements related to
When A establishes a SUBSCRIPTION to B's PRESENCE INFORMATION
5.1.1. The protocol MUST provide A means of identifying
authenticating that the PRESENTITY subscribed to is controlled by B
5.1.2. If A so chooses, the protocol SHOULD NOT make A's
to B obvious to a third party C
5.1.3. The protocol MUST provide B with means of allowing
unauthenticated subscription by A
5.1.4. The protocol MUST provide A means of verifying the
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
choose to accept A's SUBSCRIPTION, but fail to deliver
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
subscribe to B's PRESENCE INFORMATION without A's consent
Day, et al. Informational [Page 11]
RFC 2779 Instant Messaging/Presence Protocol February 2000
5.1.7. A MUST be able to cancel her SUBSCRIPTION to B's
INFORMATION at any time and for any reason. When A does so,
PRESENCE SERVICE stops informing A of changes to B's
INFORMATION
5.1.8. The protocol MUST NOT let an unauthorized party C cancel A'
SUBSCRIPTION to B
5.1.9. If A's SUBSCRIPTION to B is cancelled, the service
inform A of the cancellation
5.1.10. A SHOULD be able to determine the status of A's
to B, at any time
5.1.11. The protocol MUST provide B means of learning about A'
SUBSCRIPTION to B, both at the time of establishing the
and afterwards
5.1.12. The protocol MUST provide B means of identifying
authenticating the SUBSCRIBER's PRINCIPAL, A
5.1.13. It MUST be possible for B to prevent any particular
from subscribing
5.1.14. It MUST be possible for B to prevent anonymous
from subscribing
5.1.15. It MUST be possible for B to configure the PRESENCE
to deny A's subscription while appearing to A as if the
has been granted (this is sometimes called "polite blocking").
protocol MUST NOT mandate the PRESENCE SERVICE to
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 require A to reveal A's IP address
B
5.1.18 The protocol MUST NOT require B to reveal B's IP address to A
5.2. Requirements related to
When a PRINCIPAL B publishes PRESENCE INFORMATION for NOTIFICATION
another PRINCIPAL A
5.2.1. The protocol MUST provide means of ensuring that only
PRINCIPAL A being sent the NOTIFICATION by B can read
NOTIFICATION
Day, et al. Informational [Page 12]
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
notifications, even if A is ordinarily permitted to see
notifications. It MUST be possible for B to, at its choosing,
different subscribers differently, through different
mechanisms or through publishing different content. This is
variation on "polite blocking".
5.2.4. The protocol MUST provide means of protecting B from
PRINCIPAL C "spoofing" notification messages about B
5.2.5. The protocol MUST NOT require that A reveal A's IP address
B
5.2.6. The protocol MUST NOT require that B reveal B's IP address
A
5.3. Requirements related to receiving a
When a PRINCIPAL A receives a notification message from
principal B, conveying PRESENCE INFORMATION
5.3.1. The protocol MUST provide A means of verifying that
presence information is accurate, as sent by B
5.3.2. The protocol MUST ensure that A is only sent
from entities she has subscribed to
5.3.3. The protocol MUST provide A means of verifying that
notification was sent by B
5.4. Requirements related to INSTANT
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
message
5.4.4. B MUST be able to reply to the message via another
message
5.4.5. The protocol MUST NOT always require A to reveal A's
address, for A to send an instant message
Day, et al. Informational [Page 13]
RFC 2779 Instant Messaging/Presence Protocol February 2000
5.4.6. The protocol MUST provide A means of ensuring that no
PRINCIPAL C can see the content of M
5.4.7. The protocol MUST provide A means of ensuring that no
PRINCIPAL C can tamper with M, and B means to verify that
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
standards for digital signatures
5.4.10. B MUST be able to prevent A from sending him
6.
[RFC 2778] Day, M., Rosenberg, J. and H. Sagano, "A Model
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
Extensions (MIME) - Part One: Format of Internet
Bodies", RFC 2045, November 1996.
[RFC 2119] Bradner, S., "Key Words for Use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
Day, et al. Informational [Page 14]
RFC 2779 Instant Messaging/Presence Protocol February 2000
7. Authors'
Mark
SightPath, Inc
135 Beaver
Waltham, MA 02452
EMail: mday@alum.mit.
(Formerly Mark_Day@lotus.com
Sonu
Microsoft
One Microsoft
Redmond, WA 98052
EMail: sonuag@microsoft.
Gordon
EMail: gojomo@usa.
(Formerly gojomo@activerse.com
Jesse
Into Networks, Inc
150 Cambridgepark
Cambridge, MA 02140
EMail: jesse@intonet.
(Formerly jvincent@microsoft.com
Day, et al. Informational [Page 15]
RFC 2779 Instant Messaging/Presence Protocol February 2000
8. Appendix: Security Expectations and Deriving
This appendix is based on the security expectations discussed on
impp mailing list and assembled by Jesse Vincent. The original
of numbering has been preserved in this appendix (so there
several different items labeled B1, for example). The
requirements have new numbers that are consistent with the main
of the document. This appendix is included to provide a
from discussions on the list to the requirements of Section 8, but
is not intended to introduce any new requirements beyond
presented in Sections 5 through 8.
8.1. PRESENCE
In the case of PRESENCE INFORMATION, the controlling PRINCIPAL'
privacy interests are paramount; we agreed that "polite blocking
(denying without saying that the subscription is denied, or
false information) should be possible
8.1.1.
When a user Alice subscribes to another person, Bob's presence info
Alice expects
A1. the PRESENTITY's PRINCIPAL, B, is identifiable and
Discussion: Stands as a requirement. Note that the
should provide Alice the capability of authenticating,
requiring that Alice authenticate every SUBSCRIPTION.
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.
example, in some topologies, nothing can prevent someone
traffic analysis to deduce that A has subscribed to B. We
merely require that the protocol not expose
information in any obvious manner. [Requirement 5.1.2]
Day, et al. Informational [Page 16]
RFC 2779 Instant Messaging/Presence Protocol February 2000
A3. A has the capability to subscribe to B's presence without B'
knowledge, if B permits anonymous subscriptions
Discussion: An "anonymous subscription" above can have
implications - (i) B may allow an unauthenticated subscription
A, and (ii) B may be unaware of A's stated identity.
(i) is reasonable [Requirement 8.1.3], but (ii) doesn't appear
be a core requirement -- it can be adequately simulated via
subscription pseudonym
A4. A will accurately receive what B chooses to disclose to
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
Discussion: Stands as a requirement. [Requirement 5.1.5]
A6. No third party, C can force A to subscribe to B's
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
any reason. When A does so, she will receive no further
about B's presence information
Discussion: This essentially stands. However,
may have to contend with a timing window where A receives,
sending her cancellation request, a notification sent by B
B received the cancellation request. Therefore, the
should focus on B's ceasing to send presence information,
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
apply. [Requirement 5.1.8]
A9. A is notified if her subscription to B is cancelled for
reason
Discussion: Although the intent is reasonable, there are a
of scenarios (e.g. overburdened server, clogged network,
crash) where delivering a notification to A of the
is undesirable or impossible. Therefore, the service should
Day, et al. Informational [Page 17]
RFC 2779 Instant Messaging/Presence Protocol February 2000
an attempt to inform, but this is not required. [
5.1.9]
Bob expects
B1. B will be informed that A subscribed to B's presence information
as long as A has not subscribed anonymously
Discussion: This essentially stands. However, B can also
to determine A's subscription after the fact. [
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 subscribing
Discussion: This stands as a requirement. [Requirement 5.1.12]
B4. B can prevent anonymous users from subscribing
Discussion: This stands as a requirement. [Requirement 5.1.13]
B5. B's presence information is not republished by A to a
party, E, who does not
Discussion: This is practically impossible to enforce, so it
omitted from the requirement set
B6. B can deny A's subscription without letting A know that she'
been blocked
Discussion: This "polite blocking" capability essentially stands
accepting a "denied" subscription should bear no implication
servicing it for status notifications. [Requirement 5.1.14]
B7. B can cancel A's subscription at will
Discussion: Stands as a requirement. [Requirement 5.1.15]
Charlie, bob's network administrator expects
C1. C knows who is subscribed to B at all times
Discussion: Administrators should be able to determine who
subscribed, but needn't be continuously informed of the list
subscribers. Also, in some cases user agents (e.g. proxies)
Day, et al. Informational [Page 18]
RFC 2779 Instant Messaging/Presence Protocol February 2000
have subscribed on behalf of users, and in these cases
administrator can only determine the identity of these agents
not their users. [Requirement 5.1.16]
C2. C can manage all aspects of A's presence information
Discussion: This stands as a requirement. [Requirement 5.1.17]
C3. C can control who can access A's presence information
exchange instant messages with A
Discussion: This stands in principle, but C should be able
waive these capabilities if C desires. [Requirement 5.1.18]
8.1.2.
The publisher of status information, Bob, expects
B1. That information about B is not provided to any entity
B's knowledge and consent
Discussion: This is nearly impossible to accomplish, so it
omitted from the requirements
8.1.3. Publication for
When information is published for notification, B expects
B1. only a person being sent a notification, A, can read
notification
Discussion: Stands as a requirement. [Requirement 5.2.1]
B2. A reliably receives all notifications intended for her
Discussion: This stands, although "Reliably" is a little
(e.g. network outages, etc.). [Requirement 5.2.2]
B3. B can prevent A from receiving notifications, even if A
ordinarily permitted to see such notifications. This is a
on "polite blocking."
Discussion: This stands as a requirement. Also incorporated
this requirement is the notifications equivalent of the
expectation, B4. [Requirement 5.2.3]
Day, et al. Informational [Page 19]
RFC 2779 Instant Messaging/Presence Protocol February 2000
B4. B can provide two interested parties A and E with
status information at the same time. (B could represent the
event differently to different people.)
Discussion: This stands as a requirement; it has
incorporated into the corresponding requirement for B3 above
B5. B expects that malicious C cannot spoof notification
about B
Discussion: Stands in principle, but it should be optional for B
[Requirement 5.2.4]
8.1.4. Receiving a
When Alice receives a notification, the recipient, Alice, expects
A1. That the notification information is accurate, truthful
Discussion: Stands in principle, although being "truthful" can'
be a requirement, and the verification is optional for Alice
[Requirement 5.3.1]
A2. That information about subscriptions remains private; people
not learn that A's subscription to B's information exists by
notifications occur
Discussion: This is omitted from the requirements, as
analysis, even of encrypted traffic, can convey this
in some situations
A3. That she only receives notifications of things she's
to
Discussion: Stands as a requirement. [Requirement 5.3.2]
A4. Notifications come from the apparent sender, B
Discussion: Stands in principle, although the verification
be optional for A. [Requirement 5.3.3]
A5. A can tell the difference between a message generated by
user, and a message legitimately generated by the agent on behalf
the user
Discussion: This could be quite difficult to enforce and
unduly restrict usage scenarios; this is omitted from
requirements
Day, et al. Informational [Page 20]
RFC 2779 Instant Messaging/Presence Protocol February 2000
A6. That information given by agents on behalf of users can also
expected to be truthful, complete, and legitimately offered; the
permitted the agent to publish these notifications
Discussion: This is difficult to enforce and is omitted from
requirements
A7. A can prove that a notification from B was delivered in a
fashion and can prove exactly how long the message took to
delivered
Discussion: This is difficult to enforce and is omitted from
requirements. For example, such proof may entail global
synchronization mechanisms (since any system clocks
associated unreliability), which is outside the scope of
effort
A8. A can prove that B was indeed the sender of a given message
Discussion: This is a duplication of expectation A4 above and
reflected in the corresponding requirement 5.3.3.
8.2. INSTANT
8.2.1. Named Instant
When a user Alice sends an instant message M to another user Bob
Alice expects that she
A1. will receive notification of non-
Discussion: Stands as a requirement. [Requirement 5.4.1]
Alice expects that Bob
B1. will receive the
Discussion: covered by A1 and is reflected in the
requirement 5.4.1.
B2. will receive the message
Discussion: Stands as a requirement, although this is
covered elsewhere (in the non-security requirements), so this
omitted from the security requirements
Day, et al. Informational [Page 21]
RFC 2779 Instant Messaging/Presence Protocol February 2000
B3. will receive the message only
Discussion: Stands as a requirement. [Requirement 5.4.2]
B4. will be able to verify that Alice sent the
Discussion: Stands as a requirement. [Requirement 5.4.3]
B5. will not know whether there were
Discussion: Emulating e-mail conventions and social protocols
not a core goal of this effort, and therefore references
standard mail fields are omitted from the requirements
B6. will be able to reply to the
Discussion: Stands in principle; the recipient should be able
reply via an instant message. [Requirement 5.4.4]
B7. will know if he was a bcc
Discussion: Omitted, as noted above
B8. will not be able to determine any information about A (such
her location or IP address) without A's knowledge and consent
Discussion: "Any information about A" is too general;
requirement should focus on IP address. Further, "without A'
knowledge and consent" may be overkill. [Requirement 5.4.5]
Alice expects that no other user Charlie will be able to
C1. see the content of
Discussion: Stands in principle, although this should not
mandated for all IM communication. [Requirement 5.4.6]
C2. tamper with
Discussion: Stands, with the same caveat as above
[Requirement 5.4.7]
C3. know that M was
Discussion: It is impossible to prevent traffic analysis,
this is therefore omitted from the requirements
Day, et al. Informational [Page 22]
RFC 2779 Instant Messaging/Presence Protocol February 2000
When a user Bob receives an instant message M from another
Alice
Bob expects that Bob
D1. will be able to read
Discussion: Stands as a requirement. [Requirement 5.4.8]
D2. will be able to verify M's authenticity (both Temporal and
sender's identity
Discussion: As noted earlier, it is not reasonable to
require temporal checks. The protocol should, however,
signing messages using existing standards for signing
[Requirement 5.4.9]
D3. will be able to verify M's
Discussion: Stands as a requirement. [Requirement 5.4.10]
D4. will be able to prevent A from sending him future
Discussion: Stands as a requirement. [Requirement 5.4.11]
Bob expects that Alice
E1. intended to send the message to
Discussion: This is covered by the corresponding
5.4.6 for C1 above
E2. informed Bob of all CCs
Discussion: As noted earlier, references to cc:'s are
from the requirements
8.2.2. Anonymous Instant
Discussion: Anonymous instant messaging, as in "hiding
identity of the sender", is not deemed to be a core
of the protocol and references to it are therefore omitted
the requirements. Implementations may provide facilities
anonymous messaging if they wish, in ways that are
with the other requirements
When a user Alice sends an anonymous instant message to another
Bob
Day, et al. Informational [Page 23]
RFC 2779 Instant Messaging/Presence Protocol February 2000
Alice expects that Bob
B1. will receive the
B2. will receive the message
B3. will receive the message only
AB4.1. cannot know Alice sent
AB4.2. will know that the IM is anonymous, and not from a
named
AB4.3 may not allow anonymous
B5. will not know whether there were
B6. will be able to reply to the
Alice expects that she
C1. will receive notification of non-
AC2. will receive an error if the IM was
Bob expects that he
D1. will be able to read
D2. will be able to verify M's authenticity (both temporal and
sender's identity
D3. will be able to verify M's
AD4. will know if an IM was sent
AD5. will be able to automatically discard anonymous IM if
AD6. will be able to control whether an error is sent to Alice if
is discarded
8.2.3. Administrator
Charlie, Alice's network administrator expects
C1. that C will be able to send A instant messages at any time
C2. that A will receive any message he sends while A is online
Day, et al. Informational [Page 24]
RFC 2779 Instant Messaging/Presence Protocol February 2000
C3. that A will not be able to refuse delivery of any
messages sent by C
Discussion for C1-C3: It is not clear this needs to be
handled at the protocol level; Administrators may accomplish
above objectives through other means. For example,
administrator may send a message to a user through the
mechanisms. This is therefore omitted from the requirements
Day, et al. Informational [Page 25]
RFC 2779 Instant Messaging/Presence Protocol February 2000
Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Day, et al. Informational [Page 26]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
