idnits 2.17.1 draft-siemborski-mupdate-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 10 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 454 has weird spacing: '...1" "leg lrswi...' == Line 714 has weird spacing: '...for the purpo...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'IMAP-ACL' is defined on line 746, but no explicit reference was found in the text == Unused Reference: 'POP3' is defined on line 761, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2060 (ref. 'IMAP') (Obsoleted by RFC 3501) ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2086 (ref. 'IMAP-ACL') (Obsoleted by RFC 4314) ** Obsolete normative reference: RFC 2222 (ref. 'SASL') (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2192 (ref. 'IMAP-URL') (Obsoleted by RFC 5092) ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Robert Siemborski 3 INTERNET-DRAFT Carnegie Mellon University 4 Intended Category: Experimental April, 2003 6 The MUPDATE Distributed Mailbox Database Protocol 8 10 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Task Force 15 (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet Drafts as 21 reference material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Distribution of this memo is unlimited. 31 Abstract 33 As the demand for high-performance mail delivery agents increases, 34 it becomes apparent that single-machine solutions are inadequate to 35 the task, both because of capacity limits and that the failure of 36 the single machine means a loss of mail delivery for all users. It 37 is preferable to allow many machines to share the responsibility of 38 mail delivery. 40 The Mailbox Update (MUPDATE) protocol allows a group of IMAP (or 41 POP3) servers to function with a unified mailbox namespace. This 42 document is intended to serve as a reference guide to that protocol. 44 Please note that this specification is provided to give information 45 to the Internet community; it is anticipated that it would need to 46 be revised before widespread adaption. 48 The MUPDATE Protocol April, 2003 50 Table of Contents 52 1. Changes Since -02 . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Changes Since -01 . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Changes Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. How to Read This Document . . . . . . . . . . . . . . . . . . . . 3 56 5. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 6. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 58 6.1. Atoms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 6.2. Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 7. Server Responses . . . . . . . . . . . . . . . . . . . . . . . . 4 61 7.1. Response: OK . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 7.2. Response: NO . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 7.3. Response: BAD . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 7.4. Response: BYES . . . . . . . . . . . . . . . . . . . . . . . . 5 65 7.5. Response: RESERVE . . . . . . . . . . . . . . . . . . . . . . . 6 66 7.6. Response: MAILBOX . . . . . . . . . . . . . . . . . . . . . . . 6 67 7.7. Response: DELETE . . . . . . . . . . . . . . . . . . . . . . . 6 68 7.8. Server Capability Response . . . . . . . . . . . . . . . . . . 7 69 8. Client Commands . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 8.1. Command: ACTIVATE . . . . . . . . . . . . . . . . . . . . . . . 8 71 8.2. Command: AUTHENTICATE . . . . . . . . . . . . . . . . . . . . . 8 72 8.3. Command: DEACTIVATE . . . . . . . . . . . . . . . . . . . . . . 9 73 8.4. Command: DELETE . . . . . . . . . . . . . . . . . . . . . . . . 9 74 8.5. Command: FIND . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 8.6. Command: LIST . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 8.7. Command: LOGOUT . . . . . . . . . . . . . . . . . . . . . . . . 10 77 8.8. Command: NOOP . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 8.9. Command: RESERVE . . . . . . . . . . . . . . . . . . . . . . . 11 79 8.10. Command: STARTTLS . . . . . . . . . . . . . . . . . . . . . . 11 80 8.11. Command: UPDATE . . . . . . . . . . . . . . . . . . . . . . . 12 81 9. MUPDATE Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 12 82 10. MUPDATE URL Scheme . . . . . . . . . . . . . . . . . . . . . . . 14 83 10.1. Formal Syntax for the MUPDATE URL scheme . . . . . . . . . . . 14 84 11. Security Considerations . . . . . . . . . . . . . . . . . . . . 14 85 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 15 86 13. Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 15. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 89 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 17 91 The MUPDATE Protocol April, 2003 93 1. Changes Since -02 (RFC Editor: Remove Before Publication) 95 1. Add STARTTLS Command 97 2. Changes Since -01 (RFC Editor: Remove Before Publication) 99 1. Add IANA considerations section requesting a TCP port number. 101 2. Split references into normative/informative. 103 3. Changes Since -00 (RFC Editor: Remove Before Publication) 105 1. Added required-to-implement SASL mechanism: GSSAPI. 107 2. Slight wording change in Server Initial Response section. 109 3. Allow untagged BAD responses. 111 4. How to Read This Document 113 The key words "MUST, "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 114 "RECOMMENDED", and "MAY" in this document are to be interpreted as 115 defined in "Key words for use in RFCs to Indicate Requirement Lev- 116 els" [KEYWORDS] 118 In examples, "C:" and "S:" indicate lines sent by the client and 119 server respectively. 121 5. Introduction 123 In order to support an architecture where there are multiple [IMAP] 124 servers sharing a common mailbox database, it is necessary to be 125 able to provide atomic mailbox operations, as well as offer suffi- 126 cient guarantees about database consistency. 128 The primary goal of the MUPDATE protocol is to be simple to imple- 129 ment yet allow for database consistency between participants. 131 6. Protocol Overview 133 The MUPDATE protocol assumes a reliable data stream such as a TCP 134 network connection. This document requests that the IANA register a 135 TCP port number with the short name of "mupdate" for this purpose. 136 Current implementations are using port 2004. 138 In the current implementation of the MUPDATE protocol there are 139 three types of participants: a single master server, slave (or 140 replica) servers, and clients. The master server maintains an 142 The MUPDATE Protocol April, 2003 144 authoritative copy of the mailbox database. Slave servers connect 145 to the MUPDATE master server as clients, and function as replicas 146 from the point of view of end clients. End clients may connect to 147 either the master or any slave and perform searches against the 148 database, however operations that change the database can only be 149 performed against the master. For the purposes of protocol discus- 150 sion we will consider a slave's connection to the master identical 151 to that of any other client. 153 After connection, all commands from a client to server must have an 154 associated unique tag which is an alphanumeric string. 156 MUPDATE uses data formats similar to those used in [ACAP]. That is, 157 atoms and strings. All commands and tags in the protocol are trans- 158 mitted as atoms. All other data is considered to a string, and must 159 be quoted or transmitted as a literal. 161 6.1. Atoms 163 An atom consists of one or more alphanumeric characters. 165 6.2. Strings 167 As in [ACAP], a string may be either literal or a quoted string. 169 A literal is a sequence of zero or more octets (including CR and 170 LF), prefix-quoted with an octet count in the form of an open brace 171 ("{"), the number of octets, an optional plus sign to indicate that 172 the data follows immediately (a non-synchronized literal), a close 173 brace ("}"), and a CRLF sequence. If the plus sign is omitted (a 174 synchronized literal), then the receiving side MUST send a "+ go 175 ahead" response, and the sending side MUST wait for this response. 177 Strings that are sent from server to client SHOULD NOT be in the 178 synchronized literal format. 180 A quoted string is a sequence of zero or more 7-bit characters, 181 excluding CR, LF, and the double quote (<">), with double quote 182 characters at each end. 184 The empty string is represented as either "" (a quoted string with 185 zero characters between double quotes) or as {0} followed by CRLF (a 186 literal with an octet count of 0). 188 7. Server Responses 190 Every client command in the MUPDATE protocol may receive one or more 191 tagged responses from the server. Each response is preceeded by the 193 The MUPDATE Protocol April, 2003 195 same tag as the command that elicited the response from the server. 197 7.1. Response: OK 199 A tagged OK response indicates that the operation completed success- 200 fully. There is a mandatory implementation-defined string after the 201 OK response. This response also indicates the beginning of the 202 streaming update mode when given in response to an UPDATE command. 204 Example: 206 C: N01 NOOP 207 S: N01 OK "NOOP Complete" 209 7.2. Response: NO 211 A tagged NO response indicates that the operation was explicitly 212 denied by the server or otherwise failed. There is a mandatory 213 implementation-defined string after the NO response that SHOULD 214 explain the reason for denial. 216 Example: 218 C: A01 AUTHENTICATE "PLAIN" 219 S: A01 NO "PLAIN is not a supported SASL mechanism" 221 7.3. Response: BAD 223 A tagged BAD response indicates that the command from the client 224 could not be parsed or understood. There is a mandatory implementa- 225 tion-defined string after the BAD response to provide additional 226 information about the error. Note that untagged BAD responses are 227 allowed if it is unclear what the tag for a given command is (for 228 example, if a blank line is received by the mupdate server, it can 229 generate an untagged BAD response). In the case of an untagged 230 response, the tag should be replaced with a "*". 232 Example: 234 C: C01 SELECT "INBOX" 235 S: C01 BAD "This is not an IMAP server" 236 C: 237 S: * BAD "Need Command" 239 The MUPDATE Protocol April, 2003 241 7.4. Response: BYE 243 A tagged BYE response indicates that the server has decided to close 244 the connection. There is a mandatory implementation-defined string 245 after the bad response that SHOULD explain the reason for closing 246 the connection. The server MUST close the connection immediately 247 after transmitting the BYE response. 249 Example: 251 C: L01 LOGOUT 252 S: L01 BYE "User Logged Out" 254 7.5. Response: RESERVE 256 A tagged RESERVE response may only be given in response to a FIND, 257 LIST, or UPDATE command. It includes two parameters: the name of 258 the mailbox that is being reserved (in mUTF-7 encoding, as specified 259 in [IMAP]) and a location string whose contents is defined by the 260 clients that are using the database, though it is RECOMMENDED that 261 the format of this string be the hostname of the server which is 262 storing the mailbox. 264 This response indicates that the given name is no longer available 265 in the namespace, though it does not indicate that the given mailbox 266 is available to clients at the current time. 268 Example: 270 S: U01 RESERVE "internet.bugtraq" "mail2.andrew.cmu.edu" 272 7.6. Response: MAILBOX 274 A tagged MAILBOX response may only be given in response to a FIND, 275 LIST, or UPDATE command. It includes three parameters: the name of 276 the mailbox that is currently reserved, a location string (as with 277 RESERVE), and a client-defined string that specifies the IMAP ACL 278 [IMAP-ACL]of the mailbox. This message indicates that the given 279 mailbox is ready to be accessed by clients. 281 Example: 283 S: U01 MAILBOX "internet.bugtraq" "mail2.andrew.cmu.edu" "anyone rls" 285 The MUPDATE Protocol April, 2003 287 7.7. Response: DELETE 289 A tagged DELETE response may only be given in response to an UPDATE 290 command, and MUST NOT be given before the OK response to the UPDATE 291 command is given. It contains a single parameter, that of the mail- 292 box that should be deleted from the slave's database. This response 293 indicates that the given mailbox no longer exists in the namespace 294 of the database, and may be given for any mailbox name, active, 295 reserved, or nonexistent. (Though implementations SHOULD NOT issue 296 DELETE responses for nonexistent mailboxes). 298 Example: 300 S: U01 DELETE "user.rjs3.sent-mail-jan-2002" 302 7.8. Server Capability Response 304 Upon connection of the client to the server, and directly following 305 a successful STARTTLS command, the server MUST issue a capabilities 306 banner, of the following format: 308 The banner MUST contain a line that begins with "* AUTH" and contain 309 a space-separated list of SASL mechanisms that the server will 310 accept for authentication. The mechanism names are transmitted as 311 atoms. Servers MAY advertise no available mechanisms (to indicate 312 that STARTTLS must be completed before authentication may occur). 313 If STARTTLS is not supported by the server, then the line MUST con- 314 tain at least one mechanism. 316 If the banner is being issued without a TLS layer, and the server 317 supports the STARTTLS command, the banner MUST contain the line "* 318 STARTTLS". If the banner is being issued under a TLS layer (or the 319 server does not support STARTTLS), the banner MUST NOT contain this 320 line. 322 The last line of the banner MUST start with "* OK MUPDATE" and be 323 followed by four strings: the server's hostname, an implementation- 324 defined string giving the name of the implementation, an implementa- 325 tion-defined string giving the version of the implementation, and a 326 string that indicates if the server is a master or a slave. The 327 master/slave indication MUST be either "(master)" or an MUPDATE URL 328 that defines where the master can be contacted. 330 Any unrecognized responses before the "* OK MUPDATE" response MUST 331 be ignored by the client. 333 The MUPDATE Protocol April, 2003 335 Example: 337 S: * AUTH KERBEROS_V4 GSSAPI 338 S: * STARTTLS 339 S: * OK MUPDATE "mupdate.andrew.cmu.edu" "Cyrus" "v2.1.2" "(master)" 341 8. Client Commands 343 The following are valid commands that a client may send to the MUP- 344 DATE server: AUTHENTICATE, ACTIVATE, DEACTIVATE, DELETE, FIND, LIST, 345 LOGOUT, NOOP, RESERVE, STARTTLS, and UPDATE. 347 Before a successful AUTHENTICATE command has occurred, the server 348 MUST NOT accept any commands except for AUTHENTICATE, STARTTLS, and 349 LOGOUT (and SHOULD reply with a NO response for all other commands). 351 8.1. Command: ACTIVATE 353 The ACTIVATE command has 3 parameters: the mailbox name, its loca- 354 tion, and its ACL. This command MUST NOT not be issued to a slave 355 server. 357 This command can also be used to update the ACL or location informa- 358 tion of a mailbox. Note that it is not a requirement for a mailbox 359 to be reserved (or even exist in the database) for an ACTIVATE com- 360 mand to succeed, implementations MUST allow this behavior as it 361 facilitates synchronization of the database with the current state 362 of the mailboxes. 364 8.2. Command: AUTHENTICATE 366 The AUTHENTICATE command initiates a [SASL] negotiation session 367 between the client and the server. It has two parameters. The 368 first parameter is mandatory, and is a string indicating the desired 369 [SASL] mechanism. The second is a string containing an optional 370 BASE64 encoded (as defined in section 6.8 of [MIME]) client first 371 send. 373 All of the remaining SASL blobs that are sent MUST be sent across 374 the wire must be in BASE64 encoded format, and followed by a CR and 375 LF combination. They MUST NOT be encoded as strings. 377 Clients may cancel authentication by sending a * followed by a CR 378 and LF. 380 The [SASL] service name for the MUPDATE protocol is "mupdate". 381 Implementations are REQUIRED to implement the GSSAPI [SASL] 383 The MUPDATE Protocol April, 2003 385 mechanism, though they SHOULD implement as many mechanisms as possi- 386 ble. 388 If a security layer is negotiated, it should be used directly fol- 389 lowing the CR and LF combination at the end of the server's OK 390 response. (i.e. beginning with the client's next command) 392 Only one successful AUTHENTICATE command may be issued per session. 394 8.3. Command: DEACTIVATE 396 The DEACTIVATE command takes two parameters, the mailbox name and 397 location data. The mailbox MUST already exist and be activated on 398 the MUPDATE server. If the server responds OK, then the mailbox 399 name has been moved to the RESERVE state. If the server responds 400 NO, then the mailbox name has not been moved (for example, the mail- 401 box was not already active). Any ACL information that is known 402 about the mailbox MAY be lost when a DEACTIVATE succeeds. This com- 403 mand MUST NOT be issued to a slave. 405 The typical sequence for mailbox creation is: 407 C: R01 ACTIVATE "user.rjs3.new" "mail3.andrew.cmu.edu!u4" 408 S: R01 OK "Mailbox Reserved." 409 C: A01 DEACTIVATE "user.rjs3.new" "mail3.andrew.cmu.edu!u4" 410 S: A01 OK "Mailbox Reserved." 412 8.4. Command: DELETE 414 The DELETE command takes only a single parameter, the mailbox name 415 to be removed from the database's namespace. The server SHOULD give 416 a NO response if the mailbox does not exist. This command MUST NOT 417 be issued to a slave server. 419 8.5. Command: FIND 421 The FIND command takes a single parameter, a mailbox name. The 422 server then responds with the current record for the given mailbox, 423 if any, and an OK response. 425 Example (mailbox does not exist): 427 C: F01 FIND "user.rjs3.xyzzy" 428 S: F01 OK "Search Complete" 430 The MUPDATE Protocol April, 2003 432 Example (mailbox is reserved): 434 C: F01 FIND "user.rjs3" 435 S: F01 RESERVE "user.rjs3" "mail4.andrew.cmu.edu" 436 S: F01 OK "Search Complete" 438 8.6. Command: LIST 440 The LIST command is similar to running FIND across the entire 441 database. The LIST command takes a single optional parameter, which 442 is a prefix to try to match against the location field of the 443 records. Without the parameter, LIST returns every record in the 444 database. 446 For each mailbox that matches, either a MAILBOX or a RESERVE 447 response (as applicable) is sent to the client. When all responses 448 are complete, an OK response is issued. 450 Example: 452 C: L01 LIST 453 S: L01 RESERVE "user.rjs3" "mail4.andrew.cmu.edu!u2" 454 S: L01 MAILBOX "user.leg" "mail2.andrew.cmu.edu!u1" "leg lrswipcda" 455 S: L01 OK "List Complete" 456 C: L02 LIST "mail4.andrew.cmu.edu!" 457 S: L02 RESERVE "user.rjs3" "mail4.andrew.cmu.edu!u2" 458 S: L02 OK "List Complete" 460 8.7. Command: LOGOUT 462 The LOGOUT command tells the server to close the connection. Its 463 only valid response is the BYE response. The LOGOUT command takes 464 no parameters. 466 8.8. Command: NOOP 468 The NOOP command takes no parameters. Provided the client is 469 authenticated, its only acceptable response is an OK. Any idle 470 timeouts that the server may have on the connection SHOULD be reset 471 upon receipt of this command. 473 If this command is issued after an UPDATE command has been issued, 474 then the OK response also indicates that all pending database 475 updates have been sent to the client. That is, the slave can guar- 476 antee that its local database is up to date as of a certain time by 477 issuing a NOOP and waiting for the OK. The OK MUST NOT return until 479 The MUPDATE Protocol April, 2003 481 all updates that were pending at the time of the NOOP have been 482 sent. 484 8.9. Command: RESERVE 486 The RESERVE command takes two parameters (just like the RESERVE 487 response), the mailbox name to reserve and location data. If the 488 server responds OK, then the mailbox name has been reserved. If the 489 server responds NO, then the mailbox name has not been reserved (for 490 example, another server has reserved it already). This command MUST 491 NOT be issued to a slave. 493 The typical sequence for mailbox creation is: 495 C: R01 RESERVE "user.rjs3.new" "mail3.andrew.cmu.edu!u4" 496 S: R01 OK "Mailbox Reserved." 497 498 C: A01 ACTIVATE "user.rjs3.new" "mail3.andrew.cmu.edu!u4" "rjs3 lrswipcda" 499 S: A01 OK "Mailbox Activated." 501 8.10. Command: STARTTLS 503 The STARTTLS command requests the commencement of a [TLS] negotia- 504 tion. The negotiation begins immediately after the CRLF in the OK 505 response. After a client issues a STARTTLS command, it MUST NOT 506 issue further commands until a server response is seen and the [TLS] 507 negotiation is complete. 509 The STARTTLS command is only valid in non-authenticated state. The 510 server remains in non-authenticated state, even if client creden- 511 tials are supplied during the [TLS] negotiation. The [SASL] EXTERNAL 512 mechanism MAY be used to authenticate once [TLS] client credentials 513 are successfully exchanged. Note that servers are not required to 514 support the EXTERNAL mechanism. 516 After the [TLS] layer is established, the server MUST re-issue the 517 initial response banner (see Section 7.8). This is necessary to pro- 518 tect against man-in-the-middle attacks which alter the capabilities 519 list prior to STARTTLS, as well as to advertise any new SASL mecha- 520 nisms (or other capabilities) that may be available under the layer. 521 The client MUST discard cached capability information and replace it 522 with the new information. 524 After the a successful STARTTLS command, the server SHOULD return a 525 NO response to additional STARTTLS commands. 527 Servers MAY choose to not implement STARTTLS. In this case, they 529 The MUPDATE Protocol April, 2003 531 MUST NOT advertise STARTTLS in their capabilities banner, and SHOULD 532 return a BAD response to the STARTTLS command, if it is issued. 534 Example: 536 C: S01 STARTTLS 537 S: S01 OK "Begin TLS negotiation now" 538 539 S: * AUTH KERBEROS_V4 GSSAPI PLAIN 540 S: * OK MUPDATE "mupdate.andrew.cmu.edu" "Cyrus" "v2.1.2" "(master)" 542 8.11. Command: UPDATE 544 The UPDATE command is how a slave initializes an update stream from 545 the master (though it is also valid to issue this command to a 546 slave). In response to the command, the server returns a list of 547 all mailboxes in its database (the same results as a parameterless 548 LIST command) followed by an OK response. From this point forward, 549 whenever an update occurs to the master database, it will immedi- 550 ately stream the update to the slave. That is, it will send 551 RESERVE, MAILBOX, or DELETE responses as they are applicable. 553 After a client has issued an UPDATE command, it may only issue NOOP 554 and LOGOUT commands for the remainder of the session. 556 Example: 558 C: U01 UPDATE 559 S: U01 MAILBOX "user.leg" "mail2.andrew.cmu.edu!u1" "leg lrswipcda" 560 S: U01 MAILBOX "user.rjs3" "mail3.andrew.cmu.edu!u4" "rjs3 lrswipcda" 561 S: U01 RESERVE "internet.bugtraq" "mail1.andrew.cmu.edu!u5" "anyone lrs" 562 S: U01 OK "Streaming Begins" 563 564 S: U01 RESERVE "user.leg.new" "mail2.andrew.cmu.edu!u1" 565 566 S: U01 MAILBOX "user.leg.new" "mail2.andrew.cmu.edu!u1" "leg lrswipcda" 567 569 C: N01 NOOP 570 S: U01 DELETE "user.leg.new" 571 S: N01 OK "NOOP Complete" 573 9. MUPDATE Formal Syntax 575 The following syntax specification uses the Augmented Backus-Naur 576 Form (ABNF) notation as specified in [ABNF]. This uses the ABNF core 578 The MUPDATE Protocol April, 2003 580 rules as specified in Appendix A of [ABNF]. 582 Except as noted otherwise, all alphabetic characters are case- 583 insensitive. The use of upper or lower case characters to define 584 token strings is for editorial clarity only. Implementations MUST 585 accept these strings in a case-insensitive fashion. 587 Note that this specification also uses some terminals from section 8 588 of [ACAP]. 590 cmd-activate = "ACTIVATE" SP string SP string SP string 592 cmd-authenticate = "AUTHENTICATE" SP sasl-mech [ SP string ] 594 cmd-delete = "DELETE" SP string 596 cmd-find = "FIND" SP string 598 cmd-list = "LIST" [ SP string ] 600 cmd-logout = "LOGOUT" 602 cmd-noop = "NOOP" 604 cmd-reserve = "RESERVE" SP string SP string 606 cmd-starttls = "STARTTLS" 608 cmd-update = "UPDATE" 610 command = tag SP command-type CRLF 612 command-type = cmd-activate / cmd-authenticate / cmd-delete / 613 cmd-find / cmd-list / cmd-logout / cmd-noop / 614 cmd-reserve / cmd-starttls / cmd-update 616 response = tag SP response-type CRLF 618 response-type = rsp-ok / rsp-no / rsp-bad / rsp-bye / rsp-mailbox / 619 rsp-reserve / rsp-delete 621 rsp-bad = "BAD" SP string 623 rep-bye = "BYE" SP string 625 rsp-mailbox = "MAILBOX" SP string SP string SP string 627 rsp-no = "NO" SP string 629 The MUPDATE Protocol April, 2003 631 rsp-ok = "OK" SP string 633 rsp-reserve = "RESERVE" SP string SP string 635 rsp-delete = "DELETE" SP string 637 sasl-mech = 1*ATOM-CHAR 638 ; ATOM-CHAR is defined in [ACAP] 640 string = quoted / literal 641 ; quoted and literal are defined in [ACAP] 643 tag = 1*ATOM-CHAR 644 ; ATOM-CHAR is defined in [ACAP] 646 10. MUPDATE URL Scheme 648 The MUPDATE URL Scheme is similar to the IMAP URL Scheme [IMAP-URL]. 649 It takes one of two possible forms: 651 mupdate:/// 652 mupdate:/// 654 The first form indicates just the MUPDATE server, the second form 655 indicates both the server and a mailbox to run a FIND against once 656 authenticated to the server. Note that part of may 657 include username and authentication information along with a host- 658 name and port. 660 10.1. Formal Syntax of the MUPDATE URL scheme 662 This defines the MUPDATE URL scheme using ABNF as defined in 663 [ABNF]. Terminals from the BNF of IMAP URLs [IMAP-URL] are also 664 used. 666 mupdateurl = "mupdate://" iserver "/" [ enc_mailbox ] 667 ; iserver and enc_mailbox are as defined in [IMAP-URL] 669 11. Security Considerations 671 While no unauthenticated users may make modifications or even per- 672 form searches on the database, it is important to note that this 673 specification assumes no protections of any type for authenticated 674 users. 676 All authenticated users have complete access to the database. For 678 The MUPDATE Protocol April, 2003 680 this reason it is important to ensure that accounts that are making 681 use of the database are well secured. 683 A more secure deployment might have all read only access go through 684 a slave, and only have accounts which need write access use the mas- 685 ter. This has the disadvantage of a marginally longer time for 686 updates to reach the clients. 688 The protocol assumes that all authenticated users are cooperating to 689 maintain atomic operations. Therefore, all new mailboxes SHOULD be 690 RESERVEd before they are ACTIVATEd, despite the fact that the proto- 691 col does not require this, and it is therefore possible for a set of 692 participants which do not obey the provided locking to create an 693 inconsistent database. RESERVEing the mailbox first is not required 694 to perform an activate because this behavior simplifies synchroniza- 695 tion with the actual location of the mailboxes. 697 12. IANA Considerations 699 This document requests that the IANA provide a TCP port number with 700 the short name of "mupdate". 702 13. Copyright 704 Copyright (C) The Internet Society (2002). All Rights Reserved. 706 This document and translations of it may be copied and furnished to 707 others, and derivative works that comment on or otherwise explain it 708 or assist in its implementation may be prepared, copied, published 709 and distributed, in whole or in part, without restriction of any 710 kind, provided that the above copyright notice and this paragraph 711 are included on all such copies and derivative works. However, this 712 document itself may not be modified in any way, such as by removing 713 the copyright notice or references to the Internet Society or other 714 Internet organizations, except as needed for the purpose of devel- 715 oping Internet standards in which case the procedures for copyrights 716 defined in the Internet Standards process must be followed, or as 717 required to translate it into languages other than English. 719 This document and the information contained herein is provided on an 720 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 721 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 722 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 723 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 724 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 726 The MUPDATE Protocol April, 2003 728 14. References 730 The following documents contain definitions or specifications that are 731 necessary for correct understanding of this protocol: 733 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Require- 734 ment Levels", BCP 14, RFC 2119, March 1997 736 [IMAP] Crispin, M., "Internet Message Access Protocol", RFC 2060, 737 December 1996. 739 [ABNF] Crocker, D., "Augmented BNF for Syntax Specifications: 740 ABNF", RFC 2234, November, 1997. 742 [MIME] Freed, N. & Bornstein, N., "Multipurpose Internet Mail 743 Extentions (MIME) Part One: Format of Internet Message Bod- 744 ies", RFC 2045, November 1996. 746 [IMAP-ACL] Myers, J., "IMAP4 ACL extention", RFC 2086, January 1997. 748 [SASL] Myers, J., "Simple Authentication and Security Layer 749 (SASL)", RFC 2222, October 1997. 751 [IMAP-URL] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997. 753 [ACAP] Newman, C. & Myers, J., "ACAP -- Application Configuration 754 Access Protocol", RFC 2244, November 1997. 756 [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 757 2246, January 1999. 759 The following document discusses the related POP3 protocol: 761 [POP3] Myers, J. & Rose, M., "Post Office Protocol - Version 3", 762 STD 53, RFC 1939, May 1996. 764 15. Author's Address: 766 Robert Siemborski 767 Carnegie Mellon, Andrew Systems Group 768 Cyert Hall 207 769 5000 Forbes Avenue 770 Pittsburgh, PA 15213 771 +1 412 268 7456 772 rjs3+@andrew.cmu.edu 774 The MUPDATE Protocol April, 2003 776 16. Acknowledgments: 778 Lawrence Greenfield of Carnegie Mellon, for a great deal of input 779 into the first draft of the protocol.