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]