Internet Engineering Task Force J. Stracke INTERNET DRAFT eCal draft-stracke-impp-straw-protocol-00.txt May 2000 Expires: November 2000 Strawman IMPP Protocol Suite 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 docu- ments 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. 2. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. 3. Abstract This document sets forth a strawman IMPP protocol suite. It is not asserted that this protocol suite is suitable for standardization, but it does have lessons to teach us as we develop the IMPP standard. Stracke [Page 1] IMPP Strawman May 2000 4. Introduction The IMPP WG is currently expecting to have several alternative pro- posals among which to choose in Pittsburgh. A couple have already been made public; they look good, but I'm not sure they have every- thing they should. Accordingly, I am publishing this strawman proto- col, so that, when the time comes to say what I want, I can have something to point to. This protocol was developed as a research effort at eCal. More information on eCal's IMPP-related research, including a GPL server and class framework for IMPP development in Java, can be found at . 5. Desirable Properties This section lays out characteristics of this protocol which I'd like to see in the eventual IMPP protocol. 5.1. Clients know how to find servers. A client can use an SRV record to find the home server(s) for its domain; it doesn't need to be configured. This would substantially improve manageability for server admins: when a service moves from one host to another, the clients don't have to be reconfigured. It would also simplify configuration for new users: just type in your address and the client will find your server. 5.2. Send and receive are split. The address(es) from which a client sends, if any, do not have to be the as the one(s) whose traffic the client receives. Furthermore, more than one client can receive traffic sent to the same address simultaneously (if the server allows). This gives us the flexibility to create small, focused clients; for example, a client which logs all my incoming messages and runs at the same time as my full-fledged GUI client; or a client which sends notifications but does not receive any messages. The email world has long enjoyed this flexi- bility. (Note, though, that, unlike email, this proposal does not require separate connections for send and receive.) Stracke [Page 2] IMPP Strawman May 2000 5.3. Client-to-server and server-to-server protocols are similar. The client-to-server and server-to-server protocols are essentially similar, though with different authorization models. This simplifies comprehension and implementation, and may actually enable better per- formance in some cases, since the message which a server forwards is often identical to the one it receives. 5.4. End-to-end acknowledgments are not messages. In our discussions last year, we talked about a couple of different ways to do end-to-end acknowledgments. One was to make them messages in their own right (like email DSNs); the other was to send back result codes from the "send message" commands. My objection to the first approach was that it would be too easy to get into a bounce loop; Christophe's objection to the second approach was that it would be too synchronous, as each server would have to assemble the responses from the next hops, and could not respond until all recipi- ents had acknowledged. The approach in this protocol is to use asyn- chronous result codes, which can be interleaved with other commands, so that responses can go all the way back to the original sender without having to wait at intermediate servers. 5.5. Presence is message-based. Presence is built over the same message infrastructure as IM. This gives all the advantages of any message queueing system: we can for- ward presence requests, queue them, etc. At the same time, though, presence is not tied to IM; the addresses use different URLs, and the SRV records use different service names. 6. Address Formats Instant messaging addresses are of the form "im:@". Presence addresses are of the form "pr:@". Presence server addresses are of the form "pr-s:@". 7. Connection Model All traffic flows over TCP. The client opens a connection to the server and keeps the connection open. The server never connects to the client. Servers connect to servers. Server A may have more than one connection open to server B at the same time. If server A decides it has too many connections open, it can close some; but it Stracke [Page 3] IMPP Strawman May 2000 should not close its connection to server B without sending a Close command and waiting for a CloseAck. This is because B may be using that connection to send a message. If A is shutting down, of course, it can close the connection gracelessly. 8. Server location The preferred way to locate a server for a domain is via an SRV lookup. The protocol to look up is "tcp". For client-to-server presence connections, the service is "pr-c"; for client-to-server IM connections, the service is "im-c". For server-to-server presence connections, the service is "pr-s"; for server-to-server IM connec- tions, the service is "im-s". If no SRV record is found, the domain's A record MUST be used instead. (In the A record case, default ports are needed. If this protocol were to be standardized, an IANA registration would be needed; the existing implementation arbitrarily uses TCP port 6803 for all client-to-server connections, and 6809 for all server-to-server connections.) Note that it is possible for a single server to provide both presence and IM services. Capabilities exchange is performed to allow a server to assert which service(s) it provides. Note that this asser- tion MUST NOT be trusted blindly; a connecting server or client which has found a server for one service, which claims supports the other service, MUST double-check that assertion via another SRV lookup. If the first service had an SRV record, and the second one does not, the connecting server or client MUST NOT fall back to the A record. The point of allowing an A fallback is that someone might not have the ability to set up an SRV record for their domain; but, if they can set up one, they can probably to set up the other. Client-to-server is separated from server-to-server because a fire- wall admin may want to be able to control them differently; for exam- ple, they may want to allow incoming server-to-server connections, but not incoming client-to-server connections. Or an implementation may actually split the two halves for scalability reasons. In the client-to-server case, the domain to look up is the domain within which the client wishes to authenticate; in the server-to- server case, it's the domain to which the sender wishes to send. 9. Command Model A command (request or reply) is made up of a sequence of lines, optionally followed by a body. Lines from different commands may be interleaved. The syntax of a command line is: Stracke [Page 4] IMPP Strawman May 2000 line = continuation id SP verb [SP params] LF continuation = "+" / "-" / "." id = 1*digit digit = %x30-39 ; 0-9 verb = 1*alpha alpha = %x41-5A / %x61-7A ; A-Z / a-z params = 1*(%20-%7e) LF = %x0A SP = %x20 Each command has an ID number; lines for the same command all carry that ID number. Each line bears a continuation character. A contin- uation character of "+" indicates that more lines for the same line will follow; "-" indicates that no more lines follow, and there is no body; "." indicates that no more lines follow, and there is a body. If there is a body, then the line is immediately followed by a deci- mal number (call it Len), followed by a LF, followed by Len bytes, which make up the body. (Side note: yes, I am aware that CRLF is preferred; I thought about changing this document, but I decided to leave it, so that this docu- ment could serve as a spec for the protocol actually used by the existing research implementation.) The reply to a request has the same ID number as the request. Clearly, then, ID numbers do not need to be unique for all time, but an implementation about to send a request must use an ID number for which there is no outstanding request (one for which the last reply line has not been received). The params part of each line is for carrying command parameters. Each command specifies whether it may/must carry parameters, and what their format is. There is no need to indicate whether a command is a request or a reply, because it is implicit in the verb: there are no verbs which are sometimes requests and sometimes replies. Command verbs are case-insensitive. Stracke [Page 5] IMPP Strawman May 2000 10. Requests and Replies This section documents each command verb and how it is to be used. The Modes entry on each request refers to whether the verb can is for server-to-server, server-to-client, or client-to-server connections. 10.1. Capabilities request Verb: capabilities Body: None Params: A capability tag (one per line). Multiline: Yes, if there is more than one capability tag to be sent. Modes: Any. Possible replies: None. Upon connect, each end of the connection immediately sends a Capabil- ities command with its capabilities. Capability tags are not case- sensitive. The two defined capability tags are "IM" and "Presence". 10.2. Auth request Verb: auth Body: None Params: The string representation of the client's credentials. Multiline: No. Modes: Client-to-server. Possible replies: AuthAck, AuthNak. A client sends an Auth command immediately after Capabilities, in order to authenticate. The string encoding is in the form of a rela- tive URL with parameters. The only defined relative URL is "pass- word", for username/password credentials. For example, if the client's username is "fred mbongo" and their password is "doctor", then their credentials string is: password?username=fred+mbongo&password=doctor (note the use of URL encoding). Obviously, this is not an ideal authentication system; I do not advocate it. It was just good enough for an experiment. 10.3. AuthAck reply Verb: authack Body: None Stracke [Page 6] IMPP Strawman May 2000 Params: None. Multiline: No. Modes: Server-to-client. Possible replies: None. An AuthAck is sent in reply to a successful Auth command, to indicate that the client is authenticated. 10.4. AuthNak reply Verb: authnak Body: None Params: None. Multiline: No. Modes: Server-to-client. Possible replies: None. An AuthNak is sent in reply to an unsuccessful Auth command, to indi- cate that the client is not authenticated. 10.5. Domain request Verb: domain Body: None Params: domain "/" service Multiline: No. Modes: Server-to-server. Possible replies: DomainAck, DomainNak A server which wishes to send messages from a domain MUST send a Domain command for that domain, to assert that it is authoritative for the domain. The params contain the domain name and the service name ("im" or "pr"). The receiver MUST verify the assertion by per- forming an SRV lookup for the domain and service, just as if the receiver wished to connect to that domain and service; if the IP address of the server issuing the Domain command is not one to which one might connect for that domain and service, the receiver MUST reject the assertion. (This could be strenghtened via a callback mechanism, in which the receiver would connect back to the server and issue a challenge, to make sure that the entity issuing the Domain command is not some other process that just happens to be running on the same machine.) Stracke [Page 7] IMPP Strawman May 2000 10.6. DomainAck reply Verb: domainack Body: None Params: None. Multiline: No. Modes: Server-to-server. A DomainAck is sent in reply to a successful Domain command, to indi- cate that the assertion is believed. 10.7. DomainNak reply Verb: domainnak Body: None Params: None. Multiline: No. Modes: Server-to-server. A DomainNak is sent in reply to an unsuccessful Domain command, to indicate that the assertion is not believed. 10.8. From request Verb: from Body: None Params: An INSTANT INBOX ADDRESS. Multiline: No. Modes: Client-to-server. Possible replies: FromAck, FromNak A client MAY send a From command at any time, to specify the default from address to be used in Send commands that don't specify one. This is an optimization, to permit us to save a little bandwidth in the common case where the client sends from only a single address, without constraining all clients to do so. 10.9. FromAck reply Verb: fromack Body: None Params: None. Multiline: No. Modes: Server-to-client. Stracke [Page 8] IMPP Strawman May 2000 A FromAck is sent in reply to a successful From command, to indicate that the client's credentials permit it to send from the given address. 10.10. FromNak reply Verb: fromnak Body: None Params: None. Multiline: No. Modes: Server-to-client. A FromNak is sent in reply to an unsuccessful From command, to indi- cate that the client's credentials do not permit it to send from the requested address. It may also be sent in response to a Send com- mand, to indicate a similar problem with the address specified in the "from=" parameter. 10.11. Receive request Verb: receive Body: None Params: An INSTANT INBOX ADDRESS. Multiline: No. Modes: Client-to-server. Possible replies: ReceiveAck, ReceiveNak A client MAY send a Receive command at any time, to start receiving messages addressed to an INSTANT INBOX ADDRESS. It would theoreti- cally be possible to extend the protocol so that a client could request to receive messages for an address which is not hosted at the server; the server would then pass on the request to the address's home server. It would be difficult to design an adequate security model, though. Note that it is possible to create a client which only sends a mes- sage, and never registers to receive any. This is useful for various stripped-down cases; for example, someone using a a Web-based (or WAP-based) form to send a message may not be able to receive mes- sages, and so the client should not ask for any. Alternatively, the user might have a split user agent, in which one process sends IMs and the other receives them (for example, if the user is a robot). Stracke [Page 9] IMPP Strawman May 2000 10.12. ReceiveAck reply Verb: receiveack Body: None Params: None. Multiline: No. Modes: Server-to-client. A ReceiveAck is sent in reply to a successful Receive command, to indicate that the client will now start receiving messages sent to the requested address. 10.13. ReceiveNak reply Verb: receivenak Body: None Params: "Auth" / "WrongServer" / "Busy" / "NoMultiple" Multiline: No. Modes: Server-to-client. A ReceiveNak is sent in reply to an successful Receive command. The reason for failure is given in the params. "Auth" means that the client's credentials do not permit receiving at the requested address. "WrongServer" means that the server does not host the requested address. "Busy" means that there is already another client receiving messages at the requested address. "NoMultiple" means that the client is already receiving messages at a different address. (Note that some servers may not issue Busy and NoMultiple errors; they may permit multiple clients per address and/or multiple addresses per client. This is an implementation detail. The exist- ing implementation permits both.) 10.14. Unreceive request Verb: unreceive Body: None Params: An INSTANT INBOX ADDRESS. Multiline: No. Modes: Client-to-server. Possible replies: UnreceiveAck, ReceiveNak A client MAY send a Unreceive command at any time, to stop receiving messages addressed to an INSTANT INBOX ADDRESS. A client need not send Unreceive upon disconnect; it is implicit. Stracke [Page 10] IMPP Strawman May 2000 10.15. UnreceiveAck reply Verb: unreceiveack Body: None Params: None. Multiline: No. Modes: Server-to-client. A UnreceiveAck is sent in reply to an Unreceive command, to indicate that the client will no longer receive messages sent to the requested address. Note that it's possible that the client was not receiving at the given address, but the net result is the same, and there's no real need to report such an error. 10.16. Send request Verb: send Body: Required (the body is the message to send). Params: ("from=<" addr ">") / ("to=<" addr ">") Multiline: Optional. Modes: Any. Possible replies: SendStatus, FromNak Used to send an IM or presence message. Each recipient is specified on a separate line, with a "to=" param. On a client-to-server con- nection, there need not be a line with a from param, provided the client has already issued a From command. No Send command may con- tain more than one from param. The body of the command is a MIME message. Send may be used client-to-server (to start a message on its way), server-to-server (to relay the message) or server-to-client (to deliver the message to its final recipient). 10.17. SendStatus reply Verb: sendstatus Body: None Params: ("Ack" / "Nak" / "Unknown") "=<" addr ">" Multiline: No. Modes: Any. Sent in response to a Send command. A client sends a SendStatus with Ack or Nak immediately upon receipt of the Send (Ack if the message is delivered, Nak if not). A server which will not (or cannot) deliver a message to an address sends Nak= as Stracke [Page 11] IMPP Strawman May 2000 soon as it knows it will not; a server which does deliver a message waits until it receives a SendStatus from the next hop, and then for- wards that reply back to the previous hop. A client which receives a message sends back Ack= immediately (or Nak if the message is rejected for some reason). A server which cannot tell whether the message will be delivered or not (e.g., if it forwards the message over an unreliable channel such as SMS) sends SendStatus Unknown. It might be a nice optimization if, when the Send contained only one to=, the SendStatus could omit the address. 10.18. Close request Verb: close Body: None Params: None. Multiline: No. Modes: Any. Possible replies: CloseAck An endpoint SHOULD send a Close command before closing a connection, and not actually close the connection until receiving CloseAck. This is in case the other end is already sending a message over the con- nection. Naturally, though, all implementations MUST be able to han- dle a connection closed without warning. 10.19. CloseAck reply Verb: closeack Body: None Params: None. Multiline: No. Modes: Any. Sent in response to a Close command. 11. Presence Protocol The presence protocol is a message exchange protocol built over the same core protocol as the instant messaging protocol (above). Requests are sent from presence clients to presence servers. To manipulate its own PRESENCE INFORMATION, a client sends a message to its own presence server; to query another PRESENTITY's PI, a client sends a message to that PRESENTITY's presence server. Presence clients use addresses of the form "pr:@". The presence Stracke [Page 12] IMPP Strawman May 2000 server for the client with the address "pr:@" has the address "pr-s:@". (Obviously, a given presence server implementation will normally respond to more than one pr-s: address.) Beyond this, there's no real need to document the details of this presence protocol: there already exists at least one superior pres- ence proposal (PePP), and mine didn't come up with anything particu- larly interesting. If you want to read it, though, you can find it described at: http://impp.research.ecal.com/java-model/presenceProtocol.html 12. Security Considerations Security considerations are treated too lightly in this document. That's the main reason I'm not submitting this protocol as a full proposal. Among the problems: cleartext passwords; weak authentica- tion of incoming server-to-server connections; no support for encryp- tion. 13. Author's Address: John Stracke Chief Scientist eCal Corp. Email: francis@ecal.com Stracke [Page 13]