Network Working Group
INTERNET-DRAFT H. Sugano
S. Fujimoto
Fujitsu
Expires: February 2002 August 2001
CPIM Presence Information Data Format
<draft-ietf-impp-cpim-pidf-00.txt>
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.
Please send comments to the authors or to the impp@iastate.edu
discussion list.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This memo proposes a common presence format specification for
discussion in the IMPP WG. It also contains a list of issues raised
in the IMPP mailing list so far to accelerate the discussions.
Sugano et al. [Page 1]
INTERNET DRAFT CPIM Presence Format August 2001
1. Introduction
The IMPP working group has been trying to build CPIM specifications
to achieve interoperability of IM and Presence services between
different protocol domains. In particular, The work on CPIM Message
Format [CPIM-MSG] defines a common format for instant messages, which
enables secure end-to-end IM exchange. For the presence service,
although the group has agreed that there should be a common format
for presence informantion, there has been very little discussion on
the concrete format for that.
This memo proposes a CPIM common presence format specification for
discussion in the group. It also contains a list of issues raised in
the IMPP mailing list so far to accelerate the discussions.
2. Assumptions and design decisions
We took the starting point of our consideration from the minutes of
the discussion in the IETF50 IMPP meeting. Thus, the payload content
for (common) presence information should include:
presentity URL
list of contact URLs
status (open,closed)
timestamp
human readable comment
relative priority
presentity human readable comment - independent of any contact
Note that extensibility is required to the format and that it was
also agreed in the IETF50 meeting that XML should be used for the
payload format.
Then, we took the following assumptions for the design.
(a) A presence payload should be able to be transported securely from
presentity to watchers.
(b) A presence server may add some metadata and it may sign or
encrypt the presence payload.
(c) Presence tuples from different sources (presentities) may be
transported in a single NOTIFY message.
Based on these assumptions, we adopted our overall design decisions
as follows:
(1) A presence payload is in XML [XML]. This follows the agreement
in the IETF50 meeting.
Sugano et al. [Page 2]
INTERNET DRAFT CPIM Presence Format August 2001
(2) A presence payload is accompanied with RFC822 style headers for
metadata [RFC822].
(3) Multiple presence payloads can be enclosed using MIME multipart
[MIME].
3. Overall Presence Information Data Structure
For an overall presence information data format, we propose to reuse
"message/cpim" content type defined by the CPIM message format
document [CPIM-MSG] and define some new headers for content-related
metadata and an XML payload format for presence information. Note
that this content can optionally be signed or encrypted using MIME
security multiparts in conjunction with an appropriate security
scheme.
Thus, the complete presence information data looks like this:
m: Content-type: message/cpim
s:
h: (message-metadata-headers)
s:
e: (encapsulated MIME entity containing presence payload)
where, "m:", "s:", "h:", "e:" have the same meaning as defined in the
CPIM-MSGFMT document and only used to indicate the different parts of
the presence data.
Message metadata used for presence information is a subset of those
defined by the MSGFMT document.
3.1. Content Part
The content part of this object, the e: part of the above schema,
further contains presence payloads with the content headers. The
content header part includes the Content-type header, whose value
indicates whether it contains a single presence payload or multiple
presence payloads.
This memo defines a new content type "application/cpim-pidf+xml" for
an XML-encoded presence payload. The Content-type header has the
value application/cpim-pidf+xml when the content part contains a
single presence payload.
If the content part contains multiple presence payloads, the value of
the Content-type header MUST be multipart/mixed. Each part of the
multipart entity itself will be an application/cpim-pidf+xml type
Sugano et al. [Page 3]
INTERNET DRAFT CPIM Presence Format August 2001
object and each part contains content headers for its payload. It
can optionally be a signed or encrypted MIME entity using the MIME
security multiparts in conjunction with an appropriate security
scheme.
4. XML-encoded Presence Data Format
This section defines an XML-encoded presence data format of the
content type application/cpim-pidf+xml for presence payloads. A
presence payload of this type is expected to be produced by the
presentity (the source of the presence information) and transported
to the watchers by the presence servers or gateways without any
interpretation or modification.
4.1. General Design
The format is designed to align with the agreement in the IMPP group
so far described in the section 2. A single payload contains a list
of presence tuples and other information related to the presentity.
4.2. XML Format Definitions
An application/cpim-pidf+xml object is a well formed XML document.
4.2.1. The <presence> element
The root element of the application/cpim-pidf+xml object is defined
as <presence>. This element contains one or more <tuple> elements
and an optional <timestamp> element. The reason that the <timestamp>
is optional is that it is sometimes needed to hide the timestamp of
the presence information change.
The <presence> element SHOULD contain an 'xmlns' attribute to
indicate the namespace of this version of presence payloads.
4.2.2. The <tuple> element
The <tuple> element is used to carry a piece of presence information
defined as PRESENCE TUPLE in RFC2778. Thus, it contains a mandatory
<status> element and optional <contact>, and <note> elements.
The <tuple> element MUST contain a 'name' attribute which is used to
distinguish this tuple from other tuples of the same presentity. The
value of 'name' attribute MUST be unique in a single presentity.
4.2.3. The <status> element
Sugano et al. [Page 4]
INTERNET DRAFT CPIM Presence Format August 2001
The <status> element contains a mandatory <value> element and an
optional <detail> element.
4.2.4. The <value> element
The <value> element contains a CDATA value, which is either "open" or
"closed". The value "open" means the availability of the contact
means in a general sense and "closed" means it is unavailable.
4.2.5. The <detail> element
The <detail> element contains a CDATA value which describes the
detailed status of the contact means. This element has a mandatory
attribute 'type' and an optional attribute 'schema'. The 'type'
attribute indicates the type of this tuple and the values of the
<detail> element varies dependent on the type value. The optional
its possible values, which is usually a DTD.
4.2.6. The <contact> element
The <contact> element contains a URL of the contact address. It
optionally has a 'priority' attribute, whose value means a relative
priority of this contact address over the others. The value of the
attribute MUST be an integer ranged from 0 to 255 and the smaller
integer means the higher priority.
4.2.7. The <note> element
The <note> element contains a CDATA value, which is usually used for
a human readable comment related to this tuple.
4.2.8. The <timestamp> element
The <timestamp> element contains a CDATA value which is a string
indicating the date and time of the status change of this tuple. The
value of this element MUST follow the IMPP datetime format [?].
4.3. Example
<presence xmlns="http://www.ietf.org/ns/cpim-pidf-xml-1.0">
<tuple name="im-1">
<status>
<value>open</value>
<detail type="im"
schema="http://www.ietf.org/dtd/im-type-im.dtd">away</detail>
</status>
<contact priority="2">im:shingo@jp.fujitsu.com</contact>
Sugano et al. [Page 5]
INTERNET DRAFT CPIM Presence Format August 2001
<note>I'll be in Tokyo tomorrow</note>
</tuple>
<tuple name="email">
<status>
<value>open</value>
</status>
<contact priority="1">mailto:shingo@jp.fujitsu.com</contact>
</tuple>
</presence>
4.4. DTD
Data Type Definition of the application/cpim-pidf+xml format.
<!ENTITY % URL "CDATA">
<!ENTITY % URI "CDATA">
<!ENTITY % DATETIME "CDATA">
<!ENTITY % DETAILTYPE "CDATA">
<!ENTITY % DETAILVALUE "CDATA">
<!ENTITY % NOTE "CDATA">
<!ELEMENT presence ((tuple+),timestamp?)>
<!ATTLIST presence
xmlns %URI; #IMPLIED
>
<!ELEMENT tuple (status,contact?,note?)>
<!ATTLIST tuple
name %TUPLENAME #REQUIRED
>
<!ELEMENT status (value,detail?)>
<!ELEMENT value ("open"|"closed")>
<!ELEMENT detail %DETAILVALUE>
<!ATTLIST detail
type %DETAILTYPE; #REQUIRED
schema %URI; #IMPLIED
>
<!ELEMENT contact %URL;>
<!ATTLIST contact
priority %PRIORITY; #IMPLIED
>
<!ELEMENT note %NOTE;>
Sugano et al. [Page 6]
INTERNET DRAFT CPIM Presence Format August 2001
<!ELEMENT timestamp %DATETIME;>
5. Header Definitions
This section defines a set of headers which are used to convey the
metadata. All the metadata, both message and content headers, are
produced by the presence server.
5.1. Message Headers
Among the headers defined by the CPIM message format document [CPIM-
MSG], we use the following headers to convey the presence
information.
5.1.1. The 'From' header
The 'From' header contains the address (pres: URL) of the presentity.
This header is mandatory.
5.1.2. The 'To' header
The 'To' header contains the address (pres: URL) of the watcher.
This header is optional.
5.1.3. The 'DateTime' header
The 'DateTime' header contains a character string of the format
defined as IMPP datetime format [DateTime]. This value indicates the
date and time at which the content part is created.
5.1.4. The 'NS' header
The "NS" header is used to declare a local namespace prefix as
defined by [CPIM-MSG].
5.1.5. The 'Require' header
The "Require" header is used to specify a header or feature that must
be implemented by the receiver, as defined by [CPIM-MSG].
5.2. Content Headers
5.2.1. The 'Content-Type' header
The 'Content-Type' header contains the type of the content.
Sugano et al. [Page 7]
INTERNET DRAFT CPIM Presence Format August 2001
5.2.2. The 'Presence-Data-ID' header
The 'Presence-Data-ID' header contains the label for the unit of
update. This header will be used for indicating the part is
replacement of the part which contained in previous NOTIFICATION with
same 'Presence-Data-ID' value.
5.2.3. The 'Presence-Modified' header
The 'Presence-Modified' header has no value. This header MAY be used
only in the NOTIFICATION message if it contains the multipart
presence payloads. The existence of this header indicates that this
part has caused the notification.
6. Examples
The following exapmle is the message/cpim object containing two
presence payload. It is supposed that the first block is published
by a PC and the second block is published by a mobile phone, and the
second block has caused the notification message conveying this
multipart content.
Content-Type: message/cpim
From: pres:shingo_fujimoto@jp.fujitsu.com
To: pres:suga@flab.fujitsu.co.jp
DateTime: 2001-06-01T08:35:44+09:00
Content-Type: multipart/mixed; boundary="PRESENCE-BLOCKS"
--PRESENCE-BLOCKS
Content-Type: application/cpim-pidf+xml
Presence-Data-ID: part1
<presence>
<tuple name="im-1">
<status>
<value>open</value>
<detail type="im"
schema="http://foo.bar.org/dtd/im-type-im.dtd">away</detail>
</status>
<contact priority="2">im:shingo@jp.fujitsu.com</contact>
<note>I'll be in Tokyo tomorrow</note>
</tuple>
<tuple name="email">
<status>
Sugano et al. [Page 8]
INTERNET DRAFT CPIM Presence Format August 2001
<value>open</value>
</status>
<contact
priority="1">mailto:shingo@jp.fujitsu.com</contact>
</tuple>
</presence>
--PRESENCE-BLOCKS
Content-Type: application/cpim-pidf+xml
Presence-Data-ID: part2
Presence-Modified:
<presence>
<tuple name="mobile-phone">
<status>
<value>open</value>
</status>
<contact priority="9">tel:09012345678</contact>
</tuple>
<tuple name="mobile-im">
<status>
<value>open</value>
</status>
<contact priority="1">im:shingo@mobilecarrier.ne.jp</contact>
</tuple>
</presence>
--PRESENCE-BLOCKS--
7. Security Considerations
The proposed format for conveying presence information is so designed
that it could be adaptable in circumstances under various security
requirements.
As a typical case, a user publishing his/her presence information may
want to sign the data to prevent from being corrupted or tampered.
This will ensure the integrity of presence information in an end-to-
end manner. This proposal enables it by allowing MIME multipart
security framework, such as usage of the multipart/signed data type.
Another possible scenario is that of third party signing. If the
computing power of the terminal device of the publishing user is
restricted, the server side signing would be sometimes desirable to
enhance the level of security in distributing presence information.
This enables to prevent from so-called "the man in the middle"
attacks when the presence notifications are distributed through the
proxies or gateways.
Sugano et al. [Page 9]
INTERNET DRAFT CPIM Presence Format August 2001
8. Discussions
The authors understand that there are some issues in our proposal to
be discussed and agreed on for the common presence format. Those
could be listed as follows;
(a) Should such server generated metadata as From, To, DateTime in
this draft be defined as a part of common presence data format?
This draft proposes to use several headers as server generated
metadata as a part of common presence data format. This is because
it would be necessary to convey these information to the end system
(UA) as it is. It would also be desirable to allow server-side
third party signing for such data. So, this may induce another
relating question; is the third party signing on the presence
service necessary?
(b) If the answer to (a) is yes , the next issue is what is the best
format for the metadata (message/cpim or any other?).
We have adopted the message/cpim format because it can be reused
with no difficulty to contain such metadata and it is RFC822 based.
The reason to prefer an RFC822 based format is that it can nicely
fit with MIME security framework which could be utilized when the
user agents sign the presence data.
(c) Extension framework
In the earlier idea stage, we thought it preferable that local
extensions could be confined within a special element (<ext>).
There have been several objections to it which argue XML is
naturally extensible and we have no need to such an element. We
have agreed with their arguments and cut this element out.
(d) XML format
We need to agree on the details of the XML format itself. In fact,
there has been proposed an idea to contain multiple contact
elements in a single tuple element. Further discussions are
needed.
9. References
[CPIM] D. Crocker et al., "A Common Profile for Instant Messaging
(CPIM)", draft-ietf-impp-cpim-01.txt, Work in Progress.
Sugano et al. [Page 10]
INTERNET DRAFT CPIM Presence Format August 2001
[CPIM-MSG] D. Atkins and G. Klyne, "Common Presence and Instant
Messaging Message Format", draft-ietf-impp-cpim-msgfmt-03.txt,
Work in Progress.
[XML] Extensible Markup Language (XML) 1.0 (Second Edition).
http://www.w3.org/TR/2000/REC-xml-20001006, A W3C recommendation,
October 2000.
[RFC822] D. Crocker, "Standard for the format of ARPA Internet text
messages", RFC 822, STD 11, Aug 1982.
[MIME] Multipurpose Internet Mail Extensions. See RFC 822, RFC 2045,
RFC 2046, RFC 2047, RFC 2048, and RFC 2049.
[RFC2778] M. Day, J. Rosenberg, H. Sugano, "A Model for Presence and
Instant Messaging", RFC 2778, February 2000.
[RFC2779] M.Day, S.Aggarwal, G.Mohr, and J.Vincent, "Instant
Messaging / Presence Protocol Requirements", RFC 2779, February 2000.
[SMIME] P. Hoffman, Ed, "S/MIME Version 3 Message Specification",
RFC2633, June 1999.
[DateTime] G. Klyne and C.Newman, "Date and Time on the Internet:
Timestamps", draft-ietf-impp-datetime-04.txt, Work in Progress.
10. Author's Addresses
H. Sugano
suga@flab.fujitsu.co.jp
Fujitsu Laboratories Ltd.
64, Nishiwaki
Ohkubo-cho
Akashi 674
Japan
S. Fujimoto
shingo@flab.fujitsu.co.jp
Fujitsu Laboratories Ltd.
64, Nishiwaki
Ohkubo-cho
Akashi 674
Japan
11. Full Copyright Statement
Sugano et al. [Page 11]
INTERNET DRAFT CPIM Presence Format August 2001
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Sugano et al. [Page 12]
