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-pidf-00.txt
June 15, 2000
Expires: December, 2000
A Data Format for Presence Using XML
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 an XML based data format for conveying
presence information. The format 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.
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
Rosenberg et. al. [Page 1]
Internet Draft pidf June 15, 2000
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. However, we describe it here so
that the document is complete.
This presence data format is based on XML. XML has its strengths and
weaknesses, and for this reason, we actually define an additional
presence data format which is more suited to smaller footprint
endpoints [3].
2 Presence Data Model
We define presence as a set of atoms. Each atom defines a component
of the presence state of a presentity. The presence state of the
presentity is defined by taking the union of the current set of
atoms. The process of combining presence information from different
sources operates on the granularity of atoms; the content of atoms is
not examined when performing such merging. Any presence data format
MUST define a means for unioning which can be accomplished through
syntactic understanding alone of the presence document. A presence
data format MAY define a means for unioning based on semantic
understanding.
Each atom MUST contain a field which defines the presentity for whom
the atom represents. This is in support of Requirement 3.1.2 of
RFC2779 [4], which defines requirements for presence and instant
messaging.
Each atom has an opaque identifier, uniquely identifying it. There is
no meaning associated with these identifiers. Two atoms are for the
same piece of presence state when they identify the same presentity,
and when their atoms match through a byte-wise equality check of
their identifiers.
Each atom also has an expiration time, indicating the lifetime of the
data contained within the atom.
A subscriber will receive a set of atoms representing the presence
for a user. Computation of the complete presence state of that
presentity proceeds as follows:
Rosenberg et. al. [Page 2]
Internet Draft pidf June 15, 2000
o The subscriber records, for each atom, the most recent
instance of that atom. Most recent is *not* defined by
expiration time, but rather through sequencing provided by the
transfer protocol, or temporal ordering of receipt or fetch,
if no such sequencing is provided.
o If the most recent atom has an expiration time earlier than
the current time, that atom is removed completely from the
list of atoms contributing to presence.
o The subscriber generates the final piece of presence by taking
the set of unexpired atoms for the same presentity, and
unioning them as defined by the presence format.
This fairly simple model of presence data is very flexible. It
supports several different usage scenarios:
o Presence data can be generated by a single entity, but be
transferred only as updates. Each piece of the presence being
updated is a single atom. The presentity need only send an
atom when it changes, or send an update before it expires.
o Presence data can be generated by a single entity, and the
entire presence state is transferred on each notification.
o Presence data can be generated by several entities, each
updating a set of atoms for the presentity.
3 Applying the Model to the Presence Protocol
When presence documents corresponding to this model are transferred
by the presence protocol [2], two issues need to be considered.
First, 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.
Secondly, it is RECOMMENDED that each atom correspond to a single
Contact address in the registrations. Furthermore, the atom
identifier SHOULD be computed as the MD5 hash of the URI of that
Contact. This allows both server and PUA to know the identifier, so
that they can alternately take over generation of updates for the
same atom.
Rosenberg et. al. [Page 3]
Internet Draft pidf June 15, 2000
4 Components of the Document
The presence document format defined here is based on XML, and is
similar in concept to the proposed PIDF format by Vermeulen [5].
Usage of XML brings several benefits; as presence data is likely to
be rendered, the ability to define XSL and CSS documents for
displaying of presence is useful. The ability to digitally sign
subcomponents of an XML document is also useful.
The presence document always contains the top level element
"presence," which indicates that the remainder of the document
contains presence information.
The first sub-element of the presence element is the "presentity"
element, which identifies the presentity for whom the presence data
is being reported.
The presentity tag has a single mandatory attribute, uri, which gives
the address of the presentity. The content of the presentity tag is
parsed character data giving a human-readable name.
This parsed character data may consist of plain text. It may also
contain XML mark-up from an XML document type designed to present
human-readable content, such as XHTML [6], MathML [7], SVG [8],
VoiceXML [9], SMIL [10], etc., when properly marked with an XML
namespace identifier. A program interpreting a buddy list SHOULD
interpret and display 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
presentity would actually be useful. XHTML, however, will
likely be common.
Rosenberg et. al. [Page 4]
Internet Draft pidf June 15, 2000
Following the presentity tag within the presence tag is a list of
atoms.
4.1 Atoms
Atoms are structured as a collection of addresses. These can either
be communications addresses, represented by URLs, or a postal
address.
The atom element has the mandatory attribute "id", the unique
identifier for the group, and the optional attribute "expires" which
indicates the time after which the presence data should be considered
invalid. The expiration time is expressed as an integral number of
seconds since January 1, 1970, 00:00 UTC.
A postal address is indicated by the "postal" element, and consists
of freeform text:
It may contain XML markup from some external namespace, as described
previously.
It would be nice to require an XML format for postal
addresses. Does any exist? vCard XML profile or something?
Communications addresses are described by the "address" element.
The "address" element has a single mandatory attribute, uri, which
gives the URI of the communications address being described. It also
Rosenberg et. al. [Page 5]
Internet Draft pidf June 15, 2000
has an optional attribute "priority". The priority tag contains an
integer that indicates the relative preference of this address over
other addresses. It is a floating-point value between 0 and 1, with 1
being the highest preference.
Within the address tag, several subtags are defined to specify
characteristics of the communications address. These tags have the
following meanings:
status: Status is an indicator, meant for machine consumption,
which indicates the status of this communications address.
Valid values are "open", which means communications can be
attempted to this address, "closed", which means
communications cannot be attempted, and "inuse", which
means that communications means is currently being actively
used with the entity receiving the presence document. For
example, if an instant messaging URL is placed in the uri
attribute of the address, and the status is "inuse", this
means that the user sending the updated presence document
is currently typing an instant message to the recipient of
the presence document.
This enables a recent feature on MSN, which allows you
to see when the person you are IMing is currently
typing a reply to your IM.
class: The class tag contains either the value "business" or
"personal", indicating whether the address is for business
or non-business use. There can only be one class tag per
address.
duplex: The duplex tag contains one of the values "full",
"half", "send-only" and "receive-only". It indicates
Rosenberg et. al. [Page 6]
Internet Draft pidf June 15, 2000
whether the address can be used for communications in one
direction, the other direction, or both. For example, a
page would be considered receive-only. There can only be
one duplex tag per address.
feature: The feature tag lists features specific to that
communications means. For voice addresses, defined values
include "voice-mail" and "attendant". There can be more
than one feature tag per address.
mobility: The mobility tag indicates whether the terminal with
the given communications address is moving around
("mobile") or fixed ("fixed"). There can only be a single
mobility tag per address.
note: Note contains freeform text meant for display to the user,
indicating some kind of information about the
communications address. There can only be one note tag per
address. The note tag may contain XML data from a
properly-qualified external XML namespace.
A PIDF document which appears as a top-level XML document is
Rosenberg et. al. [Page 7]
Internet Draft pidf June 15, 2000
identified with the formal public identifier "-//IETF//DTD RFCxxxx
XPIDF 1.0//EN". If this document is published as an RFC, "xxxx" will
be replaced by the RFC number. PIDF documents have the MIME type
"application/xpidf+xml".
The "+xml" component of the type name conforms with the
format of XML MIME types introduced by Murata et al [11];
this allows XML-aware but PIDF-unaware rendering tools to
display PIDF usefully.
A PIDF document embedded as a fragment within another XML document is
identified with the XML namespace identifier
"http://www.ietf.org/internet-drafts/draft-rosenberg-impp-pidf-
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.
5 Constructing the union of two presence documents
Construction of the union of two presence documents is
straightforward. Two presence documents can be unioned only if they
both refer to the same presentity. The atoms from each presence
document is extracted. If some number of atoms have the same id, the
most recent atom is selected. Most recent is defined either by the
transfer protocol, or through temporal ordering. A new presence
document is then constructed, using the set of atoms obtained from
the presence documents. For example, consider presence document A:
Rosenberg et. al. [Page 8]
Internet Draft pidf June 15, 2000
and presence document B:
The combined document looks like:
6 Example
The following is an example presence document:
Rosenberg et. al. [Page 9]
Internet Draft pidf June 15, 2000
Send email if I'm not around
7 Mapping from SIP Registrations
This section discusses how one would map the contents of a SIP
REGISTER message into a presence document.
Typically, each Contact header in the registration will be a separate
atom. That atom will have a single URL, which is the URL from the
Contact header. If the registration is not expired, the status is set
to open. Once the registration expires, the address is set to closed,
and can be removed completely from the presence document at some
point in the future.
If the UA sending the registration supports caller preferences [12],
and has included them in the contact header, they are mapped one to
one into their equivalent XML tags described here.
8 DTD
The following is the DTD for the presence document.
Rosenberg et. al. [Page 10]
Internet Draft pidf June 15, 2000
9 Evaluation against Requirements
The following section indicates how this proposal meets the
requirements outlined in RFC2779 [4].
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
presentity tag.
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 postal and address tags.
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 definitions of new tags for the XML
Rosenberg et. al. [Page 11]
Internet Draft pidf June 15, 2000
presence document.
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 XML, a standard structured data representation
used in many IETF standards, and on URLs, also defined by
IETF.
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 [13] is of the form sip:user@host;method=SUBSCRIBE. This
URL is then included in an address tag.
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. These
statuses are defined here.
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 statuses to any communications means. IM is not
treated differently than any other.
10 Authors Addresses
Jonathan Rosenberg
dynamicsoft
200 Executive Drive
Suite 120
West Orange, NJ 07052
email: jdrosen@dynamicsoft.com
Dean Willis
Rosenberg et. al. [Page 12]
Internet Draft pidf June 15, 2000
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
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
email: bernarda@microsoft.com
David Gurle
Microsoft Corporation
Rosenberg et. al. [Page 13]
Internet Draft pidf June 15, 2000
One Microsoft Way
Redmond, WA 98052-6399
email: dgurle@microsoft.com
11 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 lightweight
presence information data format (LPIDF)," Internet Draft, Internet
Engineering Task Force, June 2000. Work in progress.
[4] M. Day, S. Aggarwal, G. Mohr, and J. Vincent, "Instant messaging
/ presence protocol requirements," Request for Comments 2779,
Internet Engineering Task Force, Feb. 2000.
[5] C. Vermeulen, "Presence info data format (PIDF)," Internet Draft,
Internet Engineering Task Force, Dec. 1999. Work in progress.
[6] 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/.
[7] 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/.
[8] 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/.
[9] 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/.
Rosenberg et. al. [Page 14]
Internet Draft pidf June 15, 2000
[10] 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/.
[11] M. Murata and S. S. Laurent, "XML media types," Internet Draft,
Internet Engineering Task Force, Jan. 2000. Work in progress.
[12] H. Schulzrinne and J. Rosenberg, "SIP caller preferences and
callee capabilities," Internet Draft, Internet Engineering Task
Force, Mar. 2000. Work in progress.
[13] 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 15]