INTERNET-DRAFT Greg Hudson
Expires: May 15, 2000 ghudson@mit.edu
MIT
Proposed Format For Presence Information
draft-hudson-impp-presence-00.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
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 cdata and reference productions in the element's
content), 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: fullname nickname location contact
Description: This tag introduces the presence document. Any text
in the element is discarded.
Tag: fullname
Context: presence
Description: The text of this element specifies the full name of
the principal.
Tag: nickname
Context: presence
Description: The text of this element specifies the preferred name
of the principal for casual conversation.
Tag: location
Context: presence
Description: The text of this element specifies the location of the
principal as a human-readable description.
Tag: contact
Context: presence
Sub-elements: type address capabilities status note
Constraints: type, address, capabilities, and status must appear
at most once. type and address must appear.
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: type
Context: contact
Sub-elements: (none)
Description: The text of this element specifies the type of a means
of communication. Currently defined communication
means are specified in section 7.
If the text of this element does not match any defined
type, the watcher user agent MAY discard the parent
element or present it as unrecognized, but MUST
NOT reject the entire presence document or fail to
process other parts of the presence document.
Tag: address
Context: contact
Sub-elements: (none)
Description: The text of this element specifies the address for a
means of communication. The format of the address
depends on the type and is specified in section 7.
If the text of this element does not match any defined
type, the watcher user agent MAY discard the parent
element or present it as unrecognized, but MUST
NOT reject the entire presence document or fail to
process other parts of the presence document.
Tag: capabilities
Context: contact
Sub-elements: (none)
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]. If the
text does not meet that syntax, the watcher user agent
should discard the capabilities element.
Tag: status
Context: contact
Sub-elements: (none)
Description: The text of this element describes the disposition of
the principal with respect to the given communication
means. The possible status values depend on the
communications type and are specified in section 7.
The status element is optional, and the presence
document SHOULD omit the status element if the
disposition of the principal cannot be determined.
If the text of this element does not match any defined
status, the watcher user agent MAY discard the status
element or present it as unrecognized, but MUST NOT
reject the presence document, discard the contact
element, or fail to process other parts of the
presence document.
Tag: note
Context: contact
Description: The text of this element is intended for presentation
to the user and annotates a communication means. It
might explain the value of the status field in greater
detail, or it might provide more information about the
contact means in general.
7. Communication types
This section describes values for the type, address, and status
elements.
Type: im
Address format: RFC-822 email address
Status values: Text Meaning
---- -------
offline Delivery will fail
available Message will be read quickly
idle Principal is away from receiver;
message may be read after some delay
busy Available, but only important messages
desired
Description: Messages should be delivered using the Instant
Messaging protocol.
Type: email
Address format: RFC-822 email address
Status values: Text Meaning
---- -------
checking Message will be read quickly
not-checking Message will probably not be read
quickly
vacation Message will be read after an extended
delay
Description: Messages should be delivered using SMTP.
Type: phone
Address format: A phone number, as it would be written in a PHONE-NUMBER
value in [RFC 2426].
Status values: Text Meaning
---- -------
present Call will be answered
voicemail Call will be recorded
not-present Call will not be answered
line-busy Phone line currently in use
busy Present, but only important calls
desired
Description: Principal may be called on public telephone network
8. 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 "name" or "type" in which
text is significant and extra whitespace is not allowed.
Joe T. Example, Esquire
Joe
Out to lunch at Mel's Diner
im
joe@example.com
idle
(& (pix-x<=1024) (pix-y<=768) (color<=256))
email
joe@example.com
not-checking
phone
1-800-225-5563
voicemail
Remember the number as 1-800-CALL-JOE.
9. Extensions
Extensions can take the form of:
* New element tags
* New communication types
* New status values for existing communications types
Extensions can only be standardized in the form of a standards-track
RFC. Names beginning with "x-" may be used for experimental purposes
for all three kinds of extensions. New element tags should avoid the
use of the ":" character, since it may be used in the future for
XML namespaces.
10. 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.
11. IANA considerations
The current extensions proposal does not place any load on the IANA.
12. References
[Model]
M. Day, J. Rosenberg, H. Sagano. "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 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 2426]
F. Dawson, T. Howes. "vCard MIME Directory Profile." RFC 2426,
September 1998.
[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.