imapext-2007
view docs/rfc/rfc3656.txt @ 0:ada5e610ab86
imap-2007e
| author | yuuji@gentei.org |
|---|---|
| date | Mon, 14 Sep 2009 15:17:45 +0900 |
| parents | |
| children |
line source
7 Network Working Group R. Siemborski
8 Request for Comments: 3656 Carnegie Mellon University
9 Category: Experimental December 2003
12 The Mailbox Update (MUPDATE)
13 Distributed Mailbox Database Protocol
15 Status of this Memo
17 This memo defines an Experimental Protocol for the Internet
18 community. It does not specify an Internet standard of any kind.
19 Discussion and suggestions for improvement are requested.
20 Distribution of this memo is unlimited.
22 Copyright Notice
24 Copyright (C) The Internet Society (2003). All Rights Reserved.
26 Abstract
28 As the demand for high-performance mail delivery agents increases, it
29 becomes apparent that single-machine solutions are inadequate to the
30 task, both because of capacity limits and that the failure of the
31 single machine means a loss of mail delivery for all users. It is
32 preferable to allow many machines to share the responsibility of mail
33 delivery.
35 The Mailbox Update (MUPDATE) protocol allows a group of Internet
36 Message Access Protocol (IMAP) or Post Office Protocol - Version 3
37 (POP3) servers to function with a unified mailbox namespace. This
38 document is intended to serve as a reference guide to that protocol.
58 Siemborski Experimental [Page 1]
60 RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
63 Table of Contents
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
66 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3
67 2.1. Atoms . . . . . . . . . . . . . . . . . . . . . . . . . 4
68 2.2. Strings . . . . . . . . . . . . . . . . . . . . . . . . 4
69 3. Server Responses . . . . . . . . . . . . . . . . . . . . . . 4
70 3.1. Response: OK . . . . . . . . . . . . . . . . . . . . . 5
71 3.2. Response: NO . . . . . . . . . . . . . . . . . . . . . 5
72 3.3. Response: BAD . . . . . . . . . . . . . . . . . . . . . 5
73 3.4. Response: BYE . . . . . . . . . . . . . . . . . . . . . 6
74 3.5. Response: RESERVE . . . . . . . . . . . . . . . . . . . 6
75 3.6. Response: MAILBOX . . . . . . . . . . . . . . . . . . . 6
76 3.7. Response: DELETE . . . . . . . . . . . . . . . . . . . 7
77 3.8. Server Capability Response. . . . . . . . . . . . . . . 7
78 4. Client Commands . . . . . . . . . . . . . . . . . . . . . . . 8
79 4.1. Command: ACTIVATE . . . . . . . . . . . . . . . . . . . 8
80 4.2. Command: AUTHENTICATE . . . . . . . . . . . . . . . . . 8
81 4.3. Command: DEACTIVATE . . . . . . . . . . . . . . . . . . 9
82 4.4. Command: DELETE . . . . . . . . . . . . . . . . . . . . 9
83 4.5. Command: FIND . . . . . . . . . . . . . . . . . . . . . 9
84 4.6. Command: LIST . . . . . . . . . . . . . . . . . . . . . 10
85 4.7. Command: LOGOUT . . . . . . . . . . . . . . . . . . . . 10
86 4.8. Command: NOOP . . . . . . . . . . . . . . . . . . . . . 10
87 4.9. Command: RESERVE. . . . . . . . . . . . . . . . . . . . 10
88 4.10. Command: STARTTLS . . . . . . . . . . . . . . . . . . . 11
89 4.11. Command: UPDATE . . . . . . . . . . . . . . . . . . . . 12
90 5. MUPDATE Formal Syntax . . . . . . . . . . . . . . . . . . . . 12
91 6. MUPDATE URL Scheme. . . . . . . . . . . . . . . . . . . . . . 14
92 6.1. MUPDATE URL Scheme Registration Form. . . . . . . . . . 14
93 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
94 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
95 9. Intellectual Property Rights. . . . . . . . . . . . . . . . . 16
96 10. References. . . . . . . . . . . . . . . . . . . . . . . . . . 17
97 10.1. Normative References. . . . . . . . . . . . . . . . . . 17
98 10.2. Informative References. . . . . . . . . . . . . . . . . 17
99 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
100 12. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 18
101 13. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 19
114 Siemborski Experimental [Page 2]
116 RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
119 1. Introduction
121 In order to support an architecture where there are multiple [IMAP,
122 POP3] servers sharing a common mailbox database, it is necessary to
123 be able to provide atomic mailbox operations, as well as offer
124 sufficient guarantees about database consistency.
126 The primary goal of the MUPDATE protocol is to be simple to implement
127 yet allow for database consistency between participants.
129 The key words "MUST, "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
130 "RECOMMENDED", and "MAY" in this document are to be interpreted as
131 defined in BCP 14, RFC 2119 [KEYWORDS].
133 In examples, "C:" and "S:" indicate lines sent by the client and
134 server respectively.
136 2. Protocol Overview
138 The MUPDATE protocol assumes a reliable data stream such as a TCP
139 network connection. IANA has registered port 3905 with a short name
140 of "mupdate" for this purpose.
142 In the current implementation of the MUPDATE protocol there are three
143 types of participants: a single master server, slave (or replica)
144 servers, and clients. The master server maintains an authoritative
145 copy of the mailbox database. Slave servers connect to the MUPDATE
146 master server as clients, and function as replicas from the point of
147 view of end clients. End clients may connect to either the master or
148 any slave and perform searches against the database, however
149 operations that change the database can only be performed against the
150 master. For the purposes of protocol discussion we will consider a
151 slave's connection to the master identical to that of any other
152 client.
154 After connection, all commands from a client to server must have an
155 associated unique tag which is an alphanumeric string. Commands MAY
156 be pipelined from the client to the server (that is, the client need
157 not wait for the response before sending the next command). The
158 server MUST execute the commands in the order they were received,
159 however.
161 If the server supports an inactivity login timeout, it MUST be at
162 least 15 minutes.
170 Siemborski Experimental [Page 3]
172 RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
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
177 transmitted as atoms. All other data is considered to a string, and
178 must be quoted or transmitted as a literal.
180 Outside of a literal, both clients and servers MUST support line
181 lengths of at least 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 2.1. Atoms
187 An atom consists of one or more alphanumeric characters. Atoms MUST
188 be less than 15 octets in length.
190 2.2. Strings
192 As in [ACAP], a string may be either literal or a quoted string. A
193 literal is a sequence of zero or more octets (including CR and LF),
194 prefix-quoted with an octet count in the form of an open brace ("{"),
195 the number of octets, an optional plus sign to indicate that the data
196 follows immediately (a non-synchronized literal), a close brace
197 ("}"), and a CRLF sequence. If the plus sign is omitted (a
198 synchronized literal), then the receiving side MUST send a "+ go
199 ahead" response, and the sending side MUST wait for this response.
200 Servers MUST support literals of atleast 4096 octets.
202 Strings that are sent from server to client SHOULD NOT be in the
203 synchronized literal format.
205 A quoted string is a sequence of zero or more 7-bit characters,
206 excluding CR, LF, and the double quote (<">), with double quote
207 characters at each end.
209 The empty string is represented as either "" (a quoted string with
210 zero characters between double quotes) or as {0} followed by CRLF (a
211 literal with an octet count of 0).
213 3. Server Responses
215 Every client command in the MUPDATE protocol may receive one or more
216 tagged responses from the server. Each response is preceded by the
217 same tag as the command that elicited the response from the server.
226 Siemborski Experimental [Page 4]
228 RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
231 3.1. Response: OK
233 A tagged OK response indicates that the operation completed
234 successfully. There is a mandatory implementation-defined string
235 after the OK response. This response also indicates the beginning of
236 the streaming update mode when given in response to an UPDATE
237 command.
239 Example:
241 C: N01 NOOP
242 S: N01 OK "NOOP Complete"
244 3.2. Response: NO
246 A tagged NO response indicates that the operation was explicitly
247 denied by the server or otherwise failed. There is a mandatory
248 implementation-defined string after the NO response that SHOULD
249 explain the reason for denial.
251 Example:
253 C: A01 AUTHENTICATE "PLAIN"
254 S: A01 NO "PLAIN is not a supported SASL mechanism"
256 3.3. Response: BAD
258 A tagged BAD response indicates that the command from the client
259 could not be parsed or understood. There is a mandatory
260 implementation-defined string after the BAD response to provide
261 additional information about the error. Note that untagged BAD
262 responses are allowed if it is unclear what the tag for a given
263 command is (for example, if a blank line is received by the mupdate
264 server, it can generate an untagged BAD response). In the case of an
265 untagged response, the tag should be replaced with a "*".
267 Example:
269 C: C01 SELECT "INBOX"
270 S: C01 BAD "This is not an IMAP server"
271 C:
272 S: * BAD "Need Command"
282 Siemborski Experimental [Page 5]
284 RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
287 3.4. Response: BYE
289 A tagged BYE response indicates that the server has decided to close
290 the connection. There is a mandatory implementation-defined string
291 after the BYE response that SHOULD explain the reason for closing the
292 connection. The server MUST close the connection immediately after
293 transmitting the BYE response.
295 Example:
297 C: L01 LOGOUT
298 S: L01 BYE "User Logged Out"
300 3.5. Response: RESERVE
302 A tagged RESERVE response may only be given in response to a FIND,
303 LIST, or UPDATE command. It includes two parameters: the name of the
304 mailbox that is being reserved (in mUTF-7 encoding, as specified in
305 [IMAP]) and a location string whose contents is defined by the
306 clients that are using the database, though it is RECOMMENDED that
307 the format of this string be the hostname of the server which is
308 storing the mailbox.
310 This response indicates that the given name is no longer available in
311 the namespace, though it does not indicate that the given mailbox is
312 available to clients at the current time.
314 Example:
316 S: U01 RESERVE "internet.bugtraq" "mail2.example.org"
318 3.6. Response: MAILBOX
320 A tagged MAILBOX response may only be given in response to a FIND,
321 LIST, or UPDATE command. It includes three parameters: the name of
322 the mailbox, a location string (as with RESERVE), and a client-
323 defined string that specifies the IMAP ACL [IMAP-ACL] of the mailbox.
324 This message indicates that the given mailbox is ready to be accessed
325 by clients.
327 Example:
329 S: U01 MAILBOX "internet.bugtraq" "mail2.example.org" "anyone rls"
338 Siemborski Experimental [Page 6]
340 RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
343 3.7. Response: DELETE
345 A tagged DELETE response may only be given in response to an UPDATE
346 command, and MUST NOT be given before the OK response to the UPDATE
347 command is given. It contains a single parameter, that of the
348 mailbox that should be deleted from the slave's database. This
349 response indicates that the given mailbox no longer exists in the
350 namespace of the database, and may be given for any mailbox name,
351 active, reserved, or nonexistent. (Though implementations SHOULD NOT
352 issue DELETE responses for nonexistent mailboxes).
354 Example:
356 S: U01 DELETE "user.rjs3.sent-mail-jan-2002"
358 3.8. Server Capability Response
360 Upon connection of the client to the server, and directly following a
361 successful STARTTLS command, the server MUST issue a capabilities
362 banner, of the following format:
364 The banner MUST contain a line that begins with "* AUTH" and contain
365 a space-separated list of SASL mechanisms that the server will accept
366 for authentication. The mechanism names are transmitted as atoms.
367 Servers MAY advertise no available mechanisms (to indicate that
368 STARTTLS must be completed before authentication may occur). If
369 STARTTLS is not supported by the server, then the line MUST contain
370 at least one mechanism.
372 If the banner is being issued without a TLS layer, and the server
373 supports the STARTTLS command, the banner MUST contain the line "*
374 STARTTLS". If the banner is being issued under a TLS layer (or the
375 server does not support STARTTLS), the banner MUST NOT contain this
376 line.
378 The last line of the banner MUST start with "* OK MUPDATE" and be
379 followed by four strings: the server's hostname, an implementation-
380 defined string giving the name of the implementation, an
381 implementation-defined string giving the version of the
382 implementation, and a string that indicates if the server is a master
383 or a slave. The master/slave indication MUST be either "(master)" or
384 an MUPDATE URL that defines where the master can be contacted.
386 Any unrecognized responses before the "* OK MUPDATE" response MUST be
387 ignored by the client.
394 Siemborski Experimental [Page 7]
396 RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
399 Example:
401 S: * AUTH KERBEROS_V4 GSSAPI
402 S: * STARTTLS
403 S: * OK MUPDATE "mupdate.example.org" "Cyrus" "v2.1.2" "(master)"
405 4. Client Commands
407 The following are valid commands that a client may send to the
408 MUPDATE server: AUTHENTICATE, ACTIVATE, DEACTIVATE, DELETE, FIND,
409 LIST, LOGOUT, NOOP, RESERVE, STARTTLS, and UPDATE.
411 Before a successful AUTHENTICATE command has occurred, the server
412 MUST NOT accept any commands except for AUTHENTICATE, STARTTLS, and
413 LOGOUT (and SHOULD reply with a NO response for all other commands).
415 4.1. Command: ACTIVATE
417 The ACTIVATE command has 3 parameters: the mailbox name, its
418 location, and its ACL. This command MUST NOT not be issued to a
419 slave server.
421 This command can also be used to update the ACL or location
422 information of a mailbox. Note that it is not a requirement for a
423 mailbox to be reserved (or even exist in the database) for an
424 ACTIVATE command to succeed, implementations MUST allow this behavior
425 as it facilitates synchronization of the database with the current
426 state of the mailboxes.
428 4.2. Command: AUTHENTICATE
430 The AUTHENTICATE command initiates a [SASL] negotiation session
431 between the client and the server. It has two parameters. The first
432 parameter is mandatory, and is a string indicating the desired [SASL]
433 mechanism. The second is a string containing an optional BASE64
434 encoded (as defined in section 6.8 of [MIME]) client first send.
436 All of the remaining SASL blobs that are sent MUST be sent across the
437 wire must be in BASE64 encoded format, and followed by a CR and LF
438 combination. They MUST NOT be encoded as strings.
440 Clients may cancel authentication by sending a * followed by a CR and
441 LF.
443 The [SASL] service name for the MUPDATE protocol is "mupdate".
444 Implementations are REQUIRED to implement the GSSAPI [SASL]
445 mechanism, though they SHOULD implement as many mechanisms as
446 possible.
450 Siemborski Experimental [Page 8]
452 RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
455 If a security layer is negotiated, it should be used directly
456 following the CR and LF combination at the end of the server's OK
457 response (i.e., beginning with the client's next command) Only one
458 successful AUTHENTICATE command may be issued per session.
460 4.3. Command: DEACTIVATE
462 The DEACTIVATE command takes two parameters, the mailbox name and
463 location data. The mailbox MUST already exist and be activated on
464 the MUPDATE server. If the server responds OK, then the mailbox name
465 has been moved to the RESERVE state. If the server responds NO, then
466 the mailbox name has not been moved (for example, the mailbox was not
467 already active). Any ACL information that is known about the mailbox
468 MAY be lost when a DEACTIVATE succeeds. This command MUST NOT be
469 issued to a slave.
471 Example:
473 C: A01 DEACTIVATE "user.rjs3.new" "mail3.example.org!u4"
474 S: A01 OK "Mailbox Reserved."
476 4.4. Command: DELETE
478 The DELETE command takes only a single parameter, the mailbox name to
479 be removed from the database's namespace. The server SHOULD give a
480 NO response if the mailbox does not exist. This command MUST NOT be
481 issued to a slave server.
483 4.5. Command: FIND
485 The FIND command takes a single parameter, a mailbox name. The
486 server then responds with the current record for the given mailbox,
487 if any, and an OK response.
489 Example (mailbox does not exist):
491 C: F01 FIND "user.rjs3.xyzzy"
492 S: F01 OK "Search Complete"
494 Example (mailbox is reserved):
496 C: F01 FIND "user.rjs3"
497 S: F01 RESERVE "user.rjs3" "mail4.example.org"
498 S: F01 OK "Search Complete"
506 Siemborski Experimental [Page 9]
508 RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
511 4.6. Command: LIST
513 The LIST command is similar to running FIND across the entire
514 database. The LIST command takes a single optional parameter, which
515 is a prefix to try to match against the location field of the
516 records. Without the parameter, LIST returns every record in the
517 database.
519 For each mailbox that matches, either a MAILBOX or a RESERVE response
520 (as applicable) is sent to the client. When all responses are
521 complete, an OK response is issued.
523 Example:
525 C: L01 LIST
526 S: L01 RESERVE "user.rjs3" "mail4.example.org!u2"
527 S: L01 MAILBOX "user.leg" "mail2.example.org!u1" "leg lrswipcda"
528 S: L01 OK "List Complete"
529 C: L02 LIST "mail4.example.org!"
530 S: L02 RESERVE "user.rjs3" "mail4.example.org!u2"
531 S: L02 OK "List Complete"
533 4.7. Command: LOGOUT
535 The LOGOUT command tells the server to close the connection. Its
536 only valid response is the BYE response. The LOGOUT command takes no
537 parameters.
539 4.8. Command: NOOP
541 The NOOP command takes no parameters. Provided the client is
542 authenticated, its only acceptable response is an OK. Any idle
543 timeouts that the server may have on the connection SHOULD be reset
544 upon receipt of this command.
546 If this command is issued after an UPDATE command has been issued,
547 then the OK response also indicates that all pending database updates
548 have been sent to the client. That is, the slave can guarantee that
549 its local database is up to date as of a certain time by issuing a
550 NOOP and waiting for the OK. The OK MUST NOT return until all
551 updates that were pending at the time of the NOOP have been sent.
553 4.9. Command: RESERVE
555 The RESERVE command takes two parameters (just like the RESERVE
556 response), the mailbox name to reserve and location data. If the
557 server responds OK, then the mailbox name has been reserved. If the
558 server responds NO, then the mailbox name has not been reserved (for
562 Siemborski Experimental [Page 10]
564 RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
567 example, another server has reserved it already). This command MUST
568 NOT be issued to a slave.
570 The typical sequence for mailbox creation is:
572 C: R01 RESERVE "user.rjs3.new" "mail3.example.org!u4"
573 S: R01 OK "Mailbox Reserved."
574 <client does local mailbox create operations>
575 C: A01 ACTIVATE "user.rjs3.new" "mail3.example.org!u4" "rjs3 lrswipcda"
576 S: A01 OK "Mailbox Activated."
578 4.10. Command: STARTTLS
580 The STARTTLS command requests the commencement of a [TLS]
581 negotiation. The negotiation begins immediately after the CRLF in
582 the OK response. After a client issues a STARTTLS command, it MUST
583 NOT issue further commands until a server response is seen and the
584 [TLS] negotiation is complete.
586 The STARTTLS command is only valid in non-authenticated state. The
587 server remains in non-authenticated state, even if client credentials
588 are supplied during the [TLS] negotiation. The [SASL] EXTERNAL
589 mechanism MAY be used to authenticate once [TLS] client credentials
590 are successfully exchanged. Note that servers are not required to
591 support the EXTERNAL mechanism.
593 After the [TLS] layer is established, the server MUST re-issue the
594 initial response banner (see Section 3.8). This is necessary to
595 protect against man-in-the-middle attacks which alter the
596 capabilities list prior to STARTTLS, as well as to advertise any new
597 SASL mechanisms (or other capabilities) that may be available under
598 the layer. The client MUST discard cached capability information and
599 replace it with the new information.
601 After the a successful STARTTLS command, the server SHOULD return a
602 NO response to additional STARTTLS commands.
604 Servers MAY choose to not implement STARTTLS. In this case, they
605 MUST NOT advertise STARTTLS in their capabilities banner, and SHOULD
606 return a BAD response to the STARTTLS command, if it is issued.
608 Example:
610 C: S01 STARTTLS
611 S: S01 OK "Begin TLS negotiation now"
612 <TLS negotiation, further commands are under TLS layer>
613 S: * AUTH KERBEROS_V4 GSSAPI PLAIN
614 S: * OK MUPDATE "mupdate.example.org" "Cyrus" "v2.1.2" "(master)"
618 Siemborski Experimental [Page 11]
620 RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
623 4.11. Command: UPDATE
625 The UPDATE command is how a slave initializes an update stream from
626 the master (though it is also valid to issue this command to a
627 slave). In response to the command, the server returns a list of all
628 mailboxes in its database (the same results as a parameterless LIST
629 command) followed by an OK response. From this point forward,
630 whenever an update occurs to the master database, it MUST stream the
631 update to the slave within 30 seconds. That is, it will send
632 RESERVE, MAILBOX, or DELETE responses as they are applicable.
634 After a client has issued an UPDATE command, it may only issue NOOP
635 and LOGOUT commands for the remainder of the session.
637 Example:
639 C: U01 UPDATE
640 S: U01 MAILBOX "user.leg" "mail2.example.org!u1" "leg lrswipcda"
641 S: U01 MAILBOX "user.rjs3" "mail3.example.org!u4" "rjs3 lrswipcda"
642 S: U01 RESERVE "internet.bugtraq" "mail1.example.org!u5" "anyone lrs"
643 S: U01 OK "Streaming Begins"
644 <some time goes by, and another client creates a new mailbox>
645 S: U01 RESERVE "user.leg.new" "mail2.example.org!u1"
646 <some more time passes, and the create succeeds>
647 S: U01 MAILBOX "user.leg.new" "mail2.example.org!u1" "leg lrswipcda"
648 <much more time passes, and the slave decides to send a NOOP to reset
649 its inactivity timer>
650 C: N01 NOOP
651 S: U01 DELETE "user.leg.new"
652 S: N01 OK "NOOP Complete"
654 5. MUPDATE Formal Syntax
656 The following syntax specification uses the Augmented Backus-Naur
657 Form (ABNF) notation as specified in [ABNF]. This uses the ABNF core
658 rules as specified in Appendix A of [ABNF].
660 Except as noted otherwise, all alphabetic characters are case-
661 insensitive. The use of upper or lower case characters to define
662 token strings is for editorial clarity only. Implementations MUST
663 accept these strings in a case-insensitive fashion.
665 Note that this specification also uses some terminals from section 8
666 of [ACAP].
668 cmd-activate = "ACTIVATE" SP string SP string SP string
670 cmd-authenticate = "AUTHENTICATE" SP sasl-mech [ SP string ]
674 Siemborski Experimental [Page 12]
676 RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
679 cmd-delete = "DELETE" SP string
681 cmd-find = "FIND" SP string
683 cmd-list = "LIST" [ SP string ]
685 cmd-logout = "LOGOUT"
687 cmd-noop = "NOOP"
689 cmd-reserve = "RESERVE" SP string SP string
691 cmd-starttls = "STARTTLS"
693 cmd-update = "UPDATE"
695 command = tag SP command-type CRLF
697 command-type = cmd-activate / cmd-authenticate / cmd-delete /
698 cmd-find / cmd-list / cmd-logout / cmd-noop /
699 cmd-reserve / cmd-starttls / cmd-update
701 response = tag SP response-type CRLF
703 response-type = rsp-ok / rsp-no / rsp-bad / rsp-bye / rsp-mailbox /
704 rsp-reserve / rsp-delete
706 rsp-bad = "BAD" SP string
708 rsp-bye = "BYE" SP string
710 rsp-mailbox = "MAILBOX" SP string SP string SP string
712 rsp-no = "NO" SP string
714 rsp-ok = "OK" SP string
716 rsp-reserve = "RESERVE" SP string SP string
718 rsp-delete = "DELETE" SP string
720 sasl-mech = 1*ATOM-CHAR
721 ; ATOM-CHAR is defined in [ACAP]
723 string = quoted / literal
724 ; quoted and literal are defined in [ACAP]
730 Siemborski Experimental [Page 13]
732 RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
735 tag = 1*ATOM-CHAR
736 ; ATOM-CHAR is defined in [ACAP]
738 6. MUPDATE URL Scheme
740 This document defines the a URL scheme for the purposes of
741 referencing MUPDATE resources, according to the requirements in
742 [RFC2717]. This includes both MUPDATE servers as a whole, along with
743 individual mailbox entries on a given MUPDATE server.
745 There is no MIME type associated with these resources. It is
746 intended that a URL consumer would either retrieve the MUPDATE record
747 in question, or simply connect to the MUPDATE server running on the
748 specified host. Note that the consumer will need to have
749 authentication credentials for the specified host.
751 The MUPDATE URL scheme is similar to the IMAP URL scheme [IMAP-URL].
752 However, it only takes one of two possible forms:
754 mupdate://<iserver>/
755 mupdate://<iserver>/<mailbox>
757 The first form refers to a MUPDATE server as a whole, the second form
758 indicates both the server and a mailbox to run a FIND against once
759 authenticated to the server. Note that part of <iserver> may include
760 username and authentication information along with a hostname and
761 port.
763 6.1. MUPDATE URL Scheme Registration Form
765 URL scheme name: "mupdate"
767 URL scheme syntax:
769 This defines the MUPDATE URL Scheme in [ABNF]. Terminals from the
770 BNF of IMAP URLs [IMAP-URL] are also used.
772 mupdateurl = "mupdate://" iserver "/" [ enc_mailbox ]
773 ; iserver and enc_mailbox are as defined in [IMAP-URL]
775 Character encoding considerations:
777 Identical to those described in [IMAP-URL] for the appropriate
778 terminals.
786 Siemborski Experimental [Page 14]
788 RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
791 Intended Usage:
793 The form of the URL without an associated mailbox is intended to
794 designate a MUPDATE server only. If a mailbox name is included in
795 the URL, then the consumer is expected to execute a FIND command
796 for that mailbox on the specified server.
798 Applications and/or protocols which use this URL scheme name:
800 The protocol described in this document.
802 Interoperability Considerations:
804 None.
806 Security Considerations:
808 Users of the MUPDATE URL Scheme should review the security
809 considerations that are discussed in [IMAP-URL]. In particular,
810 the consequences of including authentication mechanism information
811 in a URL should be reviewed.
813 Relevant Publications:
815 This document and [IMAP-URL].
817 Author, Change Controller, and Contact for Further Information:
819 Author of this document.
821 7. Security Considerations
823 While no unauthenticated users may make modifications or even perform
824 searches on the database, it is important to note that this
825 specification assumes no protections of any type for authenticated
826 users.
828 All authenticated users have complete access to the database. For
829 this reason it is important to ensure that accounts that are making
830 use of the database are well secured.
832 A more secure deployment might have all read only access go through a
833 slave, and only have accounts which need write access use the master.
834 This has the disadvantage of a marginally longer time for updates to
835 reach the clients.
842 Siemborski Experimental [Page 15]
844 RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
847 The protocol assumes that all authenticated users are cooperating to
848 maintain atomic operations. Therefore, all new mailboxes SHOULD be
849 RESERVEd before they are ACTIVATEd, despite the fact that the
850 protocol does not require this, and it is therefore possible for a
851 set of participants which do not obey the provided locking to create
852 an inconsistent database. RESERVEing the mailbox first is not
853 required to perform an activate because this behavior simplifies
854 synchronization with the actual location of the mailboxes.
856 8. IANA Considerations
858 The IANA has assigned TCP port number 3905 to "mupdate".
860 The IANA has registered a URL scheme for the MUPDATE protocol, as
861 defined in section 6.1 of this document.
863 IANA has registered a GSSAPI service name of "mupdate" for the
864 MUPDATE protocol in the registry maintained at:
866 http://www.iana.org/assignments/gssapi-service-names
868 9. Intellectual Property Rights
870 The IETF takes no position regarding the validity or scope of any
871 intellectual property or other rights that might be claimed to
872 pertain to the implementation or use of the technology described in
873 this document or the extent to which any license under such rights
874 might or might not be available; neither does it represent that it
875 has made any effort to identify any such rights. Information on the
876 IETF's procedures with respect to rights in standards-track and
877 standards-related documentation can be found in BCP-11. Copies of
878 claims of rights made available for publication and any assurances of
879 licenses to be made available, or the result of an attempt made to
880 obtain a general license or permission for the use of such
881 proprietary rights by implementors or users of this specification can
882 be obtained from the IETF Secretariat.
884 The IETF invites any interested party to bring to its attention any
885 copyrights, patents or patent applications, or other proprietary
886 rights which may cover technology that may be required to practice
887 this standard. Please address the information to the IETF Executive
888 Director.
898 Siemborski Experimental [Page 16]
900 RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
903 10. References
905 10.1. Normative References
907 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
908 Requirement Levels", BCP 14, RFC 2119, March 1997.
910 [IMAP] Crispin, M., "Internet Message Access Protocol - Version
911 4", RFC 3501, March 2003.
913 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for
914 Syntax Specifications: ABNF", RFC 2234, November 1997.
916 [MIME] Freed, N. and N. Bornstein, "Multipurpose Internet Mail
917 Extensions (MIME) Part One: Format of Internet Message
918 Bodies", RFC 2045, November 1996.
920 [IMAP-ACL] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997.
922 [SASL] Myers, J., "Simple Authentication and Security Layer
923 (SASL)", RFC 2222, October 1997.
925 [IMAP-URL] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
927 [ACAP] Newman, C. and J. Myers, "ACAP -- Application
928 Configuration Access Protocol", RFC 2244, November 1997.
930 [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
931 RFC 2246, January 1999.
933 10.2. Informative References
935 [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version
936 3", STD 53, RFC 1939, May 1996.
938 [RFC2717] Petke, R. and I. King, "Registration Procedures for URL
939 Scheme Names", BCP 35, RFC 2717, November 1999.
954 Siemborski Experimental [Page 17]
956 RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
959 11. Acknowledgments
961 Lawrence Greenfield and Ken Murchison, for a great deal of input on
962 both the protocol and the text of the documents.
964 12. Author's Address
966 Robert Siemborski
967 Carnegie Mellon, Andrew Systems Group
968 Cyert Hall 207
969 5000 Forbes Avenue
970 Pittsburgh, PA 15213
972 Phone: (412) 268-7456
973 EMail: rjs3+@andrew.cmu.edu
1010 Siemborski Experimental [Page 18]
1012 RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
1015 13. Full Copyright Statement
1017 Copyright (C) The Internet Society (2003). All Rights Reserved.
1019 This document and translations of it may be copied and furnished to
1020 others, and derivative works that comment on or otherwise explain it
1021 or assist in its implementation may be prepared, copied, published
1022 and distributed, in whole or in part, without restriction of any
1023 kind, provided that the above copyright notice and this paragraph are
1024 included on all such copies and derivative works. However, this
1025 document itself may not be modified in any way, such as by removing
1026 the copyright notice or references to the Internet Society or other
1027 Internet organizations, except as needed for the purpose of
1028 developing Internet standards in which case the procedures for
1029 copyrights defined in the Internet Standards process must be
1030 followed, or as required to translate it into languages other than
1031 English.
1033 The limited permissions granted above are perpetual and will not be
1034 revoked by the Internet Society or its successors or assignees.
1036 This document and the information contained herein is provided on an
1037 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1038 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1039 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1040 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1041 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1043 Acknowledgement
1045 Funding for the RFC Editor function is currently provided by the
1046 Internet Society.
1066 Siemborski Experimental [Page 19]