Internet DRAFT - draft-hudson-impp-pidf-proposal
draft-hudson-impp-pidf-proposal
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
