idnits 2.17.1 draft-siemborski-mupdate-04.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 19 longer pages, the longest (page 1) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 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 481 has weird spacing: '...1" "leg lrswi...' == Line 818 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 850, but no explicit reference was found in the text == Unused Reference: 'POP3' is defined on line 865, 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) ** Obsolete normative reference: RFC 2717 (Obsoleted by RFC 4395) Summary: 13 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 May, 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 May, 2003 50 Table of Contents 52 1. Changes Since -03 . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Changes Since -02 . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Changes Since -01 . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Changes Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 3 56 5. How to Read This Document . . . . . . . . . . . . . . . . . . . . 3 57 6. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 7. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 59 7.1. Atoms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 7.2. Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 8. Server Responses . . . . . . . . . . . . . . . . . . . . . . . . 5 62 8.1. Response: OK . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 8.2. Response: NO . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 8.3. Response: BAD . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 8.4. Response: BYES . . . . . . . . . . . . . . . . . . . . . . . . 6 66 8.5. Response: RESERVE . . . . . . . . . . . . . . . . . . . . . . . 6 67 8.6. Response: MAILBOX . . . . . . . . . . . . . . . . . . . . . . . 7 68 8.7. Response: DELETE . . . . . . . . . . . . . . . . . . . . . . . 7 69 8.8. Server Capability Response . . . . . . . . . . . . . . . . . . 8 70 9. Client Commands . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 9.1. Command: ACTIVATE . . . . . . . . . . . . . . . . . . . . . . . 9 72 9.2. Command: AUTHENTICATE . . . . . . . . . . . . . . . . . . . . . 9 73 9.3. Command: DEACTIVATE . . . . . . . . . . . . . . . . . . . . . . 10 74 9.4. Command: DELETE . . . . . . . . . . . . . . . . . . . . . . . . 10 75 9.5. Command: FIND . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 9.6. Command: LIST . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 9.7. Command: LOGOUT . . . . . . . . . . . . . . . . . . . . . . . . 11 78 9.8. Command: NOOP . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 9.9. Command: RESERVE . . . . . . . . . . . . . . . . . . . . . . . 12 80 9.10. Command: STARTTLS . . . . . . . . . . . . . . . . . . . . . . 12 81 9.11. Command: UPDATE . . . . . . . . . . . . . . . . . . . . . . . 13 82 10. MUPDATE Formal Syntax . . . . . . . . . . . . . . . . . . . . . 13 83 11. MUPDATE URL Scheme . . . . . . . . . . . . . . . . . . . . . . . 15 84 11.1. MUPDATE URL Scheme Registration Form . . . . . . . . . . . . . 15 85 12. Security Considerations . . . . . . . . . . . . . . . . . . . . 17 86 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 17 87 14. Intellectual Property Rights . . . . . . . . . . . . . . . . . . 17 88 15. Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 17. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 91 18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 20 93 The MUPDATE Protocol May, 2003 95 1. Changes Since -03 (RFC Editor: Remove Before Publication) 97 1. Correct registration of URL scheme to confirm with RFC2717. 99 2. Add maximums for line length, atom size, literal size, and 100 minimum time before an update is pushed to the client. 102 3. Add a minimum idle timeout. 104 4. Add IPR Boilerplate 106 2. Changes Since -02 (RFC Editor: Remove Before Publication) 108 1. Add STARTTLS Command 110 3. Changes Since -01 (RFC Editor: Remove Before Publication) 112 1. Add IANA considerations section requesting a TCP port number. 114 2. Split references into normative/informative. 116 4. Changes Since -00 (RFC Editor: Remove Before Publication) 118 1. Added required-to-implement SASL mechanism: GSSAPI. 120 2. Slight wording change in Server Initial Response section. 122 3. Allow untagged BAD responses. 124 5. How to Read This Document 126 The key words "MUST, "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 127 "RECOMMENDED", and "MAY" in this document are to be interpreted as 128 defined in "Key words for use in RFCs to Indicate Requirement Lev- 129 els" [KEYWORDS] 131 In examples, "C:" and "S:" indicate lines sent by the client and 132 server respectively. 134 6. Introduction 136 In order to support an architecture where there are multiple [IMAP] 137 servers sharing a common mailbox database, it is necessary to be 138 able to provide atomic mailbox operations, as well as offer suffi- 139 cient guarantees about database consistency. 141 The primary goal of the MUPDATE protocol is to be simple to imple- 142 ment yet allow for database consistency between participants. 144 The MUPDATE Protocol May, 2003 146 7. Protocol Overview 148 The MUPDATE protocol assumes a reliable data stream such as a TCP 149 network connection. This document requests that the IANA register a 150 TCP port number with the short name of "mupdate" for this purpose. 151 Current implementations are using port 2004. 153 In the current implementation of the MUPDATE protocol there are 154 three types of participants: a single master server, slave (or 155 replica) servers, and clients. The master server maintains an 156 authoritative copy of the mailbox database. Slave servers connect 157 to the MUPDATE master server as clients, and function as replicas 158 from the point of view of end clients. End clients may connect to 159 either the master or any slave and perform searches against the 160 database, however operations that change the database can only be 161 performed against the master. For the purposes of protocol discus- 162 sion we will consider a slave's connection to the master identical 163 to that of any other client. 165 After connection, all commands from a client to server must have an 166 associated unique tag which is an alphanumeric string. Commands MAY 167 be pipelined from the client to the server (that is, the client need 168 not wait for the response before sending the next command). The 169 server MUST execute the commands in the order they were received, 170 however. 172 If the server supports an inactivity login timeout, it MUST be 173 atleast 15 minutes. 175 MUPDATE uses data formats similar to those used in [ACAP]. That is, 176 atoms and strings. All commands and tags in the protocol are trans- 177 mitted as atoms. All other data is considered to a string, and must 178 be quoted or transmitted as a literal. 180 Outside of a literal, both clients and servers MUST support line 181 lengths of atleast 1024 octets (including the trailing CR and LF 182 characters). If a line of a longer length must be transmitted, 183 implementations MUST make use of literals to do so. 185 7.1. Atoms 187 An atom consists of one or more alphanumeric characters. Atoms MUST 188 be less than 15 octets in length. 190 7.2. Strings 192 As in [ACAP], a string may be either literal or a quoted string. 194 The MUPDATE Protocol May, 2003 196 A literal is a sequence of zero or more octets (including CR and 197 LF), prefix-quoted with an octet count in the form of an open brace 198 ("{"), the number of octets, an optional plus sign to indicate that 199 the data follows immediately (a non-synchronized literal), a close 200 brace ("}"), and a CRLF sequence. If the plus sign is omitted (a 201 synchronized literal), then the receiving side MUST send a "+ go 202 ahead" response, and the sending side MUST wait for this response. 203 Servers MUST support literals of atleast 4096 octets. 205 Strings that are sent from server to client SHOULD NOT be in the 206 synchronized literal format. 208 A quoted string is a sequence of zero or more 7-bit characters, 209 excluding CR, LF, and the double quote (<">), with double quote 210 characters at each end. 212 The empty string is represented as either "" (a quoted string with 213 zero characters between double quotes) or as {0} followed by CRLF (a 214 literal with an octet count of 0). 216 8. Server Responses 218 Every client command in the MUPDATE protocol may receive one or more 219 tagged responses from the server. Each response is preceeded by the 220 same tag as the command that elicited the response from the server. 222 8.1. Response: OK 224 A tagged OK response indicates that the operation completed success- 225 fully. There is a mandatory implementation-defined string after the 226 OK response. This response also indicates the beginning of the 227 streaming update mode when given in response to an UPDATE command. 229 Example: 231 C: N01 NOOP 232 S: N01 OK "NOOP Complete" 234 The MUPDATE Protocol May, 2003 236 8.2. Response: NO 238 A tagged NO response indicates that the operation was explicitly 239 denied by the server or otherwise failed. There is a mandatory 240 implementation-defined string after the NO response that SHOULD 241 explain the reason for denial. 243 Example: 245 C: A01 AUTHENTICATE "PLAIN" 246 S: A01 NO "PLAIN is not a supported SASL mechanism" 248 8.3. Response: BAD 250 A tagged BAD response indicates that the command from the client 251 could not be parsed or understood. There is a mandatory implementa- 252 tion-defined string after the BAD response to provide additional 253 information about the error. Note that untagged BAD responses are 254 allowed if it is unclear what the tag for a given command is (for 255 example, if a blank line is received by the mupdate server, it can 256 generate an untagged BAD response). In the case of an untagged 257 response, the tag should be replaced with a "*". 259 Example: 261 C: C01 SELECT "INBOX" 262 S: C01 BAD "This is not an IMAP server" 263 C: 264 S: * BAD "Need Command" 266 8.4. Response: BYE 268 A tagged BYE response indicates that the server has decided to close 269 the connection. There is a mandatory implementation-defined string 270 after the bad response that SHOULD explain the reason for closing 271 the connection. The server MUST close the connection immediately 272 after transmitting the BYE response. 274 Example: 276 C: L01 LOGOUT 277 S: L01 BYE "User Logged Out" 279 The MUPDATE Protocol May, 2003 281 8.5. Response: RESERVE 283 A tagged RESERVE response may only be given in response to a FIND, 284 LIST, or UPDATE command. It includes two parameters: the name of 285 the mailbox that is being reserved (in mUTF-7 encoding, as specified 286 in [IMAP]) and a location string whose contents is defined by the 287 clients that are using the database, though it is RECOMMENDED that 288 the format of this string be the hostname of the server which is 289 storing the mailbox. 291 This response indicates that the given name is no longer available 292 in the namespace, though it does not indicate that the given mailbox 293 is available to clients at the current time. 295 Example: 297 S: U01 RESERVE "internet.bugtraq" "mail2.andrew.cmu.edu" 299 8.6. Response: MAILBOX 301 A tagged MAILBOX response may only be given in response to a FIND, 302 LIST, or UPDATE command. It includes three parameters: the name of 303 the mailbox that is currently reserved, a location string (as with 304 RESERVE), and a client-defined string that specifies the IMAP ACL 305 [IMAP-ACL]of the mailbox. This message indicates that the given 306 mailbox is ready to be accessed by clients. 308 Example: 310 S: U01 MAILBOX "internet.bugtraq" "mail2.andrew.cmu.edu" "anyone rls" 312 The MUPDATE Protocol May, 2003 314 8.7. Response: DELETE 316 A tagged DELETE response may only be given in response to an UPDATE 317 command, and MUST NOT be given before the OK response to the UPDATE 318 command is given. It contains a single parameter, that of the mail- 319 box that should be deleted from the slave's database. This response 320 indicates that the given mailbox no longer exists in the namespace 321 of the database, and may be given for any mailbox name, active, 322 reserved, or nonexistent. (Though implementations SHOULD NOT issue 323 DELETE responses for nonexistent mailboxes). 325 Example: 327 S: U01 DELETE "user.rjs3.sent-mail-jan-2002" 329 8.8. Server Capability Response 331 Upon connection of the client to the server, and directly following 332 a successful STARTTLS command, the server MUST issue a capabilities 333 banner, of the following format: 335 The banner MUST contain a line that begins with "* AUTH" and contain 336 a space-separated list of SASL mechanisms that the server will 337 accept for authentication. The mechanism names are transmitted as 338 atoms. Servers MAY advertise no available mechanisms (to indicate 339 that STARTTLS must be completed before authentication may occur). 340 If STARTTLS is not supported by the server, then the line MUST con- 341 tain at least one mechanism. 343 If the banner is being issued without a TLS layer, and the server 344 supports the STARTTLS command, the banner MUST contain the line "* 345 STARTTLS". If the banner is being issued under a TLS layer (or the 346 server does not support STARTTLS), the banner MUST NOT contain this 347 line. 349 The last line of the banner MUST start with "* OK MUPDATE" and be 350 followed by four strings: the server's hostname, an implementation- 351 defined string giving the name of the implementation, an implementa- 352 tion-defined string giving the version of the implementation, and a 353 string that indicates if the server is a master or a slave. The 354 master/slave indication MUST be either "(master)" or an MUPDATE URL 355 that defines where the master can be contacted. 357 Any unrecognized responses before the "* OK MUPDATE" response MUST 358 be ignored by the client. 360 The MUPDATE Protocol May, 2003 362 Example: 364 S: * AUTH KERBEROS_V4 GSSAPI 365 S: * STARTTLS 366 S: * OK MUPDATE "mupdate.andrew.cmu.edu" "Cyrus" "v2.1.2" "(master)" 368 9. Client Commands 370 The following are valid commands that a client may send to the MUP- 371 DATE server: AUTHENTICATE, ACTIVATE, DEACTIVATE, DELETE, FIND, LIST, 372 LOGOUT, NOOP, RESERVE, STARTTLS, and UPDATE. 374 Before a successful AUTHENTICATE command has occurred, the server 375 MUST NOT accept any commands except for AUTHENTICATE, STARTTLS, and 376 LOGOUT (and SHOULD reply with a NO response for all other commands). 378 9.1. Command: ACTIVATE 380 The ACTIVATE command has 3 parameters: the mailbox name, its loca- 381 tion, and its ACL. This command MUST NOT not be issued to a slave 382 server. 384 This command can also be used to update the ACL or location informa- 385 tion of a mailbox. Note that it is not a requirement for a mailbox 386 to be reserved (or even exist in the database) for an ACTIVATE com- 387 mand to succeed, implementations MUST allow this behavior as it 388 facilitates synchronization of the database with the current state 389 of the mailboxes. 391 9.2. Command: AUTHENTICATE 393 The AUTHENTICATE command initiates a [SASL] negotiation session 394 between the client and the server. It has two parameters. The 395 first parameter is mandatory, and is a string indicating the desired 396 [SASL] mechanism. The second is a string containing an optional 397 BASE64 encoded (as defined in section 6.8 of [MIME]) client first 398 send. 400 All of the remaining SASL blobs that are sent MUST be sent across 401 the wire must be in BASE64 encoded format, and followed by a CR and 402 LF combination. They MUST NOT be encoded as strings. 404 Clients may cancel authentication by sending a * followed by a CR 405 and LF. 407 The [SASL] service name for the MUPDATE protocol is "mupdate". 408 Implementations are REQUIRED to implement the GSSAPI [SASL] 410 The MUPDATE Protocol May, 2003 412 mechanism, though they SHOULD implement as many mechanisms as possi- 413 ble. 415 If a security layer is negotiated, it should be used directly fol- 416 lowing the CR and LF combination at the end of the server's OK 417 response. (i.e. beginning with the client's next command) 419 Only one successful AUTHENTICATE command may be issued per session. 421 9.3. Command: DEACTIVATE 423 The DEACTIVATE command takes two parameters, the mailbox name and 424 location data. The mailbox MUST already exist and be activated on 425 the MUPDATE server. If the server responds OK, then the mailbox 426 name has been moved to the RESERVE state. If the server responds 427 NO, then the mailbox name has not been moved (for example, the mail- 428 box was not already active). Any ACL information that is known 429 about the mailbox MAY be lost when a DEACTIVATE succeeds. This com- 430 mand MUST NOT be issued to a slave. 432 The typical sequence for mailbox creation is: 434 C: R01 ACTIVATE "user.rjs3.new" "mail3.andrew.cmu.edu!u4" 435 S: R01 OK "Mailbox Reserved." 436 C: A01 DEACTIVATE "user.rjs3.new" "mail3.andrew.cmu.edu!u4" 437 S: A01 OK "Mailbox Reserved." 439 9.4. Command: DELETE 441 The DELETE command takes only a single parameter, the mailbox name 442 to be removed from the database's namespace. The server SHOULD give 443 a NO response if the mailbox does not exist. This command MUST NOT 444 be issued to a slave server. 446 9.5. Command: FIND 448 The FIND command takes a single parameter, a mailbox name. The 449 server then responds with the current record for the given mailbox, 450 if any, and an OK response. 452 Example (mailbox does not exist): 454 C: F01 FIND "user.rjs3.xyzzy" 455 S: F01 OK "Search Complete" 457 The MUPDATE Protocol May, 2003 459 Example (mailbox is reserved): 461 C: F01 FIND "user.rjs3" 462 S: F01 RESERVE "user.rjs3" "mail4.andrew.cmu.edu" 463 S: F01 OK "Search Complete" 465 9.6. Command: LIST 467 The LIST command is similar to running FIND across the entire 468 database. The LIST command takes a single optional parameter, which 469 is a prefix to try to match against the location field of the 470 records. Without the parameter, LIST returns every record in the 471 database. 473 For each mailbox that matches, either a MAILBOX or a RESERVE 474 response (as applicable) is sent to the client. When all responses 475 are complete, an OK response is issued. 477 Example: 479 C: L01 LIST 480 S: L01 RESERVE "user.rjs3" "mail4.andrew.cmu.edu!u2" 481 S: L01 MAILBOX "user.leg" "mail2.andrew.cmu.edu!u1" "leg lrswipcda" 482 S: L01 OK "List Complete" 483 C: L02 LIST "mail4.andrew.cmu.edu!" 484 S: L02 RESERVE "user.rjs3" "mail4.andrew.cmu.edu!u2" 485 S: L02 OK "List Complete" 487 9.7. Command: LOGOUT 489 The LOGOUT command tells the server to close the connection. Its 490 only valid response is the BYE response. The LOGOUT command takes 491 no parameters. 493 9.8. Command: NOOP 495 The NOOP command takes no parameters. Provided the client is 496 authenticated, its only acceptable response is an OK. Any idle 497 timeouts that the server may have on the connection SHOULD be reset 498 upon receipt of this command. 500 If this command is issued after an UPDATE command has been issued, 501 then the OK response also indicates that all pending database 502 updates have been sent to the client. That is, the slave can guar- 503 antee that its local database is up to date as of a certain time by 504 issuing a NOOP and waiting for the OK. The OK MUST NOT return until 506 The MUPDATE Protocol May, 2003 508 all updates that were pending at the time of the NOOP have been 509 sent. 511 9.9. Command: RESERVE 513 The RESERVE command takes two parameters (just like the RESERVE 514 response), the mailbox name to reserve and location data. If the 515 server responds OK, then the mailbox name has been reserved. If the 516 server responds NO, then the mailbox name has not been reserved (for 517 example, another server has reserved it already). This command MUST 518 NOT be issued to a slave. 520 The typical sequence for mailbox creation is: 522 C: R01 RESERVE "user.rjs3.new" "mail3.andrew.cmu.edu!u4" 523 S: R01 OK "Mailbox Reserved." 524 525 C: A01 ACTIVATE "user.rjs3.new" "mail3.andrew.cmu.edu!u4" "rjs3 lrswipcda" 526 S: A01 OK "Mailbox Activated." 528 9.10. Command: STARTTLS 530 The STARTTLS command requests the commencement of a [TLS] negotia- 531 tion. The negotiation begins immediately after the CRLF in the OK 532 response. After a client issues a STARTTLS command, it MUST NOT 533 issue further commands until a server response is seen and the [TLS] 534 negotiation is complete. 536 The STARTTLS command is only valid in non-authenticated state. The 537 server remains in non-authenticated state, even if client creden- 538 tials are supplied during the [TLS] negotiation. The [SASL] EXTERNAL 539 mechanism MAY be used to authenticate once [TLS] client credentials 540 are successfully exchanged. Note that servers are not required to 541 support the EXTERNAL mechanism. 543 After the [TLS] layer is established, the server MUST re-issue the 544 initial response banner (see Section 7.8). This is necessary to pro- 545 tect against man-in-the-middle attacks which alter the capabilities 546 list prior to STARTTLS, as well as to advertise any new SASL mecha- 547 nisms (or other capabilities) that may be available under the layer. 548 The client MUST discard cached capability information and replace it 549 with the new information. 551 After the a successful STARTTLS command, the server SHOULD return a 552 NO response to additional STARTTLS commands. 554 Servers MAY choose to not implement STARTTLS. In this case, they 556 The MUPDATE Protocol May, 2003 558 MUST NOT advertise STARTTLS in their capabilities banner, and SHOULD 559 return a BAD response to the STARTTLS command, if it is issued. 561 Example: 563 C: S01 STARTTLS 564 S: S01 OK "Begin TLS negotiation now" 565 566 S: * AUTH KERBEROS_V4 GSSAPI PLAIN 567 S: * OK MUPDATE "mupdate.andrew.cmu.edu" "Cyrus" "v2.1.2" "(master)" 569 9.11. Command: UPDATE 571 The UPDATE command is how a slave initializes an update stream from 572 the master (though it is also valid to issue this command to a 573 slave). In response to the command, the server returns a list of 574 all mailboxes in its database (the same results as a parameterless 575 LIST command) followed by an OK response. From this point forward, 576 whenever an update occurs to the master database, it MUST stream the 577 update to the slave within 30 seconds. That is, it will send 578 RESERVE, MAILBOX, or DELETE responses as they are applicable. 580 After a client has issued an UPDATE command, it may only issue NOOP 581 and LOGOUT commands for the remainder of the session. 583 Example: 585 C: U01 UPDATE 586 S: U01 MAILBOX "user.leg" "mail2.andrew.cmu.edu!u1" "leg lrswipcda" 587 S: U01 MAILBOX "user.rjs3" "mail3.andrew.cmu.edu!u4" "rjs3 lrswipcda" 588 S: U01 RESERVE "internet.bugtraq" "mail1.andrew.cmu.edu!u5" "anyone lrs" 589 S: U01 OK "Streaming Begins" 590 591 S: U01 RESERVE "user.leg.new" "mail2.andrew.cmu.edu!u1" 592 593 S: U01 MAILBOX "user.leg.new" "mail2.andrew.cmu.edu!u1" "leg lrswipcda" 594 596 C: N01 NOOP 597 S: U01 DELETE "user.leg.new" 598 S: N01 OK "NOOP Complete" 600 10. MUPDATE Formal Syntax 602 The following syntax specification uses the Augmented Backus-Naur 603 Form (ABNF) notation as specified in [ABNF]. This uses the ABNF core 605 The MUPDATE Protocol May, 2003 607 rules as specified in Appendix A of [ABNF]. 609 Except as noted otherwise, all alphabetic characters are case- 610 insensitive. The use of upper or lower case characters to define 611 token strings is for editorial clarity only. Implementations MUST 612 accept these strings in a case-insensitive fashion. 614 Note that this specification also uses some terminals from section 8 615 of [ACAP]. 617 cmd-activate = "ACTIVATE" SP string SP string SP string 619 cmd-authenticate = "AUTHENTICATE" SP sasl-mech [ SP string ] 621 cmd-delete = "DELETE" SP string 623 cmd-find = "FIND" SP string 625 cmd-list = "LIST" [ SP string ] 627 cmd-logout = "LOGOUT" 629 cmd-noop = "NOOP" 631 cmd-reserve = "RESERVE" SP string SP string 633 cmd-starttls = "STARTTLS" 635 cmd-update = "UPDATE" 637 command = tag SP command-type CRLF 639 command-type = cmd-activate / cmd-authenticate / cmd-delete / 640 cmd-find / cmd-list / cmd-logout / cmd-noop / 641 cmd-reserve / cmd-starttls / cmd-update 643 response = tag SP response-type CRLF 645 response-type = rsp-ok / rsp-no / rsp-bad / rsp-bye / rsp-mailbox / 646 rsp-reserve / rsp-delete 648 rsp-bad = "BAD" SP string 650 rep-bye = "BYE" SP string 652 rsp-mailbox = "MAILBOX" SP string SP string SP string 654 rsp-no = "NO" SP string 656 The MUPDATE Protocol May, 2003 658 rsp-ok = "OK" SP string 660 rsp-reserve = "RESERVE" SP string SP string 662 rsp-delete = "DELETE" SP string 664 sasl-mech = 1*ATOM-CHAR 665 ; ATOM-CHAR is defined in [ACAP] 667 string = quoted / literal 668 ; quoted and literal are defined in [ACAP] 670 tag = 1*ATOM-CHAR 671 ; ATOM-CHAR is defined in [ACAP] 673 11. MUPDATE URL Scheme 675 This document defines the a URL scheme for the purposes of referenc- 676 ing MUPDATE resources, according to the requirements in [RFC2717]. 677 This includes both MUPDATE servers as a whole, along with individual 678 mailbox entries on a given MUPDATE server. 680 There is no MIME type associated with these resources. It is 681 intended that a URL consumer would either retrieve the MUPDATE 682 record in question, or simply connect to the MUPDATE server running 683 on the specified host. Note that the consumer will need to have 684 authentication credentials for the specified host. 686 The MUPDATE URL scheme is similar to the IMAP URL scheme [IMAP-URL]. 687 However, it only takes one of two possible forms: 689 mupdate:/// 690 mupdate:/// 692 The first form refers to a MUPDATE server as a whole, the second 693 form indicates both the server and a mailbox to run a FIND against 694 once authenticated to the server. Note that part of may 695 include username and authentication information along with a host- 696 name and port. 698 The MUPDATE Protocol May, 2003 700 11.1. MUPDATE URL Scheme Registration Form 702 URL scheme name: "mupdate" 704 URL scheme syntax: 706 This defines the MUPDATE URL Scheme in [ABNF]. Terminals from 707 the BNF of IMAP URLs [IMAP-URL] are also used. 709 mupdateurl = "mupdate://" iserver "/" [ enc_mailbox ] 710 ; iserver and enc_mailbox are as defined in [IMAP-URL] 712 Character encoding considerations: 714 Identical to those described in [IMAP-URL] for the appropriate 715 terminals. 717 Intended Usage: 719 The form of the URL without an associated mailbox is intended to 720 designate a MUPDATE server only. If a mailbox name is included 721 in the URL, then the consumer is expected to execute a FIND com- 722 mand for that mailbox on the specified server. 724 Applications and/or protocols which use this URL scheme name: 726 The protocol described in this document. 728 Interoperability Considerations: 730 None. 732 Security Considerations: 734 Users of the MUPDATE URL Scheme should review the security con- 735 siderations that are discussed in [IMAP-URL]. In particular, 736 the consequences of including authentication mechanism informa- 737 tion in a URL should be reviewed. 739 Relevant Publications: 741 This document and [IMAP-URL]. 743 Author, Change Controller, and Contact for Further Information: 745 Author of this document. 747 The MUPDATE Protocol May, 2003 749 12. Security Considerations 751 While no unauthenticated users may make modifications or even per- 752 form searches on the database, it is important to note that this 753 specification assumes no protections of any type for authenticated 754 users. 756 All authenticated users have complete access to the database. For 757 this reason it is important to ensure that accounts that are making 758 use of the database are well secured. 760 A more secure deployment might have all read only access go through 761 a slave, and only have accounts which need write access use the mas- 762 ter. This has the disadvantage of a marginally longer time for 763 updates to reach the clients. 765 The protocol assumes that all authenticated users are cooperating to 766 maintain atomic operations. Therefore, all new mailboxes SHOULD be 767 RESERVEd before they are ACTIVATEd, despite the fact that the proto- 768 col does not require this, and it is therefore possible for a set of 769 participants which do not obey the provided locking to create an 770 inconsistent database. RESERVEing the mailbox first is not required 771 to perform an activate because this behavior simplifies synchroniza- 772 tion with the actual location of the mailboxes. 774 13. IANA Considerations 776 This document requests that the IANA provide a TCP port number with 777 the short name of "mupdate". 779 This document requests that the IANA register a URL scheme for the 780 MUPDATE protocol, as defined in section 11.1 of this document. 782 14. Intellectual Property Rights 784 The IETF takes no position regarding the validity or scope of any 785 intellectual property or other rights that might be claimed to per- 786 tain to the implementation or use of the technology described in 787 this document or the extent to which any license under such rights 788 might or might not be available; neither does it represent that it 789 has made any effort to identify any such rights. Information on the 790 IETF's procedures with respect to rights in standards-track and 791 standards-related documentation can be found in BCP-11. Copies of 792 claims of rights made available for publication and any assurances 793 of licenses to be made available, or the result of an attempt made 794 to obtain a general license or permission for the use of such pro- 795 prietary rights by implementors or users of this specification can 796 be obtained from the IETF Secretariat. 798 The MUPDATE Protocol May, 2003 800 The IETF invites any interested party to bring to its attention any 801 copyrights, patents or patent applications, or other proprietary 802 rights which may cover technology that may be required to practice 803 this standard. Please address the information to the IETF Executive 804 Director. 806 15. Copyright 808 Copyright (C) The Internet Society (2002). All Rights Reserved. 810 This document and translations of it may be copied and furnished to 811 others, and derivative works that comment on or otherwise explain it 812 or assist in its implementation may be prepared, copied, published 813 and distributed, in whole or in part, without restriction of any 814 kind, provided that the above copyright notice and this paragraph 815 are included on all such copies and derivative works. However, this 816 document itself may not be modified in any way, such as by removing 817 the copyright notice or references to the Internet Society or other 818 Internet organizations, except as needed for the purpose of devel- 819 oping Internet standards in which case the procedures for copyrights 820 defined in the Internet Standards process must be followed, or as 821 required to translate it into languages other than English. 823 This document and the information contained herein is provided on an 824 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 825 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 826 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 827 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 828 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 830 The MUPDATE Protocol May, 2003 832 16. References 834 The following documents contain normative definitions or specifications 835 that are necessary for correct understanding of this protocol: 837 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Require- 838 ment Levels", BCP 14, RFC 2119, March 1997 840 [IMAP] Crispin, M., "Internet Message Access Protocol", RFC 2060, 841 December 1996. 843 [ABNF] Crocker, D., "Augmented BNF for Syntax Specifications: 844 ABNF", RFC 2234, November, 1997. 846 [MIME] Freed, N. & Bornstein, N., "Multipurpose Internet Mail 847 Extentions (MIME) Part One: Format of Internet Message Bod- 848 ies", RFC 2045, November 1996. 850 [IMAP-ACL] Myers, J., "IMAP4 ACL extention", RFC 2086, January 1997. 852 [SASL] Myers, J., "Simple Authentication and Security Layer 853 (SASL)", RFC 2222, October 1997. 855 [IMAP-URL] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997. 857 [ACAP] Newman, C. & Myers, J., "ACAP -- Application Configuration 858 Access Protocol", RFC 2244, November 1997. 860 [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 861 2246, January 1999. 863 The following references are for informational purposes only: 865 [POP3] Myers, J. & Rose, M., "Post Office Protocol - Version 3", 866 STD 53, RFC 1939, May 1996. 868 [RFC2717] Petke, R. and I. King, "Registration Procedures for URL 869 Scheme Names", RFC 2717, November 1999. 871 The MUPDATE Protocol May, 2003 873 17. Author's Address: 875 Robert Siemborski 876 Carnegie Mellon, Andrew Systems Group 877 Cyert Hall 207 878 5000 Forbes Avenue 879 Pittsburgh, PA 15213 880 +1 412 268 7456 881 rjs3+@andrew.cmu.edu 883 18. Acknowledgments: 885 Lawrence Greenfield and Ken Murchison, for a great deal of input on 886 both the protocol and the text of the drafts.