Internet Draft Internet Engineering Task Force IMPP WG Internet Draft Jonathan Rosenberg Dean Willis Robert Sparks Ben Campbell dynamicsoft Henning Schulzrinne Jonathan Lennox Columbia U. Bernard Aboba Christian Huitema David Gurle Microsoft draft-rosenberg-impp-watcherinfo-00.txt June 15, 2000 Expires: December, 2000 An XML Based Format for Watcher Information 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. Abstract Watchers are defined as entities that request (i.e., subscribe to) presence information about a user. There is fairly complex state associated with this subscription, and this state is dynamic. As a result, it is possible, and indeed useful, to subscribe to the watcher information for a particular subscriber. In order to enable this, a format is needed to describe the state of watchers. This specification describes an XML document format for such state. 1 Introduction Presence is (indirectly) defined in RFC2778 [1] as subscription to and notification of changes in the communications state of a user. This communications state consists of the set of communications means, communications address, and status of that user. A presence Rosenberg, et. al. [Page 1] Internet Draft Watcher Info June 15, 2000 protocol is a protocol for providing such a service over the Internet or any IP network. Such a protocol is described in [2]. While the focus on presence is the state associated with the communications capabilities and means of a presentity, it is not the only type of state that is important in a complete presence solution. Another piece of state, watcher information, is also needed. Watcher information is the state associated with the subscriptions of watchers (watcher is a generalization of subscriber. A user who fetches content is a watcher, but not a subscriber) for a particular presentity. This state contains dynamic elements, such as whether the subscription is pending or granted, and when the last update was sent to that subscriber. As with any other state that changes, the presence protocols allow users to subscribe to this state and receive notifications about changes in the state. The ability to fetch watcher information is also useful for learning about who is currently subscribed to you, as a presentity of the system. System administrators might also like to know when a subsriber is added to the system for a particular presentity. To support subscriptions and notifications of changes in watcher information, a format for describing watcher information is needed. This specification provides such a format. The format contains numerous parameters related to watcher information. As the data can be complex and structure, and will often be useful to render to end users, we have chosen to represent it with XML. 2 Structure of Watcher Information Watcher information is an XML document that begins with the root element tag "watcherinfo". It consists of any number of "presentity" sub-elements, describing all the presentities being watched. Each presentity element has an attribute giving the URI at which the watching subscribers subscribed to the presentity; it contains as sub-elements a list of the watchers watching this presentity. Rosenberg, et. al. [Page 2] Internet Draft Watcher Info June 15, 2000 The watcher element describes a user watching the enclosing presentity. The mandatory attributes of the watcher element are: uri: The identity of the watcher, expressed as a URI. In the protocol described in [2], this is the URI from the From header of the SUBSCRIBE request. status: The status of the subscription. Possible values are "pending" if the subscription is awaiting approval, "active" if the subscription is approved and active, and "rejected" if it has been rejected. There are also two optional, informative attributes of the watcher element. These are: first-subscribed: The date and time, expressed as an integral number of seconds since January 1, 1970, 00:00 UTC, when the very first SUBSRIBE by this watcher for this presentity was sent. This date and time remains unchanged even if the subscription expires and is later refreshed. most-recently-subscribed: The date and time, also expressed as seconds since January 1 1970, when the subscription was most recently refreshed. This is only relevant for current subscriptions. The watcher element may contain a list of addresses at which a particular watcher has asked to be notified. This address is expressed as a URI. There can be more than one of Rosenberg, et. al. [Page 3] Internet Draft Watcher Info June 15, 2000 these, if the watcher has requested more than one notification address. For the protocol described in [2], these are the addresses from the Contact header in the SUBSCRIBE request. The number of watchers present for each presentity, and the set of presentities listed, depends on the type of data being provided, and to whom. In the case where a watcher has asked for notification of approval of their subscription, the watcher list contains only the watcher information for that one watcher, for that one presentity. In the case where a user wishes to find out the list of users subscribed to his presentity, the list contains multiple watchers for a single presentity. In the case where an administrator wishes to learn the current status in the system, the list contains all watchers for all presentities. Which case to use depends on either modifiers to the subscription described in the body of the SUBSCRIBE, or policy information configured at the presence agent. 3 Document Identifiers A watcher information document which appears as a top-level XML document is identified with the formal public identifier "- //IETF//DTD RFCxxxx XWATCHER 1.0//EN". If this document is published as an RFC, "xxxx" will be replaced by the RFC number. Watcher lists have the MIME type "application/xwatcher+xml". The "+xml" component of the type name conforms with the format of XML MIME types introduced by Murata et al [3]; this allows XML-aware but watcherlist-unaware rendering tools to display watcher lists usefully. A watcher list embedded as a fragment within another XML document is identified with the XML namespace identifier "http://www.ietf.org/internet-drafts/draft-rosenberg-impp- watcherinfo-00.txt". If this document is published as an RFC, the namespace identifier will be "http://www.rfc- editor.org/rfc/rfcxxxx.txt", where xxxx is the RFC number. Note that the URIs specifying XML namespaces are only globally unique names; they do not have to reference any particular actual object. The URI of a canonical source of this specification meets the requirement of being globally unique, and is also useful to document the format. 4 Example The following is an example of watcher information for a presentity, Rosenberg, et. al. [Page 4] Internet Draft Watcher Info June 15, 2000 who is a professor. There are two watchers, one from a university, and another from an organization.5 Subscribing to watcher information The protocol for presence described in [2] can be used to subscribe to watcher information. This is accomplished by definining a namespace that corresponds to watcher information for a particular presentity, and than placing a name within that namespace within the request URI of the SUBSCRIBE request. Our proposal for the namespace construction is: watcher-URL = "sip:" watcher "%40" presentity "@" hostport watcher = 1*(token | escaped) presentity = 1*(token | escaped) The watcher is a URL-encoded version of the identity of the watcher, and the presentity is a URL encoded version of the identify of the presentity, both only containing the username and hostname. For example, if the watcher is joe@ex.com, and the presentity is user@un.edu, the URL used to subscribe to joe's watcher information about user is: sip:joe%40ex.com%40user%40un.edu@un.edu Rosenberg, et. al. [Page 5] Internet Draft Watcher Info June 15, 2000 To subscribe to this information, the SUBSCRIBE would look like: SUBSCRIBE sip:joe%40ex.com%40user%40un.edu@un.edu SIP/2.0 Via: SIP/2.0/UDP mypc.ex.com From: sip:joe@ex.com To: sip:joe%40ex.com%40user%40un.edu@un.edu Call-ID: 9hsdasd@1.2.3.4 CSeq: 1 SUBSCRIBE Accept: application/xwatcher+xml Note that the subscription indicates that this format defined here is required in the response and in notifications. 6 XML DTD Rosenberg, et. al. [Page 6] Internet Draft Watcher Info June 15, 2000 7 Security Considerations Watcher information is sensitive information. The protocol used to distribute it SHOULD ensure privacy, message integrity and authentication. Furthermore, the protcol should provide access controls which restrict who can see who elses watcher information. 8 Authors Addresses Jonathan Rosenberg dynamicsoft 200 Executive Drive Suite 120 West Orange, NJ 07052 email: jdrosen@dynamicsoft.com Dean Willis dynamicsoft 200 Executive Drive Suite 120 West Orange, NJ 07052 email: dwillis@dynamicsoft.com Robert Sparks dynamicsoft 200 Executive Drive Suite 120 West Orange, NJ 07052 email: rsparks@dynamicsoft.com Ben Campbell dynamicsoft 200 Executive Drive Suite 120 West Orange, NJ 07052 email: bcampbell@dynamicsoft.com Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003 email: schulzrinne@cs.columbia.edu Jonathan Lennox Columbia University M/S 0401 Rosenberg, et. al. [Page 7] Internet Draft Watcher Info June 15, 2000 1214 Amsterdam Ave. New York, NY 10027-7003 email: lennox@cs.columbia.edu Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 email: huitema@microsoft.com Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 email: bernarda@microsoft.com David Gurle Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 email: dgurle@microsoft.com 9 Bibliography [1] M. Day, J. Rosenberg, and H. Sugano, "A model for presence and instant messaging," Request for Comments 2778, Internet Engineering Task Force, Feb. 2000. [2] J. Rosenberg, R. Sparks, D. Willis, B. Campbell, H. Schulzrinne, J. Lennox, C. Huitema, B. Aboba, and D. Gurle, "SIP extensions for presence," Internet Draft, Internet Engineering Task Force, June 2000. Work in progress. [3] M. Murata and S. S. Laurent, "XML media types," Internet Draft, Internet Engineering Task Force, Jan. 2000. Work in progress. Rosenberg, et. al. [Page 8]