Network Working Group Robert Siemborski INTERNET-DRAFT Carnegie Mellon University Intended Category: Experimental December, 2002 The MUPDATE Distributed Mailbox Database Protocol 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 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. Distribution of this memo is unlimited. Abstract As the demand for high-performance mail delivery agents increases, it becomes apparent that single-machine solutions are inadequate to the task, both because of capacity limits and that the failure of the single machine means a loss of mail delivery for all users. It is preferable to allow many machines to share the responsibility of mail delivery. The Mailbox Update (MUPDATE) protocol allows a group of IMAP (or POP3) servers to function with a unified mailbox namespace. This document is intended to serve as a reference guide to that protocol. Please note that this specification is provided to give information to the internet community; it is anticipated that it would need to be revised before widespread adaption. Siemborski Expires June, 2003 [Page 1] The MUPDATE Protocol December, 2002 Table of Contents 1. Changes Since -01 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Changes Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 3 3. How to Read This Document . . . . . . . . . . . . . . . . . . . . 3 4. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 5.1. Atoms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5.2. Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Server Responses . . . . . . . . . . . . . . . . . . . . . . . . 4 6.1. Response: OK . . . . . . . . . . . . . . . . . . . . . . . . . 4 6.2. Response: NO . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.3. Response: BAD . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.4. Response: BYES . . . . . . . . . . . . . . . . . . . . . . . . 5 6.5. Response: RESERVE . . . . . . . . . . . . . . . . . . . . . . . 6 6.6. Response: MAILBOX . . . . . . . . . . . . . . . . . . . . . . . 6 6.7. Response: DELETE . . . . . . . . . . . . . . . . . . . . . . . 6 6.8. Server Initial Response . . . . . . . . . . . . . . . . . . . . 7 7. Client Commands . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Command: ACTIVATE . . . . . . . . . . . . . . . . . . . . . . . 8 7.2. Command: AUTHENTICATE . . . . . . . . . . . . . . . . . . . . . 8 7.3. Command: DEACTIVATE . . . . . . . . . . . . . . . . . . . . . . 9 7.4. Command: DELETE . . . . . . . . . . . . . . . . . . . . . . . . 9 7.5. Command: FIND . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.6. Command: LIST . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.7. Command: LOGOUT . . . . . . . . . . . . . . . . . . . . . . . . 10 7.8. Command: NOOP . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.9. Command: RESERVE . . . . . . . . . . . . . . . . . . . . . . . 10 7.10. Command: UPDATE . . . . . . . . . . . . . . . . . . . . . . . 11 8. MUPDATE Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 11 9. MUPDATE URL Scheme . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Formal Syntax for the MUPDATE URL scheme . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 14 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 15 12. Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 14. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 16 Siemborski Expires June, 2003 [Page 2] The MUPDATE Protocol December, 2002 1. Changes Since -01 1. Add IANA considerations section requesting a TCP port number. 2. Split references into normative/informative. 2. Changes Since -00 1. Added required-to-implement SASL mechanism: GSSAPI. 2. Slight wording change in Server Initial Response section. 3. Allow untagged BAD responses. 3. How to Read This Document The key words "MUST, "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Lev- els" [KEYWORDS] In examples, "C:" and "S:" indicate lines sent by the client and server respectively. 4. Introduction In order to support an architecture where there are multiple [IMAP] servers sharing a common mailbox database, it is necessary to be able to provide atomic mailbox operations, as well as offer suffi- cient guarantees about database consistency. The primary goal of the MUPDATE protocol is to be simple to imple- ment yet allow for database consistency between participants. 5. Protocol Overview The MUPDATE protocol assumes a reliable data stream such as a TCP network connection. This document requests that the IANA register a TCP port number with the short name of "mupdate" for this purpose. Current implementations are using port 2004. In the current implementation of the MUPDATE protocol there are three types of participants: a single master server, slave (or replica) servers, and clients. The master server maintains an authoritative copy of the mailbox database. Slave servers connect to the MUPDATE master server as clients, and function as replicas from the point of view of end clients. End clients may connect to either the master or any slave and perform searches against the Siemborski Expires June, 2003 [Page 3] The MUPDATE Protocol December, 2002 database, however operations that change the database can only be performed against the master. For the purposes of protocol discus- sion we will consider a slave's connection to the master identical to that of any other client. After connection, all commands from a client to server must have an associated unique tag which is an alphanumeric string. MUPDATE uses data formats similar to those used in [ACAP]. That is, atoms and strings. All commands and tags in the protocol are trans- mitted as atoms. All other data is considered to a string, and must be quoted or transmitted as a literal. 5.1. Atoms An atom consists of one or more alphanumeric characters. 5.2. Strings As in [ACAP], a string may be either literal or a quoted string. A literal is a sequence of zero or more octets (including CR and LF), prefix-quoted with an octet count in the form of an open brace ("{"), the number of octets, an optional plus sign to indicate that the data follows immediately (a non-synchronized literal), a close brace ("}"), and a CRLF sequence. If the plus sign is omitted (a synchronized literal), then the receiving side MUST send a "+ go ahead" response, and the sending side MUST wait for this response. Strings that are sent from server to client SHOULD NOT be in the synchronized literal format. A quoted string is a sequence of zero or more 7-bit characters, excluding CR, LF, and the double quote (<">), with double quote characters at each end. The empty string is represented as either "" (a quoted string with zero characters between double quotes) or as {0} followed by CRLF (a literal with an octet count of 0). 6. Server Responses Every client command in the MUPDATE protocol may receive one or more tagged responses from the server. Each response is preceeded by the same tag as the command that elicited the response from the server. Siemborski Expires June, 2003 [Page 4] The MUPDATE Protocol December, 2002 6.1. Response: OK A tagged OK response indicates that the operation completed success- fully. There is a mandatory implementation-defined string after the OK response. This response also indicates the beginning of the streaming update mode when given in response to an UPDATE command. Example: C: N01 NOOP S: N01 OK "NOOP Complete" 6.2. Response: NO A tagged NO response indicates that the operation was explicitly denied by the server or otherwise failed. There is a mandatory implementation-defined string after the NO response that SHOULD explain the reason for denial. Example: C: A01 AUTHENTICATE "PLAIN" S: A01 NO "PLAIN is not a supported SASL mechanism" 6.3. Response: BAD A tagged BAD response indicates that the command from the client could not be parsed or understood. There is a mandatory implementa- tion-defined string after the BAD response to provide additional information about the error. Note that untagged BAD responses are allowed if it is unclear what the tag for a given command is (for example, if a blank line is received by the mupdate server, it can generate an untagged BAD response). In the case of an untagged response, the tag should be replaced with a "*". Example: C: C01 SELECT "INBOX" S: C01 BAD "This is not an IMAP server" C: S: * BAD "Need Command" Siemborski Expires June, 2003 [Page 5] The MUPDATE Protocol December, 2002 6.4. Response: BYE A tagged BYE response indicates that the server has decided to close the connection. There is a mandatory implementation-defined string after the bad response that SHOULD explain the reason for closing the connection. The server MUST close the connection immediately after transmitting the BYE response. Example: C: L01 LOGOUT S: L01 BYE "User Logged Out" 6.5. Response: RESERVE A tagged RESERVE response may only be given in response to a FIND, LIST, or UPDATE command. It includes two parameters: the name of the mailbox that is being reserved (in mUTF-7 encoding, as specified in [IMAP]) and a location string whose contents is defined by the clients that are using the database, though it is RECOMMENDED that the format of this string be the hostname of the server which is storing the mailbox. This response indicates that the given name is no longer available in the namespace, though it does not indicate that the given mailbox is available to clients at the current time. Example: S: U01 RESERVE "internet.bugtraq" "mail2.andrew.cmu.edu" 6.6. Response: MAILBOX A tagged MAILBOX response may only be given in response to a FIND, LIST, or UPDATE command. It includes three parameters: the name of the mailbox that is currently reserved, a location string (as with RESERVE), and a client-defined string that specifies the IMAP ACL [IMAP-ACL]of the mailbox. This message indicates that the given mailbox is ready to be accessed by clients. Example: S: U01 MAILBOX "internet.bugtraq" "mail2.andrew.cmu.edu" "anyone rls" Siemborski Expires June, 2003 [Page 6] The MUPDATE Protocol December, 2002 6.7. Response: DELETE A tagged DELETE response may only be given in response to an UPDATE command, and MUST NOT be given before the OK response to the UPDATE command is given. It contains a single parameter, that of the mail- box that should be deleted from the slave's database. This response indicates that the given mailbox no longer exists in the namespace of the database, and may be given for any mailbox name, active, reserved, or nonexistent. (Though implementations SHOULD NOT issue DELETE responses for nonexistant mailboxes). Example: S: U01 DELETE "user.rjs3.sent-mail-jan-2002" 6.8. Server Initial Response Upon connection of the client to the server, the server MUST issue a banner, of the following format: The banner MUST contain a line that begins with "* AUTH" and contain a space-separated list of SASL mechanisms that the server will accept for authentication. The mechanism names are transmitted as strings, and servers MUST advertise at least one available mecha- nism. The last line of the banner MUST start with "* OK MUPDATE" and be followed by four strings: the server's hostname, an implementation- defined string giving the name of the implementation, an implementa- tion-defined string giving the version of the implementation, and a string that indicates if the server is a master or a slave. The master/slave indication MUST be either "(master)" or an MUPDATE URL that defines where the master can be contacted. Any unrecognized responses before the "* OK MUPDATE" response MUST be ignored by the client. Example: S: * AUTH KERBEROS_V4 GSSAPI S: * OK MUPDATE "mupdate.andrew.cmu.edu" "Cyrus" "v2.1.2" "(master)" 7. Client Commands The following are valid commands that a client may send to the MUP- DATE server: AUTHENTICATE, ACTIVATE, DEACTIVATE, DELETE, FIND, LIST, Siemborski Expires June, 2003 [Page 7] The MUPDATE Protocol December, 2002 LOGOUT, NOOP, RESERVE, and UPDATE. Before a successful AUTHENTICATE command has occurred, the server MUST NOT accept any commands except for AUTHENTICATE and LOGOUT (and SHOULD reply with a NO response for all other commands). 7.1. Command: ACTIVATE The ACTIVATE command has 3 parameters: the mailbox name, its loca- tion, and its ACL. This command MUST NOT not be issued to a slave server. This command can also be used to update the ACL or location informa- tion of a mailbox. Note that it is not a requirement for a mailbox to be reserved (or even exist in the database) for an ACTIVATE com- mand to succeed, implementations MUST allow this behavior as it facilitates synchronization of the database with the current state of the mailboxes. 7.2. Command: AUTHENTICATE The AUTHENTICATE command initiates a [SASL] negotiation session between the client and the server. It has two parameters. The first parameter is mandatory, and is a string indicating the desired [SASL] mechanism. The second is a string containing an optional BASE64 encoded (as defined in section 6.8 of [MIME]) client first send. All of the remaining SASL blobs that are sent MUST be sent across the wire must be in BASE64 encoded format, and followed by a CR and LF combination. They MUST NOT be encoded as strings. Clients may cancel authentication by sending a * followed by a CR and LF. The [SASL] service name for the MUPDATE protocol is "mupdate". Implementations are REQUIRED to implement the GSSAPI [SASL] mecha- nism, though they SHOULD implement as many mechanisms as possible. If a security layer is negotiated, it should be used directly fol- lowing the CR and LF combination at the end of the server's OK response. (i.e. beginning with the client's next command) Only one successful AUTHENTICATE command may be issued per session. Siemborski Expires June, 2003 [Page 8] The MUPDATE Protocol December, 2002 7.3. Command: DEACTIVATE The DEACTIVATE command takes two parameters, the mailbox name and location data. The mailbox MUST already exist and be activated on the MUPDATE server. If the server responds OK, then the mailbox name has been moved to the RESERVE state. If the server responds NO, then the mailbox name has not been moved (for example, the mail- box was not already active). Any ACL information that is known about the mailbox MAY be lost when a DEACTIVATE succeeds. This com- mand MUST NOT be issued to a slave. The typical sequence for mailbox creation is: C: R01 ACTIVATE "user.rjs3.new" "mail3.andrew.cmu.edu!u4" S: R01 OK "Mailbox Reserved." C: A01 DEACTIVATE "user.rjs3.new" "mail3.andrew.cmu.edu!u4" S: A01 OK "Mailbox Reserved." 7.4. Command: DELETE The DELETE command takes only a single parameter, the mailbox name to be removed from the database's namespace. The server SHOULD give a NO response if the mailbox does not exist. This command MUST NOT be issued to a slave server. 7.5. Command: FIND The FIND command takes a single parameter, a mailbox name. The server then responds with the current record for the given mailbox, if any, and an OK response. Example (mailbox does not exist): C: F01 FIND "user.rjs3.xyzzy" S: F01 OK "Search Complete" Example (mailbox is reserved): C: F01 FIND "user.rjs3" S: F01 RESERVE "user.rjs3" "mail4.andrew.cmu.edu" S: F01 OK "Search Complete" 7.6. Command: LIST The LIST command is similar to running FIND across the entire database. The LIST command takes a single optional parameter, which Siemborski Expires June, 2003 [Page 9] The MUPDATE Protocol December, 2002 is a prefix to try to match against the location field of the records. Without the parameter, LIST returns every record in the database. For each mailbox that matches, either a MAILBOX or a RESERVE response (as applicable) is sent to the client. When all responses are complete, an OK response is issued. Example: C: L01 LIST S: L01 RESERVE "user.rjs3" "mail4.andrew.cmu.edu!u2" S: L01 MAILBOX "user.leg" "mail2.andrew.cmu.edu!u1" "leg lrswipcda" S: L01 OK "List Complete" C: L02 LIST "mail4.andrew.cmu.edu!" S: L02 RESERVE "user.rjs3" "mail4.andrew.cmu.edu!u2" S: L02 OK "List Complete" 7.7. Command: LOGOUT The LOGOUT command tells the server to close the connection. Its only valid response is the BYE response. The LOGOUT command takes no parameters. 7.8. Command: NOOP The NOOP command takes no parameters. Provided the client is authenticated, its only acceptable response is an OK. Any idle timeouts that the server may have on the connection SHOULD be reset upon recipt of this command. If this command is issued after an UPDATE command has been issued, then the OK response also indicates that all pending database updates have been sent to the client. That is, the slave can guar- antee that its local database is up to date as of a certain time by issuing a NOOP and waiting for the OK. The OK MUST NOT return until all updates that were pending at the time of the NOOP have been sent. 7.9. Command: RESERVE The RESERVE command takes two parameters (just like the RESERVE response), the mailbox name to reserve and location data. If the server responds OK, then the mailbox name has been reserved. If the server responds NO, then the mailbox name has not been reserved (for example, another server has reserved it already). This command MUST NOT be issued to a slave. Siemborski Expires June, 2003 [Page 10] The MUPDATE Protocol December, 2002 The typical sequence for mailbox creation is: C: R01 RESERVE "user.rjs3.new" "mail3.andrew.cmu.edu!u4" S: R01 OK "Mailbox Reserved." C: A01 ACTIVATE "user.rjs3.new" "mail3.andrew.cmu.edu!u4" "rjs3 lrswipcda" S: A01 OK "Mailbox Activated." 7.10. Command: UPDATE The UPDATE command is how a slave initializes an update stream from the master (though it is also valid to issue this command to a slave). In response to the command, the server returns a list of all mailboxes in its database (the same results as a parameterless LIST command) followed by an OK response. From this point forward, whenever an update occurs to the master database, it will immedi- ately stream the update to the slave. That is, it will send RESERVE, MAILBOX, or DELETE responses as they are applicable. After a client has issued an UPDATE command, it may only issue NOOP and LOGOUT commands for the remainder of the session. Example: C: U01 UPDATE S: U01 MAILBOX "user.leg" "mail2.andrew.cmu.edu!u1" "leg lrswipcda" S: U01 MAILBOX "user.rjs3" "mail3.andrew.cmu.edu!u4" "rjs3 lrswipcda" S: U01 RESERVE "internet.bugtraq" "mail1.andrew.cmu.edu!u5" "anyone lrs" S: U01 OK "Streaming Begins" S: U01 RESERVE "user.leg.new" "mail2.andrew.cmu.edu!u1" S: U01 MAILBOX "user.leg.new" "mail2.andrew.cmu.edu!u1" "leg lrswipcda" C: N01 NOOP S: U01 DELETE "user.leg.new" S: N01 OK "NOOP Complete" 8. MUPDATE Formal Syntax The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF]. This uses the ABNF core rules as specified in Appendix A of [ABNF]. Except as noted otherwise, all alphabetic characters are case- Siemborski Expires June, 2003 [Page 11] The MUPDATE Protocol December, 2002 insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion. Note that this specification also uses some terminals from section 8 of [ACAP]. Siemborski Expires June, 2003 [Page 12] The MUPDATE Protocol December, 2002 cmd-activate = "ACTIVATE" SP string SP string SP string cmd-authenticate = "AUTHENTICATE" SP sasl-mech [ SP string ] cmd-delete = "DELETE" SP string cmd-find = "FIND" SP string cmd-list = "LIST" [ SP string ] cmd-logout = "LOGOUT" cmd-noop = "NOOP" cmd-reserve = "RESERVE" SP string SP string cmd-update = "UPDATE" command = tag SP command-type CRLF command-type = cmd-activate / cmd-authenticate / cmd-delete / cmd-find / cmd-list / cmd-logout / cmd-noop / cmd-reserve / cmd-update response = tag SP response-type CRLF response-type = rsp-ok / rsp-no / rsp-bad / rsp-bye / rsp-mailbox / rsp-reserve / rsp-delete rsp-bad = "BAD" SP string rep-bye = "BYE" SP string rsp-mailbox = "MAILBOX" SP string SP string SP string rsp-no = "NO" SP string rsp-ok = "OK" SP string rsp-reserve = "RESERVE" SP string SP string rsp-delete = "DELETE" SP string sasl-mech = 1*ATOM-CHAR ; ATOM-CHAR is defined in [ACAP] Siemborski Expires June, 2003 [Page 13] The MUPDATE Protocol December, 2002 string = quoted / literal ; quoted and literal are defined in [ACAP] tag = 1*ATOM-CHAR ; ATOM-CHAR is defined in [ACAP] 9. MUPDATE URL Scheme The MUPDATE URL Scheme is similar to the IMAP URL Scheme [IMAP-URL]. It takes one of two possible forms: mupdate:/// mupdate:/// The first form indicates just the MUPDATE server, the second form indicates both the server and a mailbox to run a FIND against once authenticated to the server. Note that part of may include username and authentication information along with a host- name and port. 9.1. Formal Syntax of the MUPDATE URL scheme This defines the MUPDATE URL scheme using ABNF as defined in [ABNF]. Terminals from the BNF of IMAP URLs [IMAP-URL] are also used. mupdateurl = "mupdate://" iserver "/" [ enc_mailbox ] ; iserver and enc_mailbox are as defined in [IMAP-URL] 10. Security Considerations While no unauthenticated users may make modifications or even per- form searches on the database, it is important to note that this specification assumes no protections of any type for authenticated users. All authenticated users have complete access to the database. For this reason it is important to ensure that accounts that are making use of the database are well secured. A more secure deployment might have all read only access go through a slave, and only have accounts which need write access use the mas- ter. This has the disadvantage of a marginally longer time for updates to reach the clients. Siemborski Expires June, 2003 [Page 14] The MUPDATE Protocol December, 2002 The protocol assumes that all authenticated users are cooperating to maintain atomic operations. Therefore, all new mailboxes SHOULD be RESERVEd before they are ACTIVATEd, despite the fact that the proto- col does not require this, and it is therefore possible for a set of participants which do not obey the provided locking to create an inconsistent database. RESERVEing the mailbox first is not required to perform an activate because this behavior simplifies synchroniza- tion with the actual location of the mailboxes. 11. IANA Considerations This document requests that the IANA provide a TCP port number with the short name of "mupdate". 12. Copyright Copyright (C) The Internet Society (2002). 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 implementation 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 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 Internet Society or other Internet organizations, except as needed for the purpose of devel- oping Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 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. 13. References The following documents contain definitions or specifications that are necessary for correct understanding of this protocol: [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Require- ment Levels", BCP 14, RFC 2119, March 1997 Siemborski Expires June, 2003 [Page 15] The MUPDATE Protocol December, 2002 [IMAP] Crispin, M., "Internet Message Access Protocol", RFC 2060, December 1996. [ABNF] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November, 1997. [MIME] Freed, N. & Bornstein, N., "Multipurpose Internet Mail Extentions (MIME) Part One: Format of Internet Message Bod- ies", RFC 2045, November 1996. [IMAP-ACL] Myers, J., "IMAP4 ACL extention", RFC 2086, January 1997. [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. [IMAP-URL] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997. [ACAP] Newman, C. & Myers, J., "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997. The following document discusses the related POP3 protocol: [POP3] Myers, J. & Rose, M., "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996. 14. Author's Address: Robert Siemborski Carnegie Mellon, Andrew Systems Group Cyert Hall 207 5000 Forbes Avenue Pittsburgh, PA 15213 +1 412 268 7456 rjs3+@andrew.cmu.edu 15. Acknowledgments: Lawrence Greenfield of Carnegie Mellon, for a great deal of input into the first draft of the protocol. Siemborski Expires June, 2003 [Page 16]