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-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>
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]