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