Instant Messaging and Presence Protocol John D. Ramsdell Internet Draft The MITRE Corporation Category: Informational May 2000 Document: draft-ramsdell-simp-protocol-01.txt Document Expires: ? Simple Instant Messaging and Presence 1.1 Protocol draft-ramsdell-simp-protocol-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. This document and related documents are discussed on the impp mailing list. To join the list, send mail to impp-request@iastate.edu. To contribute to the discussion, send mail to impp@iastate.edu. The archives are at http://lists.fsck.com/cgi-bin/wilma/pip. The IMPP working group charter, including the current list of group documents, can be found at http://www.ietf.org/html.charters/impp-charter.html. Copyright Notice Copyright (C) 2000 The MITRE Corporation. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are Ramsdell Informational [Page 1] Internet Draft SIMP 1.1 Protocol May 2000 included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to The MITRE Corporation. This document and the information contained herein is provided on an "AS IS" basis and THE MITRE CORPORATION DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Abstract The MITRE Corporation released a open source Instant Messaging system in March of 2000 called Simple Instant Messaging and Presence Service. This document describes an update to the protocol used by that system. In this version of the protocol, messages can be digitally signed. While the system does not meet many of the requirements of the IMPP working group, it is provided as background information on existing Instant Messaging implementations. Table of Contents 1. Introduction ...................................................... 3 2. SIMP Server Component Overview .................................... 4 2.1 Notification Connection .......................................... 4 2.2 Routing Connection ............................................... 5 3. Protocol Foundation ............................................... 5 3.1 Connection Type .................................................. 5 3.2 Data Syntax ...................................................... 5 3.3 Commands ......................................................... 6 3.4 Signed Commands .................................................. 6 3.5 Streams .......................................................... 6 3.6 Asynchronous Requests ............................................ 7 3.7 Profiles ......................................................... 7 3.8 Access Control Lists ............................................. 8 4. Notation .......................................................... 9 4.1 Path Notation ................................................... 10 4.2 Syntactic Constraints ........................................... 10 4.2.1 Value Types ................................................... 10 4.2.1.1 String ...................................................... 10 4.2.1.2 IMA ......................................................... 10 4.2.1.3 Time ........................................................ 10 4.2.1.4 Date ........................................................ 10 4.2.1.5 Int ......................................................... 11 4.2.1.6 State ....................................................... 11 4.2.1.7 Mime ........................................................ 11 4.2.1.8 Version ..................................................... 11 Ramsdell Informational [Page 2] Internet Draft SIMP 1.1 Protocol May 2000 4.2.2 Well-Formed Commands .......................................... 11 4.3 Access Control Constraints ...................................... 11 5. General Client Requests .......................................... 12 5.1 Send ............................................................ 12 5.2 Fetch ........................................................... 12 5.3 Subscribe ....................................................... 13 5.4 Unsubscribe ..................................................... 13 5.5 Inquire ......................................................... 13 6. Server Notification Requests and Commands ........................ 13 6.1 Note Change ..................................................... 14 6.2 Note Subscription End ........................................... 14 6.3 Note Subscription ............................................... 14 6.4 Note Subscription Lapse ......................................... 15 6.5 Divert .......................................................... 15 7. Client Connection Requests and Commands .......................... 15 7.1 Login ........................................................... 15 7.2 Connect ......................................................... 16 7.3 Logout .......................................................... 16 8. Client Profile Requests .......................................... 16 8.1 Get Profile ..................................................... 16 8.2 Set Profile ..................................................... 16 9. Client Access Control List Requests .............................. 17 9.1 Get ACL ......................................................... 17 9.2 Set ACL ......................................................... 17 10. Client Subscription Requests .................................... 17 10.1 Drop Subscription .............................................. 17 11. Encapsulation of Signed Commands ................................ 17 11.1 Encapsulate .................................................... 17 12. Unrecognized Requests ........................................... 18 13. Discussion ...................................................... 18 14. Acknowledgments ................................................. 18 15. References ...................................................... 19 16. Glossary ........................................................ 19 17. Author's Address ................................................ 21 1. Introduction Instant messaging is designed to support message exchange at a rate that supports chat-like conversations. An instant message is delivered quickly to a recipient if the recipient is listening for messages, otherwise the message is dropped and the sender is informed of the delivery failure. A user of an instant messaging service can employ a presence service to keep track of the listening status of a set of users. By consulting this service, a user has a good chance of predicting if a message will get to its recipient. Ramsdell Informational [Page 3] Internet Draft SIMP 1.1 Protocol May 2000 The Simple Instant Messaging and Presence Protocol is designed so that instant messaging and presence services can be provided by a set of distributed servers spread across many administrative domains. The vision is a service provided by a large number of sites much in the way that electronic mail service is provided today. The protocol is similar to email protocols. Users are identified by an Instant Message Address (IMA), which has the same syntax as an Internet email address [Email]. A message is delivered by connecting to the user's home server. A future version of the protocol will allow the use of digital signatures to authenticate the originator of a message transported by this protocol. Unlike most email systems, a user listening for instant messages remains connected to their home server. This connection is used to deliver messages in a timely fashion. Another difference with email systems is that an instant message is never queued, rather it is dropped if there is any obstacle to immediate delivery. Fundamentally, email is built on one way message passing, while most of this protocol is built on request-reply pairs. The protocol is built on the transfer of one simple type of object represented as an XML document [XML]. The simplicity of the wire protocol gives it its name, which is abbreviated as the SIMP Protocol. 2. SIMP Server Component Overview For each domain name associated with an instant message address, one or more servers provide two types connection points, one for routing messages to servers, and the other for client notification. A simple implementation of the service might use one program to implement both connection points. A domain name that maps to multiple IP addresses can be used to produce a highly available service. 2.1 Notification Connection An instant message address identifies the location of a user's contact place. The contact place provides presence service and, when the user is online, a relay for instant messages. A user listens for instant messages by maintaining a notification connection to the user's contact place. In addition to receiving instant messages by this connection, the client also uses it to receive change of presence notifications, get and set an access control list, and get and set a user profile. The contact point's access control list and profile will be described later. The client can use this connection to send messages that are routed by the Ramsdell Informational [Page 4] Internet Draft SIMP 1.1 Protocol May 2000 user's contact place to other users. The use of this connection requires user authentication. 2.2 Routing Connection A routing connection is used to deliver messages to a user's contact place. Both clients and other servers can make requests through this connection. The initial step in user authentication occurs on this connection. 3. Protocol Foundation The description of the protocol has been divided into two levels. This section describes the transfer of objects as XML documents. The remaining sections describe the interactions of clients and servers in terms of the transfer of objects described here. The paper concludes with a glossary of relevant terms. 3.1 Connection Type The SIMP Protocol currently runs over TCP/IP. The routing connection is made available on port 7467 which is SIMP on a telephone touchtone keypad. The login protocol establishes the port for the notification connection. 3.2 Data Syntax A properties object is the one and only type of data exchanged in this protocol. A properties object is a partial map from strings to strings. An item from its domain is called a key and the item from its range associated with the key is called the key's value. A key value pair is called an entry. Every properties object has a representation as a sequence of octets that make up a valid XML document. This representation is called the object's XML representation. The document type declaration which defines the validity follows. Since a property object is a partial map, the order in which the entry elements appear in its XML representation is of no significance. Furthermore, a given string can be the key of at most one entry. Ramsdell Informational [Page 5] Internet Draft SIMP 1.1 Protocol May 2000 For example, the following properties object has five entries, and the key "action" maps to the value "send". send fella@home guy@work text/plain Please meet at 8 AM in my office. In what follows, the phrase "the KEY attribute is VALUE" abbreviates the phrase "the key KEY maps to the value VALUE". In the previous example, the "action" attribute is "send". 3.3 Commands A properties object with an "action" attribute is called a command. Every properties object exchanged by the protocol is a command. 3.4 Signed Commands Any command that includes a "from" attribute giving the IMA of the originator of the command, can be digitally signed. The protocol uses the encapsulate command to exchange digitally signed commands. An encapsulate command contains the signed command, a signature of the signed command, and an X.509 certificate containing the signer's public key. Each certificate must contain the originator's IMA as the distinguished name of the subject represented by the certificate. When using version 3 certificates, the IMA may appear as a subject alternative name, instead of as the distinguished name. For alternatives schemes, see [XMLDSIG] for a proposal for digital signature processing rules and syntax for XML documents. 3.5 Streams Every connection contains a pair of streams that transfer octets in opposite directions. A stream starts with the ASCII characters: followed by zero or more commands, and terminated by the ASCII characters: Ramsdell Informational [Page 6] Internet Draft SIMP 1.1 Protocol May 2000 Thus the data on a stream is itself a valid XML document which uses the UTF-8 character encoding. The document type declaration which defines the validity follows. Each time a complete command is written to a stream, that stream is flushed. 3.6 Asynchronous Requests A command that results in a reply is known as a request. Requests are entirely asynchronous. Several requests can be made without waiting for a reply and replies need not arrive in the order in which the corresponding requests were issued. Each stream generates a sequence identifier for each request. If S is the generated sequence identifier, the request will contain the entry: S The matching reply will contain the entry: S Sequence identifiers must be unique long enough to correctly match a request with its reply. Sequence identifiers generated from a signed 64-bit counter are more that adequate for satisfying the uniqueness constraint. 3.7 Profiles A user's profile is stored at the user's contact place. The profile is given as a partial map from strings to strings. When transferred by the protocol, they are encoded as a properties object. A user's profile must not contain entries for the following keys: "action", "request", and "response". In this version of the protocol, the semantics of two keys is defined. The "message" attribute is a description of the user to be displayed with the user's online status. The "buddies" attribute is the XML representation of a buddy list, a properties object encoding interest in presence information. Ramsdell Informational [Page 7] Internet Draft SIMP 1.1 Protocol May 2000 A user can request that the presence service notify the user when the online status of another user, called a buddy, changes. A user can name sets of buddies. A named set is called group, and a set of buddies is a white space separated sequence of IMAs. A buddy list maps group names to sets of buddies. What follows is a user's profile represented as an XML properties object. The user has two groups named Pals and Coworkers. Pals has one member, friend@neighbor, and Coworkers has two members, fella@home and guy@work. Joe Manager of MITRE <?xml version="1.0"?> <properties> <entry key='Pals'>friend@neighbor </entry> <entry key='Coworkers'>fella@home guy@work</entry> </properties> 3.8 Access Control Lists Access control decisions on behalf of the user are made at the user's contact place. A client is used to modify an access control list, so it is passed between a server and the client. This section defines its representation as a properties object. An access control list is used to decide if a request is permitted. Abstractly, the decision depends on three parameters, the originator of the request, the operation requested, and the validity of a signature if the request is signed. The originator of the request is an IMA. There are six operations, "send", "fetch", "subscribe", "unsubscribe", "change", and "end". The "action" attribute of a request determines the operation. In this version of the protocol, the operation is the last word of the "action" attribute of every checked request. In representing an access control list as a properties object, each key is either an IMA or "everybody". The value associated with a key is a list of white space separated operations. An operation is proceeded with a plus sign if a valid signature is required for the operation. The access decision is made as follows. If the properties object has Ramsdell Informational [Page 8] Internet Draft SIMP 1.1 Protocol May 2000 an entry with the originator's IMA as a key, the value is the list of operations used to make the decision. Otherwise, if the domain name of the IMA is HOST, and the properties object has an entry with "@HOST" as a key, the value is the list of operations used to make the decision. Otherwise, if there is an entry with the key "everybody", the value is the list of operations used to make the decision. Otherwise, all operations are permitted. A sample access control list represented as a properties object follows. In this example, the user permits all operations from user "friend" at "neighbor", forbids all operations from any user at "bad", and allows all operations from all other users as long as they are signed. send fetch subscribe unsubscribe change end +send +fetch +subscribe +unsubscribe +change +end 4. Notation The SIMP protocol is built on the exchange of commands via streams. Commands of a particular form are used to request specific actions. The remainder of this document describes the actions associated with commands of a given form. This section introduces the notation used to make the association via a command synopsis. A command synopsis consists of four parts. The path component gives the connection to which a command may be issued by a given class of programs. The operation component gives the operation used during the access control decision. This component is empty when no access decision is associated with the command. The syntax component gives the syntactic constraints on a properties object that determine if the command is of a particular form. The reply component gives the syntactic constraints of the various possible replies to a request. The reply component is empty when the command is not a request. A command synopsis template follows. Path: path Operation: operation (optional) command pattern - reply pattern (optional) - reply pattern (optional) Ramsdell Informational [Page 9] Internet Draft SIMP 1.1 Protocol May 2000 4.1 Path Notation The path notation describes which class of programs can issue a command. The two classes are client and server, abbreviated as C and S. There are two connections to which a command can be issued, a routing connection, and a notification connection, abbreviated R and N respectively. A path is a program class, and a connection separated by the symbol ->. Thus S->R means the command it describes may be issued by a server to a routing connection. 4.2 Syntactic Constraints A pattern matching notation is used to present syntactic constraints on properties objects. 4.2.1 Value Types In a properties object, the value associated with a key is an arbitrary string, however, certain commands impose more structure on some values. For example, when a request is used to send an instant message, the "from" attribute is an IMA. A description of the value types used in the specification follows. 4.2.1.1 String An unrestricted sequence of characters. 4.2.1.2 IMA Every instant message address is syntactically an Internet email address as described in RFC 822. Each IMA has exactly one at sign character (@) separating a user name and a domain name. The user name "notifier" is reserved for use by servers. Servers have their own IMA so that they can sign commands they originate. 4.2.1.3 Time An integer giving a duration in milliseconds. 4.2.1.4 Date An integer giving a date as a number of milliseconds since the beginning of the Unix Epoch, which began at midnight, January 1, 1970 UTC. This may change in the future be a date in the fixed length subset of the format defined by RFC 1123 (an update to RFC 822). Ramsdell Informational [Page 10] Internet Draft SIMP 1.1 Protocol May 2000 4.2.1.5 Int A 32-bit signed integer. 4.2.1.6 State One of the strings "online" or "offline". 4.2.1.7 Mime A MIME type [MIME]. 4.2.1.8 Version A version number of the form major.minor, where both major and minor are small unsigned integers with no leading zeros. 4.2.2 Well-Formed Commands For each form of command, a set of attributes must be defined, and the value associated with each attribute must satisfy some syntactic constraints. Consider a properties object constrained as follows, the "action" attribute must be "fetch", the "to" attribute must be an IMA, and the "from" attribute must be an IMA. These constraints on the object are shown with the pattern: fetch(ima to, ima from) Some entries are optional and identified by surrounding brackets. For example, in the send command, the "reply to" attribute need not be defined, but when it is, it must be an IMA. send(ima to, ima from, [ima reply to], mime type, string body) Given a pattern, a command is well-formed if it defines the various attributes given by the pattern, and the value associated with each attribute meets the syntactic constraints given by the value type of the attribute in the pattern. 4.3 Access Control Constraints Some requests are subject to access control. An operation will be associated with each class of controlled requests. A request subject to access control must define the "to" and "from" attributes, and their values must be IMAs. An access decision is made at the contact place of the recipient of the request. If the object is signed, the Ramsdell Informational [Page 11] Internet Draft SIMP 1.1 Protocol May 2000 signature is validated. The access control list of the recipient is used to make the decision using the given operation and the algorithm presented in Section 3.8. Note that a reply can be signed, but the validity of the signature will only be checked by a client. 5. General Client Requests A client can issue these requests via its notification connection or via any routing connection. Servers can route the requests using a routing connection. In each request, the "to" attribute is the recipient, and the "from" attribute is the originator of the message. 5.1 Send Path: C->N, C->R Operation: send send(ima to, ima from, [ima reply to], mime type, string body) - okay(string message) - error(string message) The send request sends an instant message to the recipient. The "type" attribute is the MIME type of the body of the message. If present, the "reply to" attribute specifies the IMA to be preferred when replying to the originator. The properties object displayed on Page 6 is a well-formed send request. 5.2 Fetch Path: C->N, C->R Operation: fetch fetch(ima to, ima from) - describe(ima regarding, state status, [date online], string message) - error(string message) The fetch request seeks the current presence information associated with the user given by the "to" attribute. When the request succeeds, the reply contains the online status of the recipient, the date at which the recipient connected if the user is online, and the message from the user's profile. The IMA of the recipient is given in the "regarding" attribute of the reply. Ramsdell Informational [Page 12] Internet Draft SIMP 1.1 Protocol May 2000 5.3 Subscribe Path: C->N, C->R Operation: subscribe subscribe(ima to, ima from, time duration) - describe(ima regarding, state status, [date online], string message, time duration, string opaque) - error(string message) The subscribe request asks that the originator of the message be informed of changes in the presence information associated with the user given by the "to" attribute. The duration of the requested subscription is also a parameter of the request. If the requested duration is negative, the maximum allowed duration is requested. A successful reply includes the current presence information, the subscription duration granted, and an opaque identifier used to terminate a subscription. The IMA of the recipient in given in the "regarding" attribute of the reply. 5.4 Unsubscribe Path: C->N, C->R Operation: unsubscribe unsubscribe(ima to, ima from, string opaque) - okay(string message) - error(string message) The unsubscribe request prematurely terminates a subscription. The opaque value must match the one returned in the subscription request. This ensures only the subscriber is the source of this request. 5.5 Inquire Path: C->N, C->R inquire(ima to, ima from) - okay(string message) - error(string message) The inquire request seeks information about the server providing the contact place named by the IMA to. 6. Server Notification Requests and Commands The following messages originate from the contact place of the user supplying presence information. If HOST is the domain name associated with the contact place, the originator's IMA for these commands is notifier@HOST. Servers have their own IMA so that they Ramsdell Informational [Page 13] Internet Draft SIMP 1.1 Protocol May 2000 can sign commands they originate. 6.1 Note Change Path: S->R, S->N Operation: change note change(ima to, ima from, ima regarding, state status, [date online], string message) - okay(string message) This request is generated if the user given by the "to" attribute is subscribed to receive presence notifications for the user given by the "regarding" attribute, and the presence information has been changed. If there is no reply to this request or the reply is not a well-formed okay command, the subscription can be dropped by the server. 6.2 Note Subscription End Path: S->R, S->N Operation: end note subscription end(ima to, ima from, ima regarding, state status, [date online], string message) - okay(string message) - error(string message) The subscriber given by the "to" attribute is notified that the subscription to presence notifications for the user given by the "regarding" attribute has been ended prematurely. A user may receive this command if the server providing the presence information is being shut down in an orderly fashion or if the owner of the presence information dropped the subscription. 6.3 Note Subscription Path: S->N note subscription(ima subscriber) This command informs the owner of some presence information that the user given by the "subscriber" attribute has subscribed to receive presence notifications. When a notification connection is opened to a user's contact place, this command is used to notify the user of the current set of subscribers. Ramsdell Informational [Page 14] Internet Draft SIMP 1.1 Protocol May 2000 6.4 Note Subscription Lapse Path: S->N note subscription lapse(ima subscriber) This command informs the owner of some presence information that the user given by the "subscriber" attribute is no longer subscribed to receive presence notifications. 6.5 Divert Path: S->N divert(string nonce, string opaque, string algorithm, string host, int port) A client receives this command when the server is closing the current notification connection, while suggesting an alternative. A client may create a new notification connection using the connect request described in the next section. Alternatively, the client may terminate its current session. 7. Client Connection Requests and Commands With the exception of the login request, the remaining requests and commands are issued by a client through a notification connection after user authentication. 7.1 Login Path: C->R login(string user) - challenge(string nonce, string opaque, string algorithm, version min version, version max version, string host, int port) - error(string message) The login protocol is loosely based on HTTP digest authentication [HTTP Auth]. When the client receives the challenge, the client constructs a string consisting of the user name, the password, and the nonce, each separated by the colon character. A digest of the string is formed using the given algorithm which by default is MD5. A Base64 encoding [Base64] of the digest is the authorization string supplied in the connect request. In the login protocol, a nonce and an opaque value are strings with no interesting internal structure from the point of view of outside observers of the exchange. Ramsdell Informational [Page 15] Internet Draft SIMP 1.1 Protocol May 2000 A server advertises support for a range of protocol versions with the "min version" and "max version" attributes. 7.2 Connect Path: C->N connect(string authorization, string opaque, version version) - self(*) where * is the profile - error(string message) A client opens a notification connection to a server using the host and port returned in the login request. The first request on that connection must be the connect request. It supplies the authorization described above, the opaque string from the login reply, and a version number. The "version" attribute is the version number of the protocol to be used by the client. This number should be within the range of numbers advertised by the server. A successful reply to the connect request includes the user's profile. The connect request is also used in conjunction with the divert command. 7.3 Logout A client logs out by closing its notification connection. 8. Client Profile Requests 8.1 Get Profile Path: C->N get profile() - self(*) where * is the profile - error(string message) This request returns the user's profile. 8.2 Set Profile Path: C->N set profile(*) where * is the new profile - okay(string message) - error(string message) This request sets the user's profile. Ramsdell Informational [Page 16] Internet Draft SIMP 1.1 Protocol May 2000 9. Client Access Control List Requests 9.1 Get ACL Path: C->N get acl() - self(*) where * is the access control list - error(string message) This request returns the user's access control list. 9.2 Set ACL Path: C->N set acl(*) where * is the new access control list - okay(string message) - error(string message) This request sets the user's access control list. 10. Client Subscription Requests 10.1 Drop Subscription Path: C->N drop subscription(ima subscriber) - okay(string message) - error(string message) This request drops the subscription of the user given by the "subscriber" attribute. 11. Encapsulation of Signed Commands The authenticity of some commands can be established using digital signatures. 11.1 Encapsulate encapsulate(ima to, string contents, string signature, string algorithm, string certificate) The encapsulate command acts as an envelope for a digitally signed command. Any command that includes a "from" attribute giving the IMA of the originator of the command, can be digitally signed. The "to" attribute is the recipient of the signed command. The "contents" attribute is the XML representation of the signed command. The "signature" attribute is the Base64 encoding of the digital signature Ramsdell Informational [Page 17] Internet Draft SIMP 1.1 Protocol May 2000 of the signed command when represented as an array of UTF-8 encoded bytes. The "algorithm" attribute is the name of the algorithm used to generate the signature, which by default is SHA-1/DSA. The "certificate" attribute contains the Base64 encoding of a DER encoded X.509 certificate that must contain the originator's IMA as the distinguished name of the subject represented by the certificate. When using version 3 certificates, the IMA may appear as a subject alternative name, instead of as the distinguished name. 12. Unrecognized Requests When a client receives a request it does not recognize, it must reply with a message of the form: error(string message) 13. Discussion The SIMP 1.1 Protocol has been implemented and released with an open source license. It is available at the URI http://simp.mitre.org. Both the server and the client have been implemented in Java. They run on machines with a Java 2 runtime environment. The result is an instant messaging system that is both distributed and easily to distribute. The [Basis] document provided valuable ideas adopted by this protocol, however, a unique aspect of this protocol is layering of a specific forms of requests on top of a generic layer designed to exchange only one type of data structure. This layering is reflected in the code by separate and fairly independent modules for each layer. The layering also greatly eases the effort required to modify the protocol and add new features. 14. Acknowledgments Jay A. Carlson conceived this task and served as our link to the IMPP Working Group. In conjunction with the author, this protocol was implemented and debugged by Galen B. Williamson and Sasha P. Caskey. Jeffrey L. Kurtz provided valuable feedback on an early draft of this document. This effort was performed under the Collaborative Services Project and funded by The MITRE Corporation's Technology Program. The project is led by Roderick J. Holland. Ramsdell Informational [Page 18] Internet Draft SIMP 1.1 Protocol May 2000 15. References [Base64] Base64 Content-Transfer-Encoding. A method of transporting binary data defined by MIME. See: RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. N. Freed and N. Borenstein. November 1996. [Basis] Proposed Design Decisions for IMPP. Internet Draft. M. Day, S. Aggarwal, G. Mohr, G. Hudson. See draft-day-impp-basis-00.txt. October 1999. [Email] Electronic Mail. See RFC 821, RFC 822, and RFC 1123. [HTTP Auth] HTTP Authentication: Basic and Digest Access Authentication. RFC 2617. J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, and L. Stewart. June 1999. [MIME] Multipurpose Internet Mail Extensions. See RFC 822, RFC 2045, RFC 2046, RFC 2047, RFC 2048, and RFC 2049. [XML] Extensible Mark Up Language. A W3C recommendation. See http://www.w3.org/TR/1998/REC-xml-19980210 for the 10 February 1998 version. [XMLDSIG] XML Signature Core Syntax and Processing. Specifies XML digital signature processing rules and syntax. A W3C Working Draft. See http://www.w3.org/TR/xmldsig-core/. 16. Glossary ACL : access control list. access control list : used at a contact place to decide if a request is permitted. The decision depends on three parameters, the originator of the request, the operation requested, and the validity of a signature if the request is signed. buddy : an instant message address that is part of a buddy list. buddy list : a partial map from group names to groups. A buddy list is associated with a contact place. When a contact place's user is Ramsdell Informational [Page 19] Internet Draft SIMP 1.1 Protocol May 2000 online, the contact place requests that it be notified of any changes to each buddy's presence information. command : a properties object with an "action" attribute. contact place : provides presence information and, when its user is online, a relay point for instant messages. description : text associated with a contact place that is distributed as presence information. domain name : the part of an instant message address that identifies the home server. encapsulated command : a command that contains a digitally signed command. group : a set of buddies. home server : the server providing a given contact place. instant message : a small typed message delivered immediately or dropped if the recipient is not online. IMA : instant message address. instant message address : identifies a contact place. notifier : the user name of a server. notifier connection : a connection associated with a contact place and used by a server to deliver notifications. operation : a set of requests that are grouped together for the purposes of making an access control decision. partial map : a function that assigns a unique value to a subset of the elements in its domain. path : describes the originator and the connection used by a command. presence information : the description and online status associated with a contact place. profile : the persistent data, excluding an ACL, associated with a contact place. Ramsdell Informational [Page 20] Internet Draft SIMP 1.1 Protocol May 2000 properties object : a partial map from strings to strings. reply : a command that is invoked by a request. request : a command that invokes a reply. response : a synonym for a reply. routing connection : a connection used by clients and servers to deliver commands to a server. signed command : a digitally signed command. See encapsulated command. SIMP : simple instant messaging and presence. state : one of the strings "online" or "offline". stream : a sequence of commands transferred in one direction by both routing and notification connections. user name : the part of an instant message address that identifies the contact place within a home server. version number : a number of the form major.minor, where both major and minor are small unsigned integers with no leading zeros. well-formed command : given a pattern, a command is well-formed if it defines the various attributes given by the pattern, and the value associated with each attribute meets the syntactic constraints given by the value type of the attribute in the pattern. 17. Author's Address John D. Ramsdell Mail Stop K329 202 Burlington Road Bedford, MA 01730-1420 ramsdell@mitre.org Ramsdell Informational [Page 21]