SIMPLE B. Campbell
Internet-Draft dynamicsoft
Expires: August 12, 2003 S. Olson
Microsoft
J. Peterson
NeuStar, Inc.
J. Rosenberg
dynamicsoft
B. Stucker
Nortel Networks, Inc.
February 11, 2003
SIMPLE Presence Publication Requirements
draft-ietf-simple-publish-reqs-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 12, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes requirements for an extension to the Session
Initiation Protocol (SIP) [1]. The purpose of this extension would
be to create a means for publishing event state used within the
framework for SIP Event Notification (RFC3265 [2]). The first
Campbell, et al. Expires August 12, 2003 [Page 1]
Internet-Draft SIMPLE Pub Reqs February 2003
application of this extension is targeted at the publication of
presence information as defined by the SIMPLE [5] working group.
1. Introduction
1.1 Publication Model
The following sections outline a model for publication of event
state, in particular presence information. This model further
defines the problem that this mechanism is attempting to solve.
The method described in this document allows presence information to
be published to a presence agent on behalf of a user. This method
can be extended to support publication of other event state, but it
is not intended to be a general-purpose mechanism for transport of
arbitrary data as there are better suited mechanisms for this purpose
(ftp, http, etc.) This method is intended to be a simple, light-
weight mechanism that employs SIP in order to support SIMPLE
services.
1.1.1 Presence Composition
Most existing presence services involve a single PUA that has
complete presence for a given presentity. This allows for a very
simple model where that PUA sends full presence state to a PA, which
then distributes it to watchers.
But this is a limited view of presence. In general, the presence
state of a presentity may be derived from many different inputs. A
complete view of presence for a presentity is likely to be derived
from more than one source, where the the complete view of presence
state is composed of the presence state from each source. Therefore,
any given PUA is unlikely to be able to provide complete presence
information. This document proposes a logical model for publishing
presence information from multiple PUAs to a presence compositor,
that can act as a presence agent.
Presence composition is a logical function in a presence distribution
system. This function is fulfilled by a logical element known as a
"presence compositor". A presence compositor accepts presence inputs
from one or more PUAs, and composes these inputs into a composite
presence document.
Campbell, et al. Expires August 12, 2003 [Page 2]
Internet-Draft SIMPLE Pub Reqs February 2003
+-----------------+ +----------+
| Presence | | Presence |
| Compositor +------+ Agent |
| | | |
| | | |
+--------+--------+ +----------+
|
|
+----------+---------+
| | |
| | |
+--+--+ +--+--+ +--+--+
| PUA | | PUA | | PUA |
+-----+ +-----+ +-----+
Each PUA publishes its view of presence to the Presence Compositor,
which then relays the composed presence information to a presence
agent for distribution. It must be possible for each PUA publishes a
full view of presence from its perspective--each publication carries
full state, and does not depend on previous states for the particular
PUA. A PUA does not need to know whether or not other PUAs are also
publishing presence information to the compositor.
The transformations that a presence compositor uses for this
composition are entirely a matter of local policy. The policy could
be as simple as the creation of a combined CPIM PIDF [4] document
where each input represents a separate tuple. It can also involve
more complex transformations, such as modifying the information from
one source based on information from another source.
1.1.2 Interface between the Compositor and the PA
The interface between a compositor and a PA is also a matter of local
policy. The compositor might act as a PUA itself, and publish
presence to the PA just like any other PUA might. The compositor and
the PA may be co-located, and communicate via local procedure calls.
Specification of this interface is beyond the scope of this document.
1.2 Why use SIP for publication?
Two principal protocol candidates have been evaluated for presence
state publication from a PUA to a presence compositor: HTTP and SIP.
This document recommends the use of SIP for presence publication for
the following reasons.
Campbell, et al. Expires August 12, 2003 [Page 3]
Internet-Draft SIMPLE Pub Reqs February 2003
1.2.1 HTTP
HTTP is well suited for moving data around in the form of MIME body
parts. An HTTP client-to-server publication solution would not
require much work to specify. A SOAP over HTTP solution would
additionally allow complex transaction semantics with little
additional work. HTTP, however, does not have a well-defined routing
model at the application level. It works fine if the publication
point is well known and fairly static, but it will require additional
work to deal with situations where the publication point changes
dynamically.
1.2.2 SIP
SIP, on the otherhand, is built around the concept of mobility of
endpoints. The SIP proxy, registrar, and location service concepts
provide a rich mechanism of finding a dynamically changing endpoint
from and address of record. The application-level routing
capabilities of SIP can be very useful for presence publication. If
all PUAs for a given presentity exist in the same administrative
domain, then they can most likely publish directly to a compositor.
But if PUAs exist outside the administrative domain, it is likely
they will not be able to do so.
For example, suppose that Alice uses a presence service that allows
multiple PUAs to publish to a compositor inside the service provider
network. Further suppose that Alice wishes to incorporate presence
information from an external provider, that has no business
relationship with her primary provider. For this example, Alice
wishes to use a shared browsing service that tracks the "location"
she is currently browsing in the web. That service acts as a PUA on
Alice's behalf, and publishes the information to her primary presence
provider. Other users of the shared browsing service can subscribe
to her presence information, and determine when they are browsing the
same site.
The presence provider is highly unlikely to allow the external PUA to
send data directly to the compositor. But if Alice registers a
contact with a methods parameter value of "PUBLISH", that PUA can
send a publish request to an edge proxy in the presence providers
network, and use Alice's address of record as the requestURI. This
AoR could be her normal SIP URI, or it could be a special AoR for the
purposes of presence publication. The proxy forwards the request to
the compositor, without the external PUA having to talk directly to
the compositor, or even know its IP address.
Now consider that Alice's primary providor is actually an enterprise.
That enterprise has different compositors for different departments.
Campbell, et al. Expires August 12, 2003 [Page 4]
Internet-Draft SIMPLE Pub Reqs February 2003
The external provider has no way of knowing this internal
organization, nor does it know what department Alice works in.
Still, Alice register's her publication contact at an enterprise
registrar, the external provider sends the publish request to Alice's
address of record, and the companies internal SIP network handles
things from there, eventually getting the request to the correct
compositor.
The composition model does not at first appear to require publishing
to dynamically changing PAs. But a very powerful, but often
forgotten, aspect of SIMPLE is it allows a PA to exist on an end-user
device. Indeed, some early implentations of SIMPLE rely on exactly
that model. It is reasonable to expect the composition model above
to co-exist with end-user device PAs, where the PA location changes
dynamically.
For example, imagine Alice hosts a PA on her PC, which aquires its IP
address via DHCP. This address changes relatively frequently, and
registers a publish contact with an enterprise registrar. Now,
imagine she also has a mobile phone which contains a PUA. She wants
her presence document to show a combined view of her PCs concept of
her presence and her mobile phone service's concept of her precence.
She cannot simply tell the mobile service her PC address since it
changes often. Instead, she tells the service an AoR to publish
presence to. The mobile service publishes presence state to that
AoR, which resolves to a SIP proxy or redirect server. Normal SIP
proxy or redirect behavior is invoked to get the publication to
Alice's PC based on her publish contact registration.
1.2.3 Conclusions
It is our opinion that SIP style routing is very useful for presence
publication. Without the application level routing capabilities of
SIP, it would be difficult to build these sort of services. It is
more appropriate to add a publication mechanism to SIP than to
standardize SIP-style routing features for HTTP proxies.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3].
3. Publication Requirements
Any presence publication mechanism for SIP must meet the following
requirements.
Campbell, et al. Expires August 12, 2003 [Page 5]
Internet-Draft SIMPLE Pub Reqs February 2003
1. The presence publication mechanism must provide a way for a PUA
to publish presence to a presence compositor.
2. The presence publication mechanism must define a new SIP method
for presence publication, or describe how some existing method
can perform this function.
3. The presence publication mechanism must define a mandatory-to-
implement format for expressing presence information. This
format must have a registered MIME type. It is recommended that
this format be the Presence Information Data Format [4]. Other
formats in addition to the single mandatory-to-implement format
may be suggested.
4. The publication mechanism must support the simultaneous
publication from several distinct PUAs of presence information
concerning the same presentity.
5. The publication mechanism must allow for the fact that any
individual PUA may not know the total presence state of the
user. Publications from any given PUA may contain only part of
the total presence of the presentity.
6. It must be possible to order a published sequence of presence
information originating from a particular PUA.
7. It must be possible for a compositor to reject a publication
request.
8. The publication mechanism must support a means for a presence
compositor to compose presence information received from
multiple PUAs at different times into a single presence
document. The compositor function must be able to detect and
reconcile conflicts or overlaps in publications from different
PUAs.
9. The publication mechanism must support a means for large content
to be sent as a part of presence information.
10. It must be possible for a PUA to send full presence information
(all of the presence information that the PUA knows about a
presentity) in a publication, and there should also be a way for
PUAs to send partial or incremental presence information.
11. The publication mechanism must support a way to uniquely
identify segments of presence information (for example, the
tuple elements in PIDF are uniquely identified by a tuple ID).
Campbell, et al. Expires August 12, 2003 [Page 6]
Internet-Draft SIMPLE Pub Reqs February 2003
12. There must be a way to uniquely identify segments of presence
information for a particular presentity that is independent of
the PUA that generated this segment. The tuple identifier from
PIDF is an example of such a unique identifier.
13. The publication mechanism must allow two PUAs to publish
information for the same segment of presence information.
14. PUAs must have a capability that allows them to query for the
identifiers of all of the segments of presence information that
have currently been published for a presentity (provided that
the PUA is authorized to receive this information).
15. It must be possible for the publication of presence information
for a particular segment to overwrite existing information for
that segment, even if the existing information had been
published by a different PUA. Overwrites could occur, for
example, on the basis of a timestamp indicating when the segment
was last modified (i.e. more recent segments overwrite older
segments).
16. There must be a way for a compositor to reject a published
segment of presence information from a PUA because the segment
has been replaced by one published by another PUA.
17. It must be possible for a compositor to authenticate a publisher
of presence information.
18. The presence publication architecture must support a means for
principals to authorize the disclosure of segments of presence
information to particular watchers.
19. There must be a way for a publisher to tell a presence agent
that a piece of published presence should be passed on to
watchers without modification.
4. IANA Considerations
This document introduces no considerations for IANA.
5. Security Considerations
A presence compositor should authenticate publishing User Agents, and
may apply authorization policies. The composition model makes no
assumptions that all input sources for a compositor are on the same
network, or in the same administrative domain.
Campbell, et al. Expires August 12, 2003 [Page 7]
Internet-Draft SIMPLE Pub Reqs February 2003
Authorization of watchers becomes more complicated in a presence
publication architecture. Principals should have some way to manage
the authorization of watchers who wish to published presence
information. Since they may not directly control the presence agent
to which watchers subscribe, this introduces some mechanism
requirements.
The compositor should throttle incoming publications and the
corresponding notifications resulting from the changes in event
state. As a first step careful selection of default Expires: values
for the supported event packages at a compositor can help limit
refreshes of event state. Additional throttling and debounce logic
at the compositor is advisable to further reduce the notification
traffic produced as a result of a PUBLISH method.
6. Acknowledgments
The authors would like to thank Krisztian Kiss and Aki Niemi for
their suggestions.
Normative References
[1] Rosenberg, J., Schulzrinne, Camarillo, Johnston, Peterson,
Sparks, Handley and Schooler, "SIP: Session Initiation
Protocol", RFC 3261, June 2002.
[2] Roach, A., "Session Initiation Protocol(SIP)-Specific Event
Notification", RFC 3265, June 2002.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[4] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and
J. Peterson, "Common Presence and Instant Messaging (CPIM)
Presence Information Data Format", draft-ietf-impp-cpim-pidf-07
(work in progress), May 2002.
[5] <http://www.ietf.org/html.charters/simple-charter.html>
Campbell, et al. Expires August 12, 2003 [Page 8]
Internet-Draft SIMPLE Pub Reqs February 2003
Authors' Addresses
Ben Campbell
dynamicsoft
5100 Tennyson Parkway
Suite 1200
Plano, TX 75025
US
EMail: bcampbell@dynamicsoft.com
Sean Olson
Microsoft
One Microsoft Way
Redmond, WA 98052
US
Phone: +1-425-707-2846
EMail: seanol@microsoft.com
URI: http://www.microsoft.com/rtc
Jon Peterson
NeuStar, Inc.
1800 Sutter St
Suite 570
Concord, CA 94520
US
Phone: +1-925-363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz
Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
US
EMail: jdrosen@dynamicsoft.com
Campbell, et al. Expires August 12, 2003 [Page 9]
Internet-Draft SIMPLE Pub Reqs February 2003
Brian Stucker
Nortel Networks, Inc.
2380 Performance Drive
Richardson, TX 75082
US
EMail: bstucker@nortelnetworks.com
Campbell, et al. Expires August 12, 2003 [Page 10]
Internet-Draft SIMPLE Pub Reqs February 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Campbell, et al. Expires August 12, 2003 [Page 11]
