< draft-ietf-impp-reqts-03.txt   draft-ietf-impp-reqts-04.txt >
INTERNET-DRAFT Mark Day INTERNET-DRAFT Mark Day
Expires: February 26, 2000 Lotus Expires: June 9, 2000 Lotus
Sonu Aggarwal Sonu Aggarwal
Microsoft Microsoft
Gordon Mohr Gordon Mohr
Activerse Activerse
Jesse Vincent Jesse Vincent
Arepa Arepa
Instant Messaging / Presence Protocol Requirements Instant Messaging / Presence Protocol Requirements
draft-ietf-impp-reqts-03.txt draft-ietf-impp-reqts-04.txt
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This document and related documents are discussed on the impp mailing This document and related documents are discussed on the impp mailing
list. To join the list, send mail to impp-request@iastate.edu. To list. To join the list, send mail to impp-request@iastate.edu. To
contribute to the discussion, send mail to impp@iastate.edu. The contribute to the discussion, send mail to impp@iastate.edu. The
archives are at http://lists.fsck.com/cgi-bin/wilma/pip. The IMPP archives are at http://www.imppwg.org/ml_archives.html. The IMPP
working group charter, including the current list of group documents, working group charter, including the current list of group documents,
can be found at http://www.ietf.org/html.charters/impp-charter.html. can be found at http://www.ietf.org/html.charters/impp-charter.html.
2. Abstract 2. Abstract
Presence and Instant Messaging have recently emerged as a new medium Presence and Instant Messaging have recently emerged as a new medium
of communications over the Internet. Presence is a means for finding, of communications over the Internet. Presence is a means for finding,
retrieving, and subscribing to changes in the presence information retrieving, and subscribing to changes in the presence information
(e.g. "online" or "offline") of other users. Instant messaging is a (e.g. "online" or "offline") of other users. Instant messaging is a
means for sending small, simple messages that are delivered means for sending small, simple messages that are delivered
skipping to change at line 123 skipping to change at line 122
PRESENCE SERVICE PRESENCE SERVICE
PRESENTITY PRESENTITY
PRINCIPAL PRINCIPAL
PROXY PROXY
SERVER SERVER
STATUS STATUS
SUBSCRIBER SUBSCRIBER
SUBSCRIPTION SUBSCRIPTION
WATCHER WATCHER
The terms MUST, SHOULD, and MAY are used with the meaning defined in The terms MUST and SHOULD are used in the following sense while
[RFC 2119]. specifying requirements:
The following terms are used in this document and defined here: 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 RFC2119.
Additionally, the following terms are used in this document and
defined here:
ADMINISTRATOR: A PRINCIPAL with authority over local computer and ADMINISTRATOR: A PRINCIPAL with authority over local computer and
network resources, who manages local DOMAINS or FIREWALLS. For security network resources, who manages local DOMAINS or FIREWALLS. For security
and other purposes, an ADMINISTRATOR often needs or wants to impose and other purposes, an ADMINISTRATOR often needs or wants to impose
restrictions on network usage based on traffic type, content, volume, restrictions on network usage based on traffic type, content, volume,
or endpoints. A PRINCIPAL's ADMINISTRATOR has authority over or endpoints. A PRINCIPAL's ADMINISTRATOR has authority over
some or all of that PRINCIPAL's computer and network resources. some or all of that PRINCIPAL's computer and network resources.
DOMAIN: A portion of a NAMESPACE. DOMAIN: A portion of a NAMESPACE.
skipping to change at line 155 skipping to change at line 160
public use such as on a business card. Telephone numbers, email public use such as on a business card. Telephone numbers, email
addresses, and typical home page URLs are all examples of IDENTIFIERS 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 in other systems. Numeric IP addresses like 10.0.0.26 are not, and
neither are URLs containing numerous CGI parameters or long arbitrary neither are URLs containing numerous CGI parameters or long arbitrary
identifiers. identifiers.
INTENDED RECIPIENT: The PRINCIPAL to whom the sender of an INSTANT INTENDED RECIPIENT: The PRINCIPAL to whom the sender of an INSTANT
MESSAGE is sending it. MESSAGE is sending it.
NAMESPACE: The system that maps from a name of an ENTITY to the NAMESPACE: The system that maps from a name of an ENTITY to the
concrete implementation of that ENTITY. A NAMESPACE MAY be composed of concrete implementation of that ENTITY. A NAMESPACE may be composed of
a number of distinct DOMAINS. a number of distinct DOMAINS.
OUT OF CONTACT: A situation in which some ENTITY and the PRESENCE OUT OF CONTACT: A situation in which some ENTITY and the PRESENCE
SERVICE cannot communicate. SERVICE cannot communicate.
SUCCESSFUL DELIVERY: A situation in which an INSTANT MESSAGE was SUCCESSFUL DELIVERY: A situation in which an INSTANT MESSAGE was
transmitted to an INSTANT INBOX for the INTENDED RECIPIENT, and the transmitted to an INSTANT INBOX for the INTENDED RECIPIENT, and the
INSTANT INBOX acknowledged its receipt. SUCCESSFUL DELIVERY usually INSTANT INBOX acknowledged its receipt. SUCCESSFUL DELIVERY usually
also implies that an INBOX USER AGENT has handled the message in a also implies that an INBOX USER AGENT has handled the message in a
way chosen by the PRINCIPAL. However, SUCCESSFUL DELIVERY does not way chosen by the PRINCIPAL. However, SUCCESSFUL DELIVERY does not
skipping to change at line 179 skipping to change at line 184
This section describes non-security requirements that are common to This section describes non-security requirements that are common to
both an PRESENCE SERVICE and an INSTANT MESSAGE SERVICE. Section 6 both an PRESENCE SERVICE and an INSTANT MESSAGE SERVICE. Section 6
describes requirements specific to a PRESENCE SERVICE, while Section 7 describes requirements specific to a PRESENCE SERVICE, while Section 7
describes requirements specific to an INSTANT MESSAGE SERVICE. Section describes requirements specific to an INSTANT MESSAGE SERVICE. Section
8 describes security considerations. The reader should note that 8 describes security considerations. The reader should note that
Section 11 is an appendix that provides historical context and aids in Section 11 is an appendix that provides historical context and aids in
tracing the origins of requirements in Section 8. Section 11 is not, tracing the origins of requirements in Section 8. Section 11 is not,
however, a statement of current IMPP requirements. however, a statement of current IMPP requirements.
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 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.
5.1. Namespace and Administration 5.1. Namespace and Administration
5.1.1. The protocols MUST allow a PRESENCE SERVICE to be available 5.1.1. The protocols MUST allow a PRESENCE SERVICE to be available
independent of whether an INSTANT MESSAGE SERVICE is available, and independent of whether an INSTANT MESSAGE SERVICE is available, and
vice-versa. vice-versa.
5.1.2. The protocols MUST allow an INSTANT INBOX to be reached via a 5.1.2. The protocols must not assume that an INSTANT INBOX is
different IDENTIFIER than the IDENTIFIER of any PRESENTITY. 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.
5.1.3. The protocols MUST also allow an INSTANT INBOX to be reached 5.1.3. The protocols MUST also allow an INSTANT INBOX to be reached
via the same IDENTIFIER as the IDENTIFIER of some PRESENTITY. via the same IDENTIFIER as the IDENTIFIER of some PRESENTITY.
5.1.4. The administration and naming of ENTITIES within a given DOMAIN 5.1.4. The administration and naming of ENTITIES within a given DOMAIN
MUST be able to operate independently of actions in any other DOMAIN. MUST be able to operate independently of actions in any other DOMAIN.
5.1.5. The protocol MUST allow for an arbitrary number of DOMAINS 5.1.5. The protocol MUST allow for an arbitrary number of DOMAINS
within the NAMESPACE. within the NAMESPACE.
5.2. Scalability 5.2. Scalability
5.2.1. It MUST be possible for ENTITIES in one DOMAIN to interoperate 5.2.1. It MUST be possible for ENTITIES in one DOMAIN to interoperate
with ENTITIES in another DOMAIN, without the DOMAINS having previously with ENTITIES in another DOMAIN, without the DOMAINS having previously
been aware of each other. been aware of each other.
The protocol MUST continue to meet its other functional and The protocol MUST be capable of meeting its other functional and
performance requirements even when performance requirements even when
-- (5.2.2) there are millions of ENTITIES within a single DOMAIN. -- (5.2.2) there are millions of ENTITIES within a single DOMAIN.
-- (5.2.3) there are millions of DOMAINS within the single -- (5.2.3) there are millions of DOMAINS within the single
NAMESPACE. NAMESPACE.
-- (5.2.4) every single SUBSCRIBER has SUBSCRIPTIONS to hundreds -- (5.2.4) every single SUBSCRIBER has SUBSCRIPTIONS to hundreds
of PRESENTITIES. of PRESENTITIES.
-- (5.2.5) thousands of distinct SUBSCRIBERS have SUBSCRIPTIONS to -- (5.2.5) hundreds of distinct SUBSCRIBERS have SUBSCRIPTIONS to
a single PRESENTITY. a single PRESENTITY.
-- (5.2.6) every single SUBSCRIBER has SUBSCRIPTIONS to -- (5.2.6) every single SUBSCRIBER has SUBSCRIPTIONS to
PRESENTITIES in hundreds of distinct DOMAINS. PRESENTITIES in hundreds of distinct DOMAINS.
These are protocol design goals; implementations may choose to place
lower limits.
5.3. Access Control 5.3. Access Control
The PRINCIPAL controlling a PRESENTITY MUST be able to control The PRINCIPAL controlling a PRESENTITY MUST be able to control
-- (5.3.1) which WATCHERS can observe that PRESENTITY's PRESENCE -- (5.3.1) which WATCHERS can observe that PRESENTITY's PRESENCE
INFORMATION. INFORMATION.
-- (5.3.2) which WATCHERS can have SUBSCRIPTIONS to that -- (5.3.2) which WATCHERS can have SUBSCRIPTIONS to that
PRESENTITY's PRESENCE INFORMATION. PRESENTITY's PRESENCE INFORMATION.
skipping to change at line 251 skipping to change at line 281
-- (5.3.6) which other PRINCIPALS, if any, can read INSTANT MESSAGES from -- (5.3.6) which other PRINCIPALS, if any, can read INSTANT MESSAGES from
that INSTANT INBOX. that INSTANT INBOX.
5.3.7. Access control MUST be independent of presence: the PRESENCE 5.3.7. Access control MUST be independent of presence: the PRESENCE
SERVICE MUST be able to make access control decisions even when the SERVICE MUST be able to make access control decisions even when the
PRESENTITY is OUT OF CONTACT. PRESENTITY is OUT OF CONTACT.
5.4. Network Topology 5.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.
5.4.1. The protocol MUST allow the creation of a SUBSCRIPTION both 5.4.1. The protocol MUST allow the creation of a SUBSCRIPTION both
directly and via intermediaries, such as PROXIES. directly and via intermediaries, such as PROXIES.
5.4.2. The protocol MUST allow the sending of a NOTIFICATION both 5.4.2. The protocol MUST allow the sending of a NOTIFICATION both
directly and via intermediaries, such as PROXIES. directly and via intermediaries, such as PROXIES.
5.4.3. The protocol MUST allow the sending of an INSTANT MESSAGE both 5.4.3. The protocol MUST allow the sending of an INSTANT MESSAGE both
directly and via intermediaries, such as PROXIES. directly and via intermediaries, such as PROXIES.
5.4.4. The protocol proxying facilities and transport practices MUST 5.4.4. The protocol proxying facilities and transport practices MUST
allow ADMINISTRATORS ways to enable and disable protocol activity allow ADMINISTRATORS ways to enable and disable protocol activity
through existing and commonly-deployed FIREWALLS. through existing and commonly-deployed FIREWALLS. The protocol MUST
specify how it can be effectively filtered by such FIREWALLS.
5.5. Message Encryption and Authentication 5.5. Message Encryption and Authentication
5.5.1. The protocol MUST provide means to ensure confidence that a 5.5.1. The protocol MUST provide means to ensure confidence that a
received message (NOTIFICATION or INSTANT MESSAGE) has not been received message (NOTIFICATION or INSTANT MESSAGE) has not been
corrupted or tampered with. corrupted or tampered with.
5.5.2. The protocol MUST provide means to ensure confidence that a 5.5.2. The protocol MUST provide means to ensure confidence that a
received message (NOTIFICATION or INSTANT MESSAGE) has not been received message (NOTIFICATION or INSTANT MESSAGE) has not been
recorded and played back by an adversary. recorded and played back by an adversary.
5.5.3. The protocol MUST provide means to ensure that a sent message 5.5.3. The protocol MUST provide means to ensure that a sent message
(NOTIFICATION or INSTANT MESSAGE) is only readable by ENTITIES that (NOTIFICATION or INSTANT MESSAGE) is only readable by ENTITIES that
the sender allows. the sender allows.
5.5.4. The protocol MUST allow any client to use the means to ensure 5.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 non-corruption, non-playback, and privacy, but the protocol MUST NOT
require that all clients use these means at all times. require that all clients use these means at all times.
skipping to change at line 307 skipping to change at line 341
6.1.3. The common presence format MUST include a means to encapsulate 6.1.3. The common presence format MUST include a means to encapsulate
contact information for the PRESENTITY's PRINCIPAL (if applicable), contact information for the PRESENTITY's PRINCIPAL (if applicable),
such as email address, telephone number, postal address, or the like. such as email address, telephone number, postal address, or the like.
6.1.4. There MUST be a means of extending the common presence format 6.1.4. There MUST be a means of extending the common presence format
to represent additional information not included in the common format, to represent additional information not included in the common format,
without undermining or rendering invalid the fields of the common without undermining or rendering invalid the fields of the common
format. format.
6.1.5. The working group MUST define the extension and registration 6.1.5. The working group must define the extension and registration
mechanisms for presence information schema, including new STATUS mechanisms for presence information schema, including new STATUS
conditions and new forms for OTHER PRESENCE MARKUP. conditions and new forms for OTHER PRESENCE MARKUP.
6.1.6. The presence format SHOULD be based on IETF standards such as 6.1.6. The presence format SHOULD be based on IETF standards such as
vCard [RFC 2426] if possible. vCard [RFC 2426] if possible.
6.2. Presence Lookup and Notification 6.2. Presence Lookup and Notification
6.2.1. A FETCHER MUST be able to fetch a PRESENTITY's PRESENCE 6.2.1. A FETCHER MUST be able to fetch a PRESENTITY's PRESENCE
INFORMATION even when the PRESENTITY is OUT OF CONTACT. INFORMATION even when the PRESENTITY is OUT OF CONTACT.
skipping to change at line 384 skipping to change at line 418
receiver to reply to the sender with another INSTANT MESSAGE. receiver to reply to the sender with another INSTANT MESSAGE.
7.1.4. The common message format SHOULD include standard forms of 7.1.4. The common message format SHOULD include standard forms of
addresses or contact means for media other than INSTANT addresses or contact means for media other than INSTANT
MESSAGES, such as telephone numbers or email addresses. MESSAGES, such as telephone numbers or email addresses.
7.1.5. The common message format MUST permit the encoding and 7.1.5. The common message format MUST permit the encoding and
identification of the message payload to allow for non-ASCII or identification of the message payload to allow for non-ASCII or
encrypted content. encrypted content.
7.1.6. The working group MUST define the extension and registration 7.1.6. The protocol must reflect best current practices related to
internationalization.
7.1.7. The protocol must reflect best current practices related to
accessibility.
7.1.8. The working group MUST define the extension and registration
mechanisms for the message format, including new fields and new mechanisms for the message format, including new fields and new
schemes for INSTANT INBOX ADDRESSES. schemes for INSTANT INBOX ADDRESSES.
7.1.7. The working group MUST determine whether the common message format 7.1.9. The working group MUST determine whether the common message format
includes fields for numbering or identifying messages. If there includes fields for numbering or identifying messages. If there
are such fields, the working group MUST define the scope within which are such fields, the working group MUST define the scope within which
such identifiers are unique and the acceptable means of generating such identifiers are unique and the acceptable means of generating
such identifiers. such identifiers.
7.1.8. The common message format SHOULD be based on IETF-standard MIME 7.1.10. The common message format SHOULD be based on IETF-standard
[RFC 2045]. MIME [RFC 2045].
7.2. Reliability 7.2. Reliability
7.2.1. The protocol MUST include mechanisms so that a sender can be 7.2.1. The protocol MUST include mechanisms so that a sender can be
informed of the SUCCESSFUL DELIVERY of an INSTANT MESSAGE or reasons informed of the SUCCESSFUL DELIVERY of an INSTANT MESSAGE or reasons
for failure. The working group MUST determine what mechanisms apply for failure. The working group must determine what mechanisms apply
when final delivery status is unknown, such as when a message is when final delivery status is unknown, such as when a message is
relayed to non-IMPP systems. relayed to non-IMPP systems.
7.3 Performance 7.3 Performance
7.3.1. The transport of INSTANT MESSAGES SHOULD be sufficiently rapid to 7.3.1. The transport of INSTANT MESSAGES MUST be sufficiently rapid to
allow for comfortable conversational exchanges of short messages. allow for comfortable conversational exchanges of short messages.
7.4 Presence Format 7.4 Presence Format
7.4.1. The common presence format MUST define a minimum standard 7.4.1. The common presence format MUST define a minimum standard
presence schema suitable for INSTANT MESSAGE SERVICES. presence schema suitable for INSTANT MESSAGE SERVICES.
7.4.2. When used in a system supporting INSTANT MESSAGES, the common 7.4.2. When used in a system supporting INSTANT MESSAGES, the common
presence format MUST include a means to represent the STATUS presence format MUST include a means to represent the STATUS
conditions OPEN and CLOSED. conditions OPEN and CLOSED.
7.4.3. The STATUS conditions OPEN and CLOSED MAY also be applied to 7.4.3. The STATUS conditions OPEN and CLOSED may also be applied to
messaging or communication modes other than INSTANT MESSAGE SERVICES. messaging or communication modes other than INSTANT MESSAGE SERVICES.
8. Security Considerations 8. Security Considerations
Security considerations are addressed in section 5.3, Access Control, Security considerations are addressed in section 5.3, Access Control,
and section 5.5, Message authentication and encryption. and section 5.5, Message authentication and encryption.
This section describes further security-related requirements that the This section describes further security-related requirements that the
protocol must meet. protocol must meet.
The security requirements were derived from a set of all-encompassing The security requirements were derived from a set of all-encompassing
"security expectations" that were then evaluated for practicality and "security expectations" that were then evaluated for practicality and
implementability and translated into requirements. In the appendix, implementability and translated into requirements. In the appendix,
we describe the expectations and the process used to transform them we describe the expectations and the process used to transform them
into requirements. In this section, we simply list the consolidated into requirements. In this section, we simply list the consolidated
set of derived requirements. set of derived requirements.
Note that in the requirements, ADMINISTRATORs MAY have privileges Note that in the requirements, ADMINISTRATORs may have privileges
beyond those allowed to PRINCIPALs referred to in the requirements. beyond those allowed to PRINCIPALs referred to in the requirements.
(Unless otherwise noted, the individual expectations specifically (Unless otherwise noted, the individual expectations specifically
refer to PRINCIPALs.) It is up to individual implementations to refer to PRINCIPALs.) It is up to individual implementations to
control administrative access and implement the security privileges of control administrative access and implement the security privileges of
ADMINISTRATORs without compromising the requirements made on ADMINISTRATORs without compromising the requirements made on
PRINCIPALs. PRINCIPALs.
Unless noted otherwise, A,B,C are all names of non-ADMINISTRATOR Unless noted otherwise, A,B,C are all names of non-ADMINISTRATOR
PRINCIPALS. PRINCIPALS.
skipping to change at line 465 skipping to change at line 504
8.1.2. If A so chooses, the protocol SHOULD NOT make A's SUBSCRIPTION 8.1.2. If A so chooses, the protocol SHOULD NOT make A's SUBSCRIPTION
to B obvious to a third party C. to B obvious to a third party C.
8.1.3. The protocol MUST provide B with means of allowing an 8.1.3. The protocol MUST provide B with means of allowing an
unauthenticated subscription by A. unauthenticated subscription by A.
8.1.4. The protocol MUST provide A means of verifying the accurate 8.1.4. The protocol MUST provide A means of verifying the accurate
receipt of the content B chooses to disclose to A. receipt of the content B chooses to disclose to A.
8.1.5. B MUST inform A if B refuses A's SUBSCRIPTION. Note that B MAY 8.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 choose to accept A's SUBSCRIPTION, but fail to deliver any information
to it (so-called "polite blocking"). See 8.1.15. to it (so-called "polite blocking"). See 8.1.15.
8.1.6. The protocol MUST NOT let any third party C force A to subscribe 8.1.6. The protocol MUST NOT let any third party C force A to subscribe
to B's PRESENCE INFORMATION without A's consent. to B's PRESENCE INFORMATION without A's consent.
8.1.7. A MUST be able to cancel her SUBSCRIPTION to B's PRESENCE 8.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 INFORMATION at any time and for any reason. When A does so, the
PRESENCE SERVICE stops informing A of changes to B's PRESENCE PRESENCE SERVICE stops informing A of changes to B's PRESENCE
INFORMATION. INFORMATION.
8.1.8. The protocol MUST NOT let a third party C cancel A's 8.1.8. The protocol MUST NOT let an unauthorized party C cancel A's
SUBSCRIPTION to B. SUBSCRIPTION to B.
8.1.9. If A's SUBSCRIPTION to B is cancelled, the service SHOULD inform 8.1.9. If A's SUBSCRIPTION to B is cancelled, the service SHOULD inform
A of the cancellation. A of the cancellation.
8.1.10. A SHOULD be able to determine the status of A's SUBSCRIPTION to 8.1.10. A SHOULD be able to determine the status of A's SUBSCRIPTION to
B, at any time. B, at any time.
8.1.11. The protocol MUST provide B means of learning about A's 8.1.11. The protocol MUST provide B means of learning about A's
SUBSCRIPTION to B, both at the time of establishing the SUBSCRIPTION SUBSCRIPTION to B, both at the time of establishing the SUBSCRIPTION
skipping to change at line 522 skipping to change at line 560
8.2. Requirements related to NOTIFICATION 8.2. Requirements related to NOTIFICATION
When a PRINCIPAL B publishes PRESENCE INFORMATION for NOTIFICATION to When a PRINCIPAL B publishes PRESENCE INFORMATION for NOTIFICATION to
another PRINCIPAL A: another PRINCIPAL A:
8.2.1. The protocol MUST provide means of ensuring that only the 8.2.1. The protocol MUST provide means of ensuring that only the
PRINCIPAL A being sent the NOTIFICATION by B can read the PRINCIPAL A being sent the NOTIFICATION by B can read the
NOTIFICATION. NOTIFICATION.
8.2.2. A SHOULD receive all NOTIFICATIONS intended for her. 8.2.2. A should receive all NOTIFICATIONS intended for her.
8.2.3. It MUST be possible for B to prevent A from receiving 8.2.3. It MUST be possible for B to prevent A from receiving
notifications, even if A is ordinarily permitted to see such notifications, even if A is ordinarily permitted to see such
notifications. It MUST be possible for B to, at its choosing, notify notifications. It MUST be possible for B to, at its choosing, notify
different subscribers differently, through different notification different subscribers differently, through different notification
mechanisms or through publishing different content. This is a mechanisms or through publishing different content. This is a
variation on "polite blocking". variation on "polite blocking".
8.2.4. The protocol MUST provide means of protecting B from another 8.2.4. The protocol MUST provide means of protecting B from another
PRINCIPAL C "spoofing" notification messages about B. PRINCIPAL C "spoofing" notification messages about B.
skipping to change at line 577 skipping to change at line 614
8.4.5. The protocol MUST NOT always require A to reveal A's IP 8.4.5. The protocol MUST NOT always require A to reveal A's IP
address, for A to send an instant message. address, for A to send an instant message.
8.4.6. The protocol MUST provide A means of ensuring that no other 8.4.6. The protocol MUST provide A means of ensuring that no other
PRINCIPAL C can see the content of M. PRINCIPAL C can see the content of M.
8.4.7. The protocol MUST provide A means of ensuring that no other 8.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 PRINCIPAL C can tamper with M, and B means to verify that no tampering
has occurred. has occurred.
8.4.8. B MUST be able to read M. 8.4.8. B must be able to read M.
8.4.9. The protocol MUST allow A to sign the message, using existing 8.4.9. The protocol MUST allow A to sign the message, using existing
standards for digital signatures. standards for digital signatures.
8.4.10. B MUST be able to prevent A from sending him messages 8.4.10. B MUST be able to prevent A from sending him messages
9. References 9. References
[Aggarwal et al., 1998] [Aggarwal et al., 1998]
S. Aggarwal, M. Day, G. Mohr, "Presence Information Protocol S. Aggarwal, M. Day, G. Mohr, "Presence Information Protocol
skipping to change at line 618 skipping to change at line 655
(MIME) - Part One: Format of Internet Message Bodies." RFC 2045, (MIME) - Part One: Format of Internet Message Bodies." RFC 2045,
November 1996. November 1996.
[RFC 2119] [RFC 2119]
S. Bradner. "Key Words for Use in RFCs to Indicate Requirement S. Bradner. "Key Words for Use in RFCs to Indicate Requirement
Levels." RFC 2119, March 1997. Levels." RFC 2119, March 1997.
10. Authors' Addresses 10. Authors' Addresses
Mark Day Mark Day
<Mark_Day@lotus.com> <mday@alum.mit.edu>
Lotus Development Corporation SightPath, Inc.
55 Cambridge Parkway 135 Beaver Street
Cambridge, MA 02142 Waltham, MA 02452
USA USA
(Formerly Mark_Day@lotus.com)
Sonu Aggarwal Sonu Aggarwal
<sonuag@microsoft.com> <sonuag@microsoft.com>
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA USA
Gordon Mohr Gordon Mohr
<gojomo@activerse.com> <gojomo@usa.net>
Activerse, Inc. (Formerly gojomo@activerse.com>
1301 W. 25th St Suite 500
Austin, TX 78705
USA
Jesse Vincent Jesse Vincent
<jesse@arepa.com> <jesse@arepa.com>
Arepa, Inc. Arepa, Inc.
100 Cambridgepark Drive 100 Cambridgepark Drive
Cambridge, MA 02140 Cambridge, MA 02140
USA USA
(Formerly jvincent@microsoft.com)
11. Appendix: Security Expectations and Deriving Requirements 11. Appendix: Security Expectations and Deriving Requirements
This appendix is based on the security expectations discussed on the This appendix is based on the security expectations discussed on the
impp mailing list and assembled by Jesse Vincent. The original form impp mailing list and assembled by Jesse Vincent. The original form
of numbering has been preserved in this appendix (so there are several of numbering has been preserved in this appendix (so there are several
different items labeled B1, for example). The derived requirements different items labeled B1, for example). The derived requirements
have new numbers that are consistent with the main body of the have new numbers that are consistent with the main body of the
document. This appendix is included to provide a connection from document. This appendix is included to provide a connection from
discussions on the list to the requirements of Section 8, but it is discussions on the list to the requirements of Section 8, but it is
 End of changes. 33 change blocks. 
38 lines changed or deleted 75 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/