INTERNET-DRAFT Greg Hudson Expires: November 18, 2000 ghudson@mit.edu MIT Presence Information Data Format draft-hudson-impp-pidf-proposal-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. 2. Abstract This document specifies a simple, readable, and highly extensible presence information format to be used in the Instant Messaging and Presence Protocol suite. 3. Terminology The following terms are defined in [RFC 2778] and are used with those definitions in this document: PRESENTITY PRINCIPAL 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 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 scalar values [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 = *LWSP *var-def var-def = varname *LWSP "=" *LWSP [value *LWSP] [subtree *LWSP] subtree = "{" *LWSP *var-def "}" varname = ALPHA *(ALPHA / DIGIT / "-" / ":") value = DQUOTE *(regchar / "\" DQUOTE / "\\" / CRLF) DQUOTE ; Whitespace and all printable Unicode characters other than ; "\" (%x5C). regchar = WSP / %x21-5B / %x5D-7E / %x80-D7FF / %xE000-FFFD / %x10000-310FFFF Here is an example document illustrating all of the syntactic elements: date = "Thu, 30 Mar 2000 09:59:34 -0500" contact = "mailto:ghudson@mit.edu" contact = "imto:ghudson@mit.edu" { status = "deferred" } 5. Semantics This section defines the meanings of specific variable names in particular contexts. If the reader of a presence document does not recognize a variable name in the context it appears in, the reader MUST ignore that variable definition, including its subtree. Unless a variable definition states "this variable MAY be repeated," a given variable MUST appear once in a given context. For instance, only one "presentity" definition may appear in the top level, and only one "status" definition may appear in the subtree of a "contact" definition. If the reader of a presence document encounters multiple definitions of a variable which must not be repeated, it MUST ignore all but the first variable definition. All variables are optional. Variable names are case-sensitive. 5.1. The "presentity" top-level variable The value of this variable is a URL [RFC 1738] specifying the presentity this presence document applies to. Normally the scheme of this URL is "presence", but it MAY be of some other scheme if a local gateway is in use. Example: presentity = "presence:ghudson@mit.edu" 5.2. The "date" top-level variable The value of this variable gives the date and time at which the presence document applies. This field shall shall be expressed in the syntax from [RFC 822] section 5 as amended by [RFC 1123] section 5.2.14. Time zones MUST be expressed numerically. For reference, the ABNF resulting from these references and restrictions is (note that ABNF strings are case-insensitive, so ASCII case-folding MUST be performed when matching day and month strings): date-time = [day ","] date time day = "Mon" / "Tue" / "Wed" / "Thu" / "Fri" / "Sat" / "Sun" date = 1*2DIGIT month 4DIGIT month = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec" time = hour zone hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT] zone = ("+" / "-") 4DIGIT ; hours+min (HHMM) Example: date = "Thu, 30 Mar 2000 09:59:34 -0500" 5.4. The "contact" top-level variable The value of this variable is a URL giving a means of contacting the principal determined by this presentity. This variable may be repeated. Example: contact = "mailto:ghudson@mit.edu" 5.4.1. The "status" contact variable The value of this variable MUST be one of the following strings (case-sensitive): open closed deferred "open" implies that the contact address is in normal working order and messages will be read in a timely fashion. "closed" implies that the contact address will temporarily not work. "deferred" implies that a greater than normal delay will be experienced before the principal receives communications sent to the contact address. A fourth possibility is that the status variable is omitted entirely for a contact address. In this case, the implication is that messages can be sent to that contact address but no information is available as to whether messages will be read in a timely fashion. 5.4.2. The "capabilities" contact variable This value of this variable specifies the display capabilities of the contact address, using the filter syntax defined in [RFC 2533]. XXX NOTE: At the time of this writing, the media features currently defined in the IANA registry are geared towards printing and fax services, not instant message or email services. New media features will have to be registered before the capabilities contact variable will be adequate to express the display capabilities of interesting contact addresses. 5.4.3. The "preference" contact variable The value of this variable is an unsigned integer, represented in decimal, specifying the preference of a contact relative to the other contacts. Preference values MUST be less than 2^32. A lower preference value indicates a more desirable contact address. A contact without a preference value is less desirable than any contact address with a preference value. For example, if a presence document contains: contact = "imto:a@example.com" { preference = "1" } contact = "mailto:b@example.com" { preference = "3" } contact = "imto:c@example.com" { preference = "2" } contact = "mailto:d@example.com" Then the contact address imto:a@example.com should be considered most desirable, then imto:c@example.com, then mailto:b@example.com, then mailto:d@example.com. 6. Namespaces Variable names containing a colon are used to allow non-conflicting experimental extensions to the presence information format. This extension mechanism is based heavily on [XML-namespace]. If a variable name begins with "namespace:", then it is a namespace definition applying to the following variable definitions in that context. The value of the definition is a URL, but it simply an identifier; nothing is guaranteed about the data one might retrieve using the URL. If a variable begins with any other string followed by a colon, the string MUST be a namespace defined earlier in the context, or earlier in an enclosing context. The following is an example of a presence document using (entirely hypothetical) namespaces. namespace:foo = "http://web.mit.edu/ghudson/my-namespace" presentity = "presence:ghudson@mit.edu" foo:geoloc = "12.3N 18.6W" contact = "imto:ghudson@mit.edu" { namespace:bar = "http://web.mit.edu/ghudson/another-namespace" foo:device-type = "pager" bar:icon = "http://web.mit.edu/ghudson/icon.png" } Since namespace specifications are URLs, different parties can define non-conflicting extensions to the presence format by using URLs within their administrative control as namespace designations. 7. Examples The following presence document might be given as presence information for a presentity which might be identified as joe@example.com. presentity = "joe@example.com" date = "30 Mar 2000 14:37:41 +0200" contact = "imto:joe@example.com" { preference = "1" status = "deferred" } contact = "mailto:joe@example.com" 8. Extensions New variable names can only be standardized in the form of a standards-track RFC. Variable names using namespaces (as described in section 6) can be used for experimental purposes. 9. Security considerations If a presence document is signed using the MIME envelope, it SHOULD include a date variable to guard against replay attacks. If a user agent contacts a principal using a contact address from a presence document, it SHOULD take care to display the contact address to the sending user; otherwise, messages may be sent to an unintended third party if the presence document was written maliciously. 10. IANA considerations The current extensions proposal does not place any load on the IANA. 11. References [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. [RFC 2778] M. Day, J. Rosenberg, H.Sugano. "A model for Presence and Instant Messaging." RFC 2778, February 2000. [Unicode] The Unicode Consortium. "The Unicode Standard Version 3.0." Addison-Wesley, February 2000. [XML-namespace] T. Bray, D. Hollander, A. Layman. "Namespaces in XML." W3C Recommendation REC-names-19990114, January 1999. 12. Author's address Greg Hudson Massachusetts Institute of Technology Cambridge, MA 02139 ghudson@mit.edu