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-lpidf-00.txt June 15, 2000 Expires: December, 2000 A Lightweight Presence Information Format (LPIDF) 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 This document describes a data format, the Lightweight Presence Information Data Format (LPIDF) for conveying presence information. The format is based on RFC822 encoding of presence data. In fact, this encoding is exactly identical to the encoding used by the Session Initiation Protocol (SIP) in its registration messages. This simplifies the process of parsing and processing presence data in clients which use SIP for presence or communications services. LPIDF is one instantiation of an abstract presence data model also described here. 1 Introduction Presence is (indirectly) defined in RFC2778 [1] as subscription to and notification of changes in the communications state of a user. Rosenberg et. al. [Page 1] Internet Draft LPIDF June 15, 2000 This communications state consists of the set of communications means, communications address, and status of that user. A presence document is a computer readable piece of data that contains this presence information. Presence documents are conveyed by a presence protocol [2], but may also be conveyed out of bands. The presence documents are useful and complete in and of themselves, and do not rely on information conveyed by their transfer means in order to be useful. It is fundamental to our notion of presence that a single presentity is represented by a multitude of presence user agents (PUAs), each of which generates presence information for a particular subset of the overall presence state of a presentity. This results in the requirement of a definition of an abstract presence data model, which defines how these presence components are combined to yield a complete presence document. This data model is, in fact, independent of the presence data format itself. An alternative presence data format, the Presence Information Data Format (PIDF) [3], defines this abstract data model. LPIDF is based on an RFC822 encoding of presence data. This encoding is identical to the way the data is carried in the Session Initiation Protocol (SIP) [4] REGISTER messages, used for communications establishment and for presence [2]. This makes parsing and processing of this data easier, as the tools for doing so are already part of the device performing the processing. 2 LPIDF Format In SIP REGISTER messages, the Contact header is used to contain information on the current location of a user. In addition, the SIP extension for caller preferences and callee capabilities [5] contains additional parameters that can be added to the Contact header to further qualify the status and capabilities of that location. For example, an address can be defined as mobile, or as a business address. Preferences can also be assigned using a priority value. Notes can also be attached to URLs, conveying textual messages for display. Furthermore, SIP REGISTER messages convey the identity of the user for whom these Contact addresses pertain. That identity is carried in the To field of the request. We note that this identity is the identity of the presentity. As such, we define LPIDF simply as a document that contains the To and Contact addresses from a SIP registration. We can express this in BNF as follows: Rosenberg et. al. [Page 2] Internet Draft LPIDF June 15, 2000 LPIDF = To CRLF *(Contact CRLF) where To and Contact are defined in Sections 6.37 and 6.13 of RFC2543 [4] respectively. The Contact BNF is extended by the one defined in [5]. Note that the caller preferences specification defines a parameter, q, which represents a relative priority for using an address. A value of 0 means the address should not be used. Therefore, we can support the OPEN status, defined in [1] through a q value that is not zero, and CLOSED through a zero q value. An LPIDF document is identified by the MIME type text/lpidf. 3 Example The following is an example of a valid LPIDF document: To: sip:presentity@example.com Contact: sip:presentity@example.com;methods="INVITE,BYE,OPTIONS"; mobility=fixed;features="voicemail" Contact: mailto:presentity@example.com Contact: http://www.example.com 4 Mapping to the model PIDF [3] contains a description of a model for presence data, independent of the particular encoding. This section discusses how we map this data format to the model. Each Contact address is a separate atom. The ID for the atom is computed as an MD5 hash over the URI. Expirations can be conveyed using the expires Contact parameter. So, to combine two presence documents for the same presentity (i.e., the To values are the same), you simply merge the set of Contacts from each presence document, discarding ones with the same URI. For example, if presence document A looks like: To: sip:presentity@example.com Contact: sip:presentity@example.com;methods="INVITE,BYE,OPTIONS"; Rosenberg et. al. [Page 3] Internet Draft LPIDF June 15, 2000 mobility=fixed;features="voicemail" Contact: mailto:presentity@example.com and presence document B looks like: To: sip:presentity@example.com Contact: http://www.example.com The merged document is the example given in Section 3. 5 Transfer in a presence protocol The presence protocol [2] provides sequencing of notifications, through the CSeq header. When two notifications come from the same source (the To, From, and Call-ID are the same), the presence data MAY be ordered based on the CSeq ordering. If the notifications come from different sources, the temporal order of delivery is used to determine ordering. 6 Evaluation against Requirements The following section indicates how this proposal meets the requirements outlined in RFC2779 [6]. Requirement 3.1.2: The common presence format MUST include a means to uniquely identify the PRESENTITY whose PRESENCE INFORMATION is reported. This is supported through the To header in LPIDF. Requirement 3.1.3: The common presence format MUST include a means to encapsulate contact information for the PRESENTITY's PRINCIPAL (if applicable), such as email address, telephone number, postal address, or the like. This is supported through the Contact headers in LPIDF. Requirement 3.1.4: There MUST be a means of extending the common presence format to represent additional information not included in the common format, without undermining or rendering invalid the fields of the common format This is supported through the standard extension mechanisms defined for the SIP Contact header. Rosenberg et. al. [Page 4] Internet Draft LPIDF June 15, 2000 Requirement 3.1.5: The working group must define the extension and registration mechanisms for presence information schema, including new STATUS conditions and new forms for OTHER PRESENCE MARKUP. This is readily accomplished, although not specified in this version of the document. Requirement 3.1.6: The presence format SHOULD be based on IETF standards such as vCard [RFC 2426] if possible. The format is based on SIP, IETF proposed standard RFC2543 [4], which in turn is based on HTTP [7] and email [8]. Requirement 4.4.1: The common presence format MUST define a minimum standard presence schema suitable for INSTANT MESSAGE SERVICES. This is supported through a URL corresponding to an instant message. This URL, as proposed in [9] is of the form sip:user@host;method=SUBSCRIBE. This URL is then included in a Contact header. Requirement 4.4.2: When used in a system supporting INSTANT MESSAGES, the common presence format MUST include a means to represent the STATUS conditions OPEN and CLOSED. Open is represented by a non-zero value of the q parameter (which specifies preference). Closed is represented by a zero value of the q parameter. Requirement 4.4.3: The STATUS conditions OPEN and CLOSED may also be applied to messaging or communication modes other than INSTANT MESSAGE SERVICES. The presence document here applies the q value to any communications means. IM is not treated differently than any other. 7 Authors Addresses Jonathan Rosenberg dynamicsoft 200 Executive Drive Suite 120 West Orange, NJ 07052 email: jdrosen@dynamicsoft.com Dean Willis dynamicsoft 200 Executive Drive Rosenberg et. al. [Page 5] Internet Draft LPIDF June 15, 2000 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 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 Rosenberg et. al. [Page 6] Internet Draft LPIDF June 15, 2000 email: dgurle@microsoft.com 8 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] J. Rosenberg, R. Sparks, D. Willis, B. Campbell, H. Schulzrinne, J. Lennox, C. Huitema, B. Aboba, and D. Gurle, "A data format for presence using XML," Internet Draft, Internet Engineering Task Force, June 2000. Work in progress. [4] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol," Request for Comments 2543, Internet Engineering Task Force, Mar. 1999. [5] H. Schulzrinne and J. Rosenberg, "SIP caller preferences and callee capabilities," Internet Draft, Internet Engineering Task Force, Mar. 2000. Work in progress. [6] M. Day, S. Aggarwal, G. Mohr, and J. Vincent, "Instant messaging / presence protocol requirements," Request for Comments 2779, Internet Engineering Task Force, Feb. 2000. [7] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, and L. Stewart, "HTTP authentication: Basic and digest access authentication," Request for Comments 2617, Internet Engineering Task Force, June 1999. [8] D. Crocker, "Standard for the format of ARPA internet text messages," Request for Comments 822, Internet Engineering Task Force, Aug. 1982. [9] J. Rosenberg, R. Sparks, D. Willis, B. Campbell, H. Schulzrinne, J. Lennox, C. Huitema, B. Aboba, and D. Gurle, "SIP extensions for instant messaging," Internet Draft, Internet Engineering Task Force, June 2000. Work in progress. Rosenberg et. al. [Page 7]