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-buddylist-00.txt June 15, 2000 Expires: December, 2000 An XML Format for Presence Buddy Lists 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 defines an XML format for a buddy list, which represents a list of other users a particular user would like to subscribe to. When a presence client starts up, it needs to initiate subscriptions to the users on the buddy list. By keeping this list in a standard XML format, the list can be stored locally, or retrieved remotely using HTTP or any other transfer protocol. The great advantage of storing it remotely is that a user can move from machine to machine, fetch their buddy list from a home server, and then subscribe to those users. This provides personal mobility for presence services. 1 Introduction Presence is (indirectly) defined in RFC2778 [1] as subscription to Rosenberg et. al. [Page 1] Internet Draft xml buddylist June 15, 2000 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 protocol is a protocol for providing such a service over the Internet or any IP network. A presence protocol is described in [2]. Presence services begin when a user logs into their machine, and starts up their presence tool (which contains a watcher user agent (WUA), the protocol entity that performs the subscriptions). As subscription state is soft state, the tool must refresh its subscriptions by resubscribing to those users in the "buddy list". The buddy list represents the set of other users that the user has asked to subscribe to. The subscriptions are automatically made, and the subscribing user then receives notifications as their buddies come online or offline, or their communications state otherwise changes. The result of this is a requirement that the buddy list be stored somewhere, and accessible to the WUA when the tool starts. It can be stored locally on disk, in proprietary format. However, this has disadvantages. In particular, it means that if the user goes to a different machine, their buddy list is no longer accessible. It is therefore desirable to allow (but not mandate, of course), such lists to be stored on network servers, so that they can be retrieved. This way, when a user sits down at a new machine, they can start the presence tool, enter in the address where the buddy list can be fetched from, and then obtain presence services at that new machine. With the increasing amount of personal and terminal mobility in Internet access, allowing users to access their presence services from any machine seems highly desirable. As an example application, a presence tool, along with a web browser, could be made available at public access PCs in airports (these are already commonplace). When the presence tool starts, it prompts the user for a URL for their buddy list. The user enters the URL, and the presence tool fetches the list. It then asks the user for a username and password, used possibly for authentications required to subscribe to the buddies listed in the list. The application then subscribes to each of the buddies. The user can then work and have access to presence and IM services. To enable this capability, we define here an XML based format for storing buddy lists. We do not mandate a particular protocol for fetching the buddy lists, although HTTP [3] is the obvious choice. Other possibilities, including SIP registrations, are also possible [4]. 2 Buddy List Format Rosenberg et. al. [Page 2] Internet Draft xml buddylist June 15, 2000 A buddy list is a well-formed XML [5] document. It MUST conform to the DTD given in appendix A, possibly extended by elements from other XML document types properly identified with XML namespace identifiers [6]. Portions of the buddy list DTD are also interspersed throughout this section, in the subsections where each element is explained. 2.1 Buddylist Element The root element of a buddy list MUST be the element "buddylist": The "buddylist" element has no attributes. Its first sub-element is "title", giving the general title of the buddy list; it then contains any number of individual buddies or groups. 2.2 Group Element The "group" element represents groups of buddies and sub-groups: The "group" element has no attributes. Its first element is "title", giving the name of the group of buddies; it then contains any number of buddies or other groups. Note: "buddylist" and "group" are syntactially identical, though their semantics are slightly different. Would it be sensible to unify them? 2.3 Buddy Element The "buddy" element represents a single buddy: Rosenberg et. al. [Page 3] Internet Draft xml buddylist June 15, 2000 The "buddy" element MUST have an attribute "href", giving the URI used to subscribe to the buddy. It MAY have the attribute "date", giving the date when this buddy was added to the buddy list. The date is represented as an integral number of seconds since January 1, 1970, 00:00 UTC. The content of the "buddy" element is parsed character data meant to be displayed as a human readable description of the buddy. This is typically though not necessarily a name. This parsed character data MAY contain plain text. It MAY also contain XML mark-up from an XML document type designed to present human-readable content, such as XHTML [7], MathML [8], SVG [9], VoiceXML [10], SMIL [11], etc., when properly marked with an XML namespace identifier. A program interpreting a buddy list SHOULD interpret XML markup from an unknown or unsupported XML namespace as it would a document of type "text/xml" with an unknown or unsupported document type declaration. Note that some of the items in this list of document formats are deliberately rather over-the-top; it seems improbable that having a SMIL presentation to describe a buddy list entry would actually be useful. XHTML, however, will likely be common. 2.4 Title Element The "title" element represents the title of a buddy list or buddy group: This element contains a human readable description of the buddy list or group. For buddy lists, it will typically, though not necessarily, identify the list's owner; for groups, it will typically give some identifying characteristic of the group. The "title" element contains parsed character data, and MAY contain XML markup from other XML document types, as with the "buddy" element. 3 XML Buddy List Document Identifiers An XML buddy list which appears as a top-level XML document is Rosenberg et. al. [Page 4] Internet Draft xml buddylist June 15, 2000 identified with the formal public identifier "-//IETF//DTD RFCxxxx XBUDDY 1.0//EN". If this document is published as an RFC, "xxxx" will be replaced by the RFC number. XML buddy lists have the MIME type "application/xbuddy+xml". The "+xml" component of the type name conforms with the format of XML MIME types introduced by Murata et al [12]; this allows XML-aware but buddylist-unaware rendering tools to display buddy lists usefully. An XML buddy 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-buddylist- 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. The usefulness of embedding buddy lists as sub-documents of other XML documents isn't entirely clear, but defining it doesn't hurt anything. 4 Example This buddy list conforms strictly to the DTD given in this document: Buddy list for John Doe Friends Jane Doe John Smith Coworkers Eric Rosenberg et. al. [Page 5] Internet Draft xml buddylist June 15, 2000 Summer Boss - Jim This buddy list uses other XML document types, referenced with XML namespaces: <p xmlns="http://www.w3.org/1999/xhtml"> <b><i><font size="+1">Important</font></i></b> People </p> ⅇ π⁢ⅈ +1 =0 5 Security Considerations Buddy lists contain potentially sensitive information. Therefore, when stored remotely, the protocol for fetching them should provide authentication capabilities and some form of access controls, if the author of the buddy list so desires. It should also be possible to transfer the buddy list over an encrypted channel. Rosenberg et. al. [Page 6] Internet Draft xml buddylist June 15, 2000 With HTTP, these requirements are readily met by using HTTPS combined with basic authentication. This allows a user to give out passwords for access to the buddy list, and also keep the buddy list encrypted when transferred over the network. With SIP registrations, the buddy list would typically be returned in the response to a registration, if the client indicated support for buddy lists in replies. In this case, registrations SHOULD be authenticated, and either SIP encryption or hop by hop encryption SHOULD be used. A The XML Buddy List DTD B Authors Addresses Jonathan Rosenberg Rosenberg et. al. [Page 7] Internet Draft xml buddylist June 15, 2000 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 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 Rosenberg et. al. [Page 8] Internet Draft xml buddylist June 15, 2000 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 C 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. 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. [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] T. Bray, J. Paoli, and C. M. Sperberg-McQueen, "Extensible markup language (XML) 1.0," W3C Recommendation REC-xml-19980210, World Wide Web Consortium (W3C), Feb. 1998. Available at http://www.w3.org/TR/REC-xml. [6] T. Bray, D. Hollander, and A. Layman, "Namespaces in XML," W3C Recommendation REC-xml-names-19900114, World Wide Web Consortium (W3C), Jan. 1999. Available at http://www.w3.org/TR/REC-xml-names/. [7] W. H. W. Group, "XHTML 1.0: The extensible hypertext markup language," W3C Recommendation REC-xhtml1-20000126, World Wide Web Consortium (W3C), Jan. 2000. Available at http://www.w3.org/TR/xhtml1/. Rosenberg et. al. [Page 9] Internet Draft xml buddylist June 15, 2000 [8] P. Ion and R. Miner, "Mathematical markup language (MathML) 1.01 specification," W3C Recommendation REC-MathML-19990707, World Wide Web Consortium (W3C), July 1999. Available at http://www.w3.org/TR/REC-MathML/. [9] J. Ferraiolo, "Scalable vector graphics (SVG) 1.0 specification," W3C Working Draft WD-SVG-20000303, World Wide Web Consortium (W3C), Mar. 2000. Available at http://www.w3.org/TR/SVG/. [10] VoiceXML Forum, "Voice extensible markup language (VoiceXML) version 1.0," W3C Note NOTE-voicexml-20000505, World Wide Web Consortium (W3C), May 2000. Available at http://www.w3.org/TR/voicexml/. [11] P. Hoschka, "Synchronized multimedia integration language (SMIL) 1.0 specification," W3C Recommendation REC-smil-19980615, World Wide Web Consortium (W3C), June 1998. Available at http://www.w3.org/TR/REC-smil/. [12] M. Murata and S. S. Laurent, "XML media types," Internet Draft, Internet Engineering Task Force, Jan. 2000. Work in progress. Rosenberg et. al. [Page 10]