idnits 2.17.1 draft-siemborski-mupdate-02.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 15 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 16 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 9 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 437 has weird spacing: '...1" "leg lrswi...' == Line 654 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 686, but no explicit reference was found in the text == Unused Reference: 'POP3' is defined on line 698, 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) Summary: 11 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 December, 2002 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 December, 2002 50 Table of Contents 52 1. Changes Since -01 . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Changes Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. How to Read This Document . . . . . . . . . . . . . . . . . . . . 3 55 4. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 57 5.1. Atoms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 5.2. Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 6. Server Responses . . . . . . . . . . . . . . . . . . . . . . . . 4 60 6.1. Response: OK . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 6.2. Response: NO . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 6.3. Response: BAD . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 6.4. Response: BYES . . . . . . . . . . . . . . . . . . . . . . . . 5 64 6.5. Response: RESERVE . . . . . . . . . . . . . . . . . . . . . . . 6 65 6.6. Response: MAILBOX . . . . . . . . . . . . . . . . . . . . . . . 6 66 6.7. Response: DELETE . . . . . . . . . . . . . . . . . . . . . . . 6 67 6.8. Server Initial Response . . . . . . . . . . . . . . . . . . . . 7 68 7. Client Commands . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 7.1. Command: ACTIVATE . . . . . . . . . . . . . . . . . . . . . . . 8 70 7.2. Command: AUTHENTICATE . . . . . . . . . . . . . . . . . . . . . 8 71 7.3. Command: DEACTIVATE . . . . . . . . . . . . . . . . . . . . . . 9 72 7.4. Command: DELETE . . . . . . . . . . . . . . . . . . . . . . . . 9 73 7.5. Command: FIND . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 7.6. Command: LIST . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 7.7. Command: LOGOUT . . . . . . . . . . . . . . . . . . . . . . . . 10 76 7.8. Command: NOOP . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 7.9. Command: RESERVE . . . . . . . . . . . . . . . . . . . . . . . 10 78 7.10. Command: UPDATE . . . . . . . . . . . . . . . . . . . . . . . 11 79 8. MUPDATE Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 11 80 9. MUPDATE URL Scheme . . . . . . . . . . . . . . . . . . . . . . . 14 81 9.1. Formal Syntax for the MUPDATE URL scheme . . . . . . . . . . . 14 82 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 14 83 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 15 84 12. Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 14. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 87 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 16 89 The MUPDATE Protocol December, 2002 91 1. Changes Since -01 93 1. Add IANA considerations section requesting a TCP port number. 95 2. Split references into normative/informative. 97 2. Changes Since -00 99 1. Added required-to-implement SASL mechanism: GSSAPI. 101 2. Slight wording change in Server Initial Response section. 103 3. Allow untagged BAD responses. 105 3. How to Read This Document 107 The key words "MUST, "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 108 "RECOMMENDED", and "MAY" in this document are to be interpreted as 109 defined in "Key words for use in RFCs to Indicate Requirement Lev- 110 els" [KEYWORDS] 112 In examples, "C:" and "S:" indicate lines sent by the client and 113 server respectively. 115 4. Introduction 117 In order to support an architecture where there are multiple [IMAP] 118 servers sharing a common mailbox database, it is necessary to be 119 able to provide atomic mailbox operations, as well as offer suffi- 120 cient guarantees about database consistency. 122 The primary goal of the MUPDATE protocol is to be simple to imple- 123 ment yet allow for database consistency between participants. 125 5. Protocol Overview 127 The MUPDATE protocol assumes a reliable data stream such as a TCP 128 network connection. This document requests that the IANA register a 129 TCP port number with the short name of "mupdate" for this purpose. 130 Current implementations are using port 2004. 132 In the current implementation of the MUPDATE protocol there are 133 three types of participants: a single master server, slave (or 134 replica) servers, and clients. The master server maintains an 135 authoritative copy of the mailbox database. Slave servers connect 136 to the MUPDATE master server as clients, and function as replicas 137 from the point of view of end clients. End clients may connect to 138 either the master or any slave and perform searches against the 140 The MUPDATE Protocol December, 2002 142 database, however operations that change the database can only be 143 performed against the master. For the purposes of protocol discus- 144 sion we will consider a slave's connection to the master identical 145 to that of any other client. 147 After connection, all commands from a client to server must have an 148 associated unique tag which is an alphanumeric string. 150 MUPDATE uses data formats similar to those used in [ACAP]. That is, 151 atoms and strings. All commands and tags in the protocol are trans- 152 mitted as atoms. All other data is considered to a string, and must 153 be quoted or transmitted as a literal. 155 5.1. Atoms 157 An atom consists of one or more alphanumeric characters. 159 5.2. Strings 161 As in [ACAP], a string may be either literal or a quoted string. 163 A literal is a sequence of zero or more octets (including CR and 164 LF), prefix-quoted with an octet count in the form of an open brace 165 ("{"), the number of octets, an optional plus sign to indicate that 166 the data follows immediately (a non-synchronized literal), a close 167 brace ("}"), and a CRLF sequence. If the plus sign is omitted (a 168 synchronized literal), then the receiving side MUST send a "+ go 169 ahead" response, and the sending side MUST wait for this response. 171 Strings that are sent from server to client SHOULD NOT be in the 172 synchronized literal format. 174 A quoted string is a sequence of zero or more 7-bit characters, 175 excluding CR, LF, and the double quote (<">), with double quote 176 characters at each end. 178 The empty string is represented as either "" (a quoted string with 179 zero characters between double quotes) or as {0} followed by CRLF (a 180 literal with an octet count of 0). 182 6. Server Responses 184 Every client command in the MUPDATE protocol may receive one or more 185 tagged responses from the server. Each response is preceeded by the 186 same tag as the command that elicited the response from the server. 188 The MUPDATE Protocol December, 2002 190 6.1. Response: OK 192 A tagged OK response indicates that the operation completed success- 193 fully. There is a mandatory implementation-defined string after the 194 OK response. This response also indicates the beginning of the 195 streaming update mode when given in response to an UPDATE command. 197 Example: 199 C: N01 NOOP 200 S: N01 OK "NOOP Complete" 202 6.2. Response: NO 204 A tagged NO response indicates that the operation was explicitly 205 denied by the server or otherwise failed. There is a mandatory 206 implementation-defined string after the NO response that SHOULD 207 explain the reason for denial. 209 Example: 211 C: A01 AUTHENTICATE "PLAIN" 212 S: A01 NO "PLAIN is not a supported SASL mechanism" 214 6.3. Response: BAD 216 A tagged BAD response indicates that the command from the client 217 could not be parsed or understood. There is a mandatory implementa- 218 tion-defined string after the BAD response to provide additional 219 information about the error. Note that untagged BAD responses are 220 allowed if it is unclear what the tag for a given command is (for 221 example, if a blank line is received by the mupdate server, it can 222 generate an untagged BAD response). In the case of an untagged 223 response, the tag should be replaced with a "*". 225 Example: 227 C: C01 SELECT "INBOX" 228 S: C01 BAD "This is not an IMAP server" 229 C: 230 S: * BAD "Need Command" 232 The MUPDATE Protocol December, 2002 234 6.4. Response: BYE 236 A tagged BYE response indicates that the server has decided to close 237 the connection. There is a mandatory implementation-defined string 238 after the bad response that SHOULD explain the reason for closing 239 the connection. The server MUST close the connection immediately 240 after transmitting the BYE response. 242 Example: 244 C: L01 LOGOUT 245 S: L01 BYE "User Logged Out" 247 6.5. Response: RESERVE 249 A tagged RESERVE response may only be given in response to a FIND, 250 LIST, or UPDATE command. It includes two parameters: the name of 251 the mailbox that is being reserved (in mUTF-7 encoding, as specified 252 in [IMAP]) and a location string whose contents is defined by the 253 clients that are using the database, though it is RECOMMENDED that 254 the format of this string be the hostname of the server which is 255 storing the mailbox. 257 This response indicates that the given name is no longer available 258 in the namespace, though it does not indicate that the given mailbox 259 is available to clients at the current time. 261 Example: 263 S: U01 RESERVE "internet.bugtraq" "mail2.andrew.cmu.edu" 265 6.6. Response: MAILBOX 267 A tagged MAILBOX response may only be given in response to a FIND, 268 LIST, or UPDATE command. It includes three parameters: the name of 269 the mailbox that is currently reserved, a location string (as with 270 RESERVE), and a client-defined string that specifies the IMAP ACL 271 [IMAP-ACL]of the mailbox. This message indicates that the given 272 mailbox is ready to be accessed by clients. 274 Example: 276 S: U01 MAILBOX "internet.bugtraq" "mail2.andrew.cmu.edu" "anyone rls" 278 The MUPDATE Protocol December, 2002 280 6.7. Response: DELETE 282 A tagged DELETE response may only be given in response to an UPDATE 283 command, and MUST NOT be given before the OK response to the UPDATE 284 command is given. It contains a single parameter, that of the mail- 285 box that should be deleted from the slave's database. This response 286 indicates that the given mailbox no longer exists in the namespace 287 of the database, and may be given for any mailbox name, active, 288 reserved, or nonexistent. (Though implementations SHOULD NOT issue 289 DELETE responses for nonexistant mailboxes). 291 Example: 293 S: U01 DELETE "user.rjs3.sent-mail-jan-2002" 295 6.8. Server Initial Response 297 Upon connection of the client to the server, the server MUST issue a 298 banner, of the following format: 300 The banner MUST contain a line that begins with "* AUTH" and contain 301 a space-separated list of SASL mechanisms that the server will 302 accept for authentication. The mechanism names are transmitted as 303 strings, and servers MUST advertise at least one available mecha- 304 nism. 306 The last line of the banner MUST start with "* OK MUPDATE" and be 307 followed by four strings: the server's hostname, an implementation- 308 defined string giving the name of the implementation, an implementa- 309 tion-defined string giving the version of the implementation, and a 310 string that indicates if the server is a master or a slave. The 311 master/slave indication MUST be either "(master)" or an MUPDATE URL 312 that defines where the master can be contacted. 314 Any unrecognized responses before the "* OK MUPDATE" response MUST 315 be ignored by the client. 317 Example: 319 S: * AUTH KERBEROS_V4 GSSAPI 320 S: * OK MUPDATE "mupdate.andrew.cmu.edu" "Cyrus" "v2.1.2" "(master)" 322 7. Client Commands 324 The following are valid commands that a client may send to the MUP- 325 DATE server: AUTHENTICATE, ACTIVATE, DEACTIVATE, DELETE, FIND, LIST, 327 The MUPDATE Protocol December, 2002 329 LOGOUT, NOOP, RESERVE, and UPDATE. 331 Before a successful AUTHENTICATE command has occurred, the server 332 MUST NOT accept any commands except for AUTHENTICATE and LOGOUT (and 333 SHOULD reply with a NO response for all other commands). 335 7.1. Command: ACTIVATE 337 The ACTIVATE command has 3 parameters: the mailbox name, its loca- 338 tion, and its ACL. This command MUST NOT not be issued to a slave 339 server. 341 This command can also be used to update the ACL or location informa- 342 tion of a mailbox. Note that it is not a requirement for a mailbox 343 to be reserved (or even exist in the database) for an ACTIVATE com- 344 mand to succeed, implementations MUST allow this behavior as it 345 facilitates synchronization of the database with the current state 346 of the mailboxes. 348 7.2. Command: AUTHENTICATE 350 The AUTHENTICATE command initiates a [SASL] negotiation session 351 between the client and the server. It has two parameters. The 352 first parameter is mandatory, and is a string indicating the desired 353 [SASL] mechanism. The second is a string containing an optional 354 BASE64 encoded (as defined in section 6.8 of [MIME]) client first 355 send. 357 All of the remaining SASL blobs that are sent MUST be sent across 358 the wire must be in BASE64 encoded format, and followed by a CR and 359 LF combination. They MUST NOT be encoded as strings. 361 Clients may cancel authentication by sending a * followed by a CR 362 and LF. 364 The [SASL] service name for the MUPDATE protocol is "mupdate". 365 Implementations are REQUIRED to implement the GSSAPI [SASL] mecha- 366 nism, though they SHOULD implement as many mechanisms as possible. 368 If a security layer is negotiated, it should be used directly fol- 369 lowing the CR and LF combination at the end of the server's OK 370 response. (i.e. beginning with the client's next command) 372 Only one successful AUTHENTICATE command may be issued per session. 374 The MUPDATE Protocol December, 2002 376 7.3. Command: DEACTIVATE 378 The DEACTIVATE command takes two parameters, the mailbox name and 379 location data. The mailbox MUST already exist and be activated on 380 the MUPDATE server. If the server responds OK, then the mailbox 381 name has been moved to the RESERVE state. If the server responds 382 NO, then the mailbox name has not been moved (for example, the mail- 383 box was not already active). Any ACL information that is known 384 about the mailbox MAY be lost when a DEACTIVATE succeeds. This com- 385 mand MUST NOT be issued to a slave. 387 The typical sequence for mailbox creation is: 389 C: R01 ACTIVATE "user.rjs3.new" "mail3.andrew.cmu.edu!u4" 390 S: R01 OK "Mailbox Reserved." 391 C: A01 DEACTIVATE "user.rjs3.new" "mail3.andrew.cmu.edu!u4" 392 S: A01 OK "Mailbox Reserved." 394 7.4. Command: DELETE 396 The DELETE command takes only a single parameter, the mailbox name 397 to be removed from the database's namespace. The server SHOULD give 398 a NO response if the mailbox does not exist. This command MUST NOT 399 be issued to a slave server. 401 7.5. Command: FIND 403 The FIND command takes a single parameter, a mailbox name. The 404 server then responds with the current record for the given mailbox, 405 if any, and an OK response. 407 Example (mailbox does not exist): 409 C: F01 FIND "user.rjs3.xyzzy" 410 S: F01 OK "Search Complete" 412 Example (mailbox is reserved): 414 C: F01 FIND "user.rjs3" 415 S: F01 RESERVE "user.rjs3" "mail4.andrew.cmu.edu" 416 S: F01 OK "Search Complete" 418 7.6. Command: LIST 420 The LIST command is similar to running FIND across the entire 421 database. The LIST command takes a single optional parameter, which 423 The MUPDATE Protocol December, 2002 425 is a prefix to try to match against the location field of the 426 records. Without the parameter, LIST returns every record in the 427 database. 429 For each mailbox that matches, either a MAILBOX or a RESERVE 430 response (as applicable) is sent to the client. When all responses 431 are complete, an OK response is issued. 433 Example: 435 C: L01 LIST 436 S: L01 RESERVE "user.rjs3" "mail4.andrew.cmu.edu!u2" 437 S: L01 MAILBOX "user.leg" "mail2.andrew.cmu.edu!u1" "leg lrswipcda" 438 S: L01 OK "List Complete" 439 C: L02 LIST "mail4.andrew.cmu.edu!" 440 S: L02 RESERVE "user.rjs3" "mail4.andrew.cmu.edu!u2" 441 S: L02 OK "List Complete" 443 7.7. Command: LOGOUT 445 The LOGOUT command tells the server to close the connection. Its 446 only valid response is the BYE response. The LOGOUT command takes 447 no parameters. 449 7.8. Command: NOOP 451 The NOOP command takes no parameters. Provided the client is 452 authenticated, its only acceptable response is an OK. Any idle 453 timeouts that the server may have on the connection SHOULD be reset 454 upon recipt of this command. 456 If this command is issued after an UPDATE command has been issued, 457 then the OK response also indicates that all pending database 458 updates have been sent to the client. That is, the slave can guar- 459 antee that its local database is up to date as of a certain time by 460 issuing a NOOP and waiting for the OK. The OK MUST NOT return until 461 all updates that were pending at the time of the NOOP have been 462 sent. 464 7.9. Command: RESERVE 466 The RESERVE command takes two parameters (just like the RESERVE 467 response), the mailbox name to reserve and location data. If the 468 server responds OK, then the mailbox name has been reserved. If the 469 server responds NO, then the mailbox name has not been reserved (for 470 example, another server has reserved it already). This command MUST 471 NOT be issued to a slave. 473 The MUPDATE Protocol December, 2002 475 The typical sequence for mailbox creation is: 477 C: R01 RESERVE "user.rjs3.new" "mail3.andrew.cmu.edu!u4" 478 S: R01 OK "Mailbox Reserved." 479 480 C: A01 ACTIVATE "user.rjs3.new" "mail3.andrew.cmu.edu!u4" "rjs3 lrswipcda" 481 S: A01 OK "Mailbox Activated." 483 7.10. Command: UPDATE 485 The UPDATE command is how a slave initializes an update stream from 486 the master (though it is also valid to issue this command to a 487 slave). In response to the command, the server returns a list of 488 all mailboxes in its database (the same results as a parameterless 489 LIST command) followed by an OK response. From this point forward, 490 whenever an update occurs to the master database, it will immedi- 491 ately stream the update to the slave. That is, it will send 492 RESERVE, MAILBOX, or DELETE responses as they are applicable. 494 After a client has issued an UPDATE command, it may only issue NOOP 495 and LOGOUT commands for the remainder of the session. 497 Example: 499 C: U01 UPDATE 500 S: U01 MAILBOX "user.leg" "mail2.andrew.cmu.edu!u1" "leg lrswipcda" 501 S: U01 MAILBOX "user.rjs3" "mail3.andrew.cmu.edu!u4" "rjs3 lrswipcda" 502 S: U01 RESERVE "internet.bugtraq" "mail1.andrew.cmu.edu!u5" "anyone lrs" 503 S: U01 OK "Streaming Begins" 504 505 S: U01 RESERVE "user.leg.new" "mail2.andrew.cmu.edu!u1" 506 507 S: U01 MAILBOX "user.leg.new" "mail2.andrew.cmu.edu!u1" "leg lrswipcda" 508 510 C: N01 NOOP 511 S: U01 DELETE "user.leg.new" 512 S: N01 OK "NOOP Complete" 514 8. MUPDATE Formal Syntax 516 The following syntax specification uses the Augmented Backus-Naur 517 Form (ABNF) notation as specified in [ABNF]. This uses the ABNF core 518 rules as specified in Appendix A of [ABNF]. 520 Except as noted otherwise, all alphabetic characters are case- 522 The MUPDATE Protocol December, 2002 524 insensitive. The use of upper or lower case characters to define 525 token strings is for editorial clarity only. Implementations MUST 526 accept these strings in a case-insensitive fashion. 528 Note that this specification also uses some terminals from section 8 529 of [ACAP]. 531 The MUPDATE Protocol December, 2002 533 cmd-activate = "ACTIVATE" SP string SP string SP string 535 cmd-authenticate = "AUTHENTICATE" SP sasl-mech [ SP string ] 537 cmd-delete = "DELETE" SP string 539 cmd-find = "FIND" SP string 541 cmd-list = "LIST" [ SP string ] 543 cmd-logout = "LOGOUT" 545 cmd-noop = "NOOP" 547 cmd-reserve = "RESERVE" SP string SP string 549 cmd-update = "UPDATE" 551 command = tag SP command-type CRLF 553 command-type = cmd-activate / cmd-authenticate / cmd-delete / 554 cmd-find / cmd-list / cmd-logout / cmd-noop / 555 cmd-reserve / cmd-update 557 response = tag SP response-type CRLF 559 response-type = rsp-ok / rsp-no / rsp-bad / rsp-bye / rsp-mailbox / 560 rsp-reserve / rsp-delete 562 rsp-bad = "BAD" SP string 564 rep-bye = "BYE" SP string 566 rsp-mailbox = "MAILBOX" SP string SP string SP string 568 rsp-no = "NO" SP string 570 rsp-ok = "OK" SP string 572 rsp-reserve = "RESERVE" SP string SP string 574 rsp-delete = "DELETE" SP string 576 sasl-mech = 1*ATOM-CHAR 577 ; ATOM-CHAR is defined in [ACAP] 579 The MUPDATE Protocol December, 2002 581 string = quoted / literal 582 ; quoted and literal are defined in [ACAP] 584 tag = 1*ATOM-CHAR 585 ; ATOM-CHAR is defined in [ACAP] 587 9. MUPDATE URL Scheme 589 The MUPDATE URL Scheme is similar to the IMAP URL Scheme [IMAP-URL]. 590 It takes one of two possible forms: 592 mupdate:/// 593 mupdate:/// 595 The first form indicates just the MUPDATE server, the second form 596 indicates both the server and a mailbox to run a FIND against once 597 authenticated to the server. Note that part of may 598 include username and authentication information along with a host- 599 name and port. 601 9.1. Formal Syntax of the MUPDATE URL scheme 603 This defines the MUPDATE URL scheme using ABNF as defined in 604 [ABNF]. Terminals from the BNF of IMAP URLs [IMAP-URL] are also 605 used. 607 mupdateurl = "mupdate://" iserver "/" [ enc_mailbox ] 608 ; iserver and enc_mailbox are as defined in [IMAP-URL] 610 10. Security Considerations 612 While no unauthenticated users may make modifications or even per- 613 form searches on the database, it is important to note that this 614 specification assumes no protections of any type for authenticated 615 users. 617 All authenticated users have complete access to the database. For 618 this reason it is important to ensure that accounts that are making 619 use of the database are well secured. 621 A more secure deployment might have all read only access go through 622 a slave, and only have accounts which need write access use the mas- 623 ter. This has the disadvantage of a marginally longer time for 624 updates to reach the clients. 626 The MUPDATE Protocol December, 2002 628 The protocol assumes that all authenticated users are cooperating to 629 maintain atomic operations. Therefore, all new mailboxes SHOULD be 630 RESERVEd before they are ACTIVATEd, despite the fact that the proto- 631 col does not require this, and it is therefore possible for a set of 632 participants which do not obey the provided locking to create an 633 inconsistent database. RESERVEing the mailbox first is not required 634 to perform an activate because this behavior simplifies synchroniza- 635 tion with the actual location of the mailboxes. 637 11. IANA Considerations 639 This document requests that the IANA provide a TCP port number with 640 the short name of "mupdate". 642 12. Copyright 644 Copyright (C) The Internet Society (2002). All Rights Reserved. 646 This document and translations of it may be copied and furnished to 647 others, and derivative works that comment on or otherwise explain it 648 or assist in its implementation may be prepared, copied, published 649 and distributed, in whole or in part, without restriction of any 650 kind, provided that the above copyright notice and this paragraph 651 are included on all such copies and derivative works. However, this 652 document itself may not be modified in any way, such as by removing 653 the copyright notice or references to the Internet Society or other 654 Internet organizations, except as needed for the purpose of devel- 655 oping Internet standards in which case the procedures for copyrights 656 defined in the Internet Standards process must be followed, or as 657 required to translate it into languages other than English. 659 This document and the information contained herein is provided on an 660 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 661 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 662 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 663 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 664 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 666 13. References 668 The following documents contain definitions or specifications that are 669 necessary for correct understanding of this protocol: 671 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Require- 672 ment Levels", BCP 14, RFC 2119, March 1997 674 The MUPDATE Protocol December, 2002 676 [IMAP] Crispin, M., "Internet Message Access Protocol", RFC 2060, 677 December 1996. 679 [ABNF] Crocker, D., "Augmented BNF for Syntax Specifications: 680 ABNF", RFC 2234, November, 1997. 682 [MIME] Freed, N. & Bornstein, N., "Multipurpose Internet Mail 683 Extentions (MIME) Part One: Format of Internet Message Bod- 684 ies", RFC 2045, November 1996. 686 [IMAP-ACL] Myers, J., "IMAP4 ACL extention", RFC 2086, January 1997. 688 [SASL] Myers, J., "Simple Authentication and Security Layer 689 (SASL)", RFC 2222, October 1997. 691 [IMAP-URL] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997. 693 [ACAP] Newman, C. & Myers, J., "ACAP -- Application Configuration 694 Access Protocol", RFC 2244, November 1997. 696 The following document discusses the related POP3 protocol: 698 [POP3] Myers, J. & Rose, M., "Post Office Protocol - Version 3", 699 STD 53, RFC 1939, May 1996. 701 14. Author's Address: 703 Robert Siemborski 704 Carnegie Mellon, Andrew Systems Group 705 Cyert Hall 207 706 5000 Forbes Avenue 707 Pittsburgh, PA 15213 708 +1 412 268 7456 709 rjs3+@andrew.cmu.edu 711 15. Acknowledgments: 713 Lawrence Greenfield of Carnegie Mellon, for a great deal of input 714 into the first draft of the protocol.