IETF IMPP Working Group C. Vermeulen INTERNET DRAFT Alcatel Expires May 25, 2000 November 25, 1999 Presence Info Data Format (PIDF) 1 Status of this Document 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 The list of Internet-Draft Shadow Directories can be accessed at Distribution of this document is unlimited. Please send comments to Christophe.Vermeulen@alcatel.be or to the impp@iastate.edu discussion list. 2 Abstract This document describes the format of presence information. It makes deliberately abstraction from issues associated with the transport of this information. The proposed format follows the W3C XML recommendation, such that presence information are valid XML documents according to a presence DTD. As several types of devices are envisioned to handle presence information, including devices with low computing power and networking capabilities, the defined format has been kept as simple as possible, with only five tags defined, two of which with no defined attributes. Vermeulen [Page 1] INTERNET-DRAFT Presence Info Data Format November 25, 1999 3 Introduction The IMPP working group has been chartered to design protocols in conformance with the [REQS] and [MODEL] documents. In particular, four documents are being prepared under this charter : Presence Info Data Format (PIDF) : this document, describes the format of presence information. Message Information Data Format (MIDF) : a companion document, describes the format of message information. Presence Information Transport Protocol (PITP) : a companion document, describes the transport of presence information. Message Information Transport Protocol (MITP) : a companion document, describes the transport of message information. The figure below explains the relationship between those four documents : Presence Service Instant Message Service -------------- ------------------ | PIDF | | MIDF | -------------- ------------------ | PITP | | MITP | -------------- ------------------ | IP | | IP | -------------- ------------------ The present document wants to show that a simple use of XML is possible without redefining it, that would not only be compatible with the standard, but also validate when applicable, while very light-weight terminals could simply discard additional information. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] . Vermeulen [Page 2] INTERNET-DRAFT Presence Info Data Format November 25, 1999 4 Syntax definition 4.1 Workgroup discussion considerations It has been agreed in the Instant Messaging and Presence Protocol working froup that presence should at least be transportable as a [MIME] object, similar to the text/xml definition of [RFC2376], so that it shares the default UTF-8 character set as default. However, no consensus has been achieved further than on the requirement document [REQS] on what should be presence and how it should be encoded. This proposal defines a very simple and generic way to format presence information using valid XML. The client implementation is expected to be very small, as only five tags are defined, two of which without attributes. Extensions of this syntax can easily be achieved either by adding tags or attributes when appropriate, or by using the XML namespace facilities. 4.2 Document-level considerations The presence document MUST adhere to the [REC-XML] specification. However, it is recognized that instant messaging will have to be supported on very light-weight terminals, including PDAs, mobile phones and other appliances, that may contain only a very simple, almost hand-written or tweaked parser, that won't support all features of the [REC-XML] specification. Therefore the additional restrictions apply : A presence document SHOULDN'T include any processor instructions, CDATA section or external references. Client implementations MAY discard them silently. Servers SHOULD reject presence information that contains the string "]]>" in it, with an appropriate error message sent to the client or server originating it. The format of the error message is out of scope for this document. 4.3 The element The root element of the presence document is defined as . This document has the structure (address)* (watcher)* The personal information proposed here differs from alternative proposals as it is only present once in the document. Therefore, it is defined in terms of attributes for nickname, first and last names, a location and an URL reference that also serves as reference for further updates. This URL MUST be present, and SHOULD point to a [VCARD] object representative of the PRESENTITY. Vermeulen [Page 3] INTERNET-DRAFT Presence Info Data Format November 25, 1999 In DTD syntax, this becomes 4.4 The
element The
element of the presence document contains the presence information related to one PRESENTITY. This element has the structure
(caps | note)*
The name "address" was chosen as the URL itself is as usual placed in an attribute of name "href". The "status" is also an attribute, with a set of pre-defined values. Both are mandatory. The "lastchecked" optional attribute contains an indication of when this address or PRESENTITY was last accessed or verified. It is a string that follows the date specification as defined in [RFC822] and extended by [RFC1123] to permit 4 digits in the year field. Capabilities () and notes are optional, and no specific order is required. In DTD syntax, this becomes 4.5 The status values In order to simplify client implementations, the same values will be used for all types of addresses (IM, e-mail, phone, ...). Notes may be used to explain the meaning of the "restricted" value. According to the requirements, two values need to be defined for OPEN and CLOSED. In addition to that, this document defines an intermediate value, RESTRICTED, that signals that the address SHOULD NOT be used without prior user check. A DEFERRED value signals that the message may be received later by the recipient. A DELETED value is used in updates when that address has been removed from the PRESENCE information. Vermeulen [Page 4] INTERNET-DRAFT Presence Info Data Format November 25, 1999 4.6 The element The element of the presence document contains the capabilities information related to one PRESENTITY or address. This element internals are for further study. 4.7 The element The element of the presence document contains some comments related to one PRESENTITY or address. This element contains free text. 4.4 The element The element of the presence document contains the WATCHER INFORMATION related to one WATCHER. This element has the structure (caps | note)* [[[ The internal structure is very much subject to change, as WATCHER information is absent from the [REQS] document. At this time, only the mandatory "href" attribute is defined, that SHOULD contain a useful reference for information on the WATCHER. Capabilities and Notes are allowed inside, like for the
element. ]]] 5 Example This example has been validated with Internet Explorer 5 using the DTD as provided in appendix. You need to copy the example.xml and presence.dtd in the same directory. The author's vCard won't be available outside the Alcatel Intranet. Vermeulen [Page 5] INTERNET-DRAFT Presence Info Data Format November 25, 1999
Let ring at least 7 times as call is forwarded. Voice mail is activated after 10 rings
The fax is far from my room, please send me a notification by mail or phone beforehand
The fax is near my secretary in Antwerp, so I won't get it until tomorrow.
6 Security Considerations This proposal does not introduce any new security considerations over those in [REC-XML] and [MODEL], but does not meet all the security requirements in [REQS], although most are out of scope for this document. However, it should be noted that the hyperlinks ("href" attributes), even when the document is authenticated by external means, are not guaranteed to meet any specific requirements on the content. This means that "navigating to them" by any way (HTTP browser, copying into the "To:" field of a mail client, ...) may cause hasards to the executing machine if not properly handled, including root access. Vermeulen [Page 6] INTERNET-DRAFT Presence Info Data Format November 25, 1999 7 References [VCARD] F. Dawson, T. Howes, "vCard MIME Directory Profile", RFC 2426 Lotus Development Corporation; Netscape Communications, September 1998. [REC-XML] T. Bray, J. Paoli, C. M. Sperberg-McQueen. "Extensible Markup Language (XML) 1.0." W3C Recommendation REC-xml-19980210, February 1998. [MIME] N. Freed et al., "Multipurpose Internet Mail Extensions (MIME) Part One" to "Five", RFC 2045-2049, Innosoft et al., November 1996. [MODEL] M. Day, J. Rosenberg, "A Model for Presence and Instant Messaging". draft-ietf-impp-model-03.txt. Internet Draft, work in progress. Lotus; Bell Labs. June 1999. [REQS] M. Day, S. Aggarawal, G. Mohr, J. Vincent, "Instant Messaging / Presence Protocol Requirements." draft-ietf-impp-reqts-03.txt. Internet Draft, work in progress. Lotus; Microsoft; Activerse; Arepa. June, 1999. [PRESENCE] G. Hudson, "Proposed Format For Presence Information", draft-hudson-impp-presence-00.txt, Internet Draft, work in progress, MIT, November 15, 1999. [RFC822] David H. Crocker, "Standard for the format of ARPA Internet text messages", RFC 822, University of Delaware, August 1982. [RFC1123] R. Braden, "Requirements for Internet Hosts -- Application and Support", RFC 1123, October 1989. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119, Harvard University, March 1997. [RFC2376] E. Whitehead, M. Murata, "XML Media Types", RFC 2376, UC Irvine, Fuji Xerox Info. Systems, July 1998. 8 Author's Address C. Vermeulen Alcatel Research Center DS9/C0 F. Wellesplein, 1 B-2018 Antwerp, Belgium Christophe.Vermeulen@alcatel.be Vermeulen [Page 7] INTERNET-DRAFT Presence Info Data Format November 25, 1999 9 Appendix : Presence Info Data Format DTD Vermeulen [Page 8]