INTERNET-DRAFT Greg Hudson Expires: August 11, 2000 ghudson@mit.edu MIT Proposed Format For Presence Information draft-hudson-impp-presence-01.txt 1. 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 IMPP working group at impp@iastate.edu. 2. Abstract This document proposes a syntax and initial tag set for presence information to be used in the IMPP protocol suite. The encoding is a subset of well-formed but not valid [XML] documents, such that it can be parsed either by a simple hand-written parser or by an XML implementation. 3. Terminology The following terms are defined in [Model] and are used with those definitions in this document: PRESENTITY PRINCIPAL WATCHER USER AGENT However, those terms are used in lowercase for improved readability, since they are relatively distinctive. The terms MUST, SHOULD, and MAY are used in uppercase with the meaning defined in [RFC 2119]. 4. Syntax [POINT OF CONTENTION: Some have argued that we should define our syntax by referring to XML and adding restrictions so that we don't accidentally introduce variations. My view is that this would force implementors to consult the full XML spec; having a self-contained, reduced grammar seems more conducive to implementations.] [POINT OF CONTENTION: Several people think we should use the MIME type application/presence-xml or try to get presence/xml to allow for future media types which encode presence information differently. Precedents like application/pip suggest to me that "application/presence" is more along the lines of common practice than creating a whole new hierarchy of different encodings.] Presence information is a MIME [RFC 2045-2049] object of type application/presence. The contents of the MIME object is a presence document. The underlying character set for a presence document is [Unicode], which will be represented in UTF-8 or as determined otherwise by a charset parameter in the media type of the MIME object. Following is an ABNF [RFC 2234] grammar describing the syntax for presence information: presence-doc = "" content "" content = *(element / char-data / reference) element = empty-tag / start-tag content end-tag ; end-tag name must match start-tag name. empty-tag = "<" name "/>" start-tag = "<" name ">" end-tag = "" name = (Letter / "_" / ":") *NameChar char-data = 1*DataChar ; "]]>" may not appear, for compatibility ; with SGML. reference = char-ref / entity-ref char-ref = "&#" 1*ASCIIDigit ';' / "&#x" 1*ASCIIHexDigit ; Must refer to a valid Char entity-ref = "<" / ">" / "&" / "'" / """ The character classes Letter, Digit, CombiningChar, and Extender are defined in [XML] Appendix B. The other character classes are defined as follows: NameChar = Letter / Digit / "." / "-" / "_" / ":" / CombiningChar / Extender DataChar = %x9 / %xA / %xD / %x20-25 / %x27-3B / %x3D-D7FF / %xE000-FFFD / %x10000-310FFFF ; Most valid Unicode characters Char = DataChar / "&" / "<" ASCIIDigit = %x30-39 ; [0-9] ASCIIHexDigit = %x30-39 / %x41-46 / %x61-66 ; [0-9A-Fa-f] A char-ref refers to a Unicode character by number, either in decimal ("&#" prefix) or in hexadecimal ("&#x" prefix). An entity-ref refers to a specific Unicode character by name, as follows: entity-ref Character ---------- --------- < < > > & & ' ' " " 5. Syntactic interpretation After parsing, a presence document consists of a tree of elements, where each element consists of a name (or "tag"), text (the concatenation of all char-data and reference productions in the element's content, but not char-data and reference productions inside sub-elements), and an ordered list of child elements. For example, the presence document: a<abbbcccddd parses into a tree of three elements named "presence", "foo", and "bar", and which can be viewed pictorially as: presence "aa<abbbddd 6. Tag set Some tag definitions include a list of constraints on that element's children. If an element's children do not meet the specified constraints, the watcher user agent MUST discard that element. Tag: presence Context: (top level) Sub-elements: date presentity location status contact [XXX Do we want sub-elements here for personal information, or is that out of scope for presence?] Constraints: time and presentity must appear exactly once. location and status must appear at most once. Description: This tag introduces the presence document. Any text in the element is discarded. Tag: date Context: presence Description: The text of this element gives the date and time for which the presence information is being reported. [XXX Obviously we need to pick a standard format, but the details are unimportant at this stage.] Tag: presentity Context: presence Description: The text of this element specifies the identifier of the presentity whose presence is being reported. Tag: location Context: presence Description: The text of this element specifies the location of the principal as a human-readable description. [XXX Open issue: is it useful to define a human-readable field like this and restrict it to flat text? Or is it only useful if it can also be a video clip or HTML or whatnot?] Tag: status Context: presence Description: The text of this element specifies the current status of the presentity. It must be one of "available", "busy", and "idle". [XXX Should we be more precise about what those values mean, or is it good enough just to make sure programs use one of those three words? Should we allow for more values in the future, or is it better for interoperability not to make this particular field extensible?] Tag: contact Context: presence Sub-elements: address capabilities preference Constraints: address must appear exactly once. capabilities and preference must appear at most once. Description: This tag introduces a means of communicating with the principal. Any text in the element is discarded. There may be multiple contact elements within the presence document. Tag: address Context: contact Description: The text of this element gives the communications address as a URL [RFC 1738]. The URL type must correspond to a communication means and not a document type. [XXX How can we be more precise about this distinction? Obviously we don't want HTTP URLs here to be considered valid.] Tag: capabilities Context: contact Description: The text of this element specifies the media features which can be processed by a means of communication, using the filter syntax defined in [RFC 2533]. [XXX RFC 2533 filters are probably not all we need. More delving into the CONNEG framework is required.] Tag: preference Context: contact Description: The text of this element is an unsigned integer giving the preference of a contact relative to other contacts. When selecting between contact addresses to use to contact a principal, addresses with lower priorities should be considered more desirable than addresses with higher priorities. If no preference element appears in a contact address, it should be considered less desirable than any contact address with a preference element. 7. Examples The following presence document might be given as presence information for a presentity which might be identified as joe@example.com. Note that clarifying whitespace in the presence document must be used with some care; it is fine to have extra whitespace directly within a "presence" or "contact" element where it will be ignored, but it should not be included in elements such as "address" in which text is significant and extra whitespace is not specifically allowed. joe@example.com 2000-02-11 17:34:12 idle Out to lunch at Mel's Diner
im:joe@example.com
(& (pix-x<=1024) (pix-y<=768) (color<=256)) 1
mailto:joe@example.com
 8. Extensions New element tags can only be standardized in the form of a standards-track RFC. Element names beginning with "x-" may be used for experimental purposes for all three kinds of extensions. New element names should avoid the use of the ":" character, since it may be used in the future for XML namespaces. 9. Security considerations Watcher user agents should be careful to present communications addresses to users when users choose to send a message to a principal, so that users cannot be easily fooled into sending authenticated messages to their work supervisors other unintended parties. 10. IANA considerations The current extensions proposal does not place any load on the IANA. 11. References [Model] M. Day, J. Rosenberg, H. Sugano. "A Model for Presence." Work in progress, draft-ietf-impp-model-03.txt. [Reqts] M. Day, S. Aggarwal, G. Mohr, J. Vincent. "Instant Message / Presence Protocol Requirements." Work in progress, draft-ietf-impp-reqts-03.txt. [Type-feature] G. Klyne. "MIME content types in media feature expressions." Work in progress, draft-ietf-conneg-feature-type-01.txt. [RFC 1738] T. Berners-Lee, L. Masinter, M. McCahill. "Uniform Resource Locators (URL)." RFC 1738, December 1994. [RFC 2045-2049] N. Freed, N. Borenstein. "Multipurpose Internet Mail Extensions (MIME)." RFC 2045-2049, November 1996. [RFC 2119] S. Bradner. "Key Words for Use in RFCs to Indicate Requirement Levels." RFC 2119, March 1997. [RFC 2234] D. Crocker, Ed., P. Overell. "Augmented BNF for Syntax Specifications: ABNF." RFC 2234, November 1997. [RFC 2533] G. Klyne. "A Syntax for Describing Media Feature Sets." RFC 2533, March 1999. [Unicode] ISO (International Organization for Standardization). "ISO/IEC 10646-1993 (E). Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane." [Geneva]: International Organization for Standardization, 1993 (plus amendments AM 1 through AM 7). [XML] T. Bray, J. Paoli, C. M. Sperberg-McQueen. "Extensible Markup Language (XML) 1.0." W3C Recommendation REC-xml-19980210, February 1998.