diff options
Diffstat (limited to 'imap/docs/rfc/rfc3656.txt')
| -rw-r--r-- | imap/docs/rfc/rfc3656.txt | 1067 |
1 files changed, 0 insertions, 1067 deletions
diff --git a/imap/docs/rfc/rfc3656.txt b/imap/docs/rfc/rfc3656.txt deleted file mode 100644 index 6c0ab5b1..00000000 --- a/imap/docs/rfc/rfc3656.txt +++ /dev/null @@ -1,1067 +0,0 @@ - - - - - - -Network Working Group R. Siemborski -Request for Comments: 3656 Carnegie Mellon University -Category: Experimental December 2003 - - - The Mailbox Update (MUPDATE) - Distributed Mailbox Database Protocol - -Status of this Memo - - This memo defines an Experimental Protocol for the Internet - community. It does not specify an Internet standard of any kind. - Discussion and suggestions for improvement are requested. - Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - As the demand for high-performance mail delivery agents increases, it - becomes apparent that single-machine solutions are inadequate to the - task, both because of capacity limits and that the failure of the - single machine means a loss of mail delivery for all users. It is - preferable to allow many machines to share the responsibility of mail - delivery. - - The Mailbox Update (MUPDATE) protocol allows a group of Internet - Message Access Protocol (IMAP) or Post Office Protocol - Version 3 - (POP3) servers to function with a unified mailbox namespace. This - document is intended to serve as a reference guide to that protocol. - - - - - - - - - - - - - - - - - - - -Siemborski Experimental [Page 1] - -RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 - 2.1. Atoms . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.2. Strings . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. Server Responses . . . . . . . . . . . . . . . . . . . . . . 4 - 3.1. Response: OK . . . . . . . . . . . . . . . . . . . . . 5 - 3.2. Response: NO . . . . . . . . . . . . . . . . . . . . . 5 - 3.3. Response: BAD . . . . . . . . . . . . . . . . . . . . . 5 - 3.4. Response: BYE . . . . . . . . . . . . . . . . . . . . . 6 - 3.5. Response: RESERVE . . . . . . . . . . . . . . . . . . . 6 - 3.6. Response: MAILBOX . . . . . . . . . . . . . . . . . . . 6 - 3.7. Response: DELETE . . . . . . . . . . . . . . . . . . . 7 - 3.8. Server Capability Response. . . . . . . . . . . . . . . 7 - 4. Client Commands . . . . . . . . . . . . . . . . . . . . . . . 8 - 4.1. Command: ACTIVATE . . . . . . . . . . . . . . . . . . . 8 - 4.2. Command: AUTHENTICATE . . . . . . . . . . . . . . . . . 8 - 4.3. Command: DEACTIVATE . . . . . . . . . . . . . . . . . . 9 - 4.4. Command: DELETE . . . . . . . . . . . . . . . . . . . . 9 - 4.5. Command: FIND . . . . . . . . . . . . . . . . . . . . . 9 - 4.6. Command: LIST . . . . . . . . . . . . . . . . . . . . . 10 - 4.7. Command: LOGOUT . . . . . . . . . . . . . . . . . . . . 10 - 4.8. Command: NOOP . . . . . . . . . . . . . . . . . . . . . 10 - 4.9. Command: RESERVE. . . . . . . . . . . . . . . . . . . . 10 - 4.10. Command: STARTTLS . . . . . . . . . . . . . . . . . . . 11 - 4.11. Command: UPDATE . . . . . . . . . . . . . . . . . . . . 12 - 5. MUPDATE Formal Syntax . . . . . . . . . . . . . . . . . . . . 12 - 6. MUPDATE URL Scheme. . . . . . . . . . . . . . . . . . . . . . 14 - 6.1. MUPDATE URL Scheme Registration Form. . . . . . . . . . 14 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 9. Intellectual Property Rights. . . . . . . . . . . . . . . . . 16 - 10. References. . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 10.1. Normative References. . . . . . . . . . . . . . . . . . 17 - 10.2. Informative References. . . . . . . . . . . . . . . . . 17 - 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 - 12. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 18 - 13. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 19 - - - - - - - - - - - - -Siemborski Experimental [Page 2] - -RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003 - - -1. Introduction - - In order to support an architecture where there are multiple [IMAP, - POP3] servers sharing a common mailbox database, it is necessary to - be able to provide atomic mailbox operations, as well as offer - sufficient guarantees about database consistency. - - The primary goal of the MUPDATE protocol is to be simple to implement - yet allow for database consistency between participants. - - The key words "MUST, "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", - "RECOMMENDED", and "MAY" in this document are to be interpreted as - defined in BCP 14, RFC 2119 [KEYWORDS]. - - In examples, "C:" and "S:" indicate lines sent by the client and - server respectively. - -2. Protocol Overview - - The MUPDATE protocol assumes a reliable data stream such as a TCP - network connection. IANA has registered port 3905 with a short name - of "mupdate" for this purpose. - - In the current implementation of the MUPDATE protocol there are three - types of participants: a single master server, slave (or replica) - servers, and clients. The master server maintains an authoritative - copy of the mailbox database. Slave servers connect to the MUPDATE - master server as clients, and function as replicas from the point of - view of end clients. End clients may connect to either the master or - any slave and perform searches against the database, however - operations that change the database can only be performed against the - master. For the purposes of protocol discussion we will consider a - slave's connection to the master identical to that of any other - client. - - After connection, all commands from a client to server must have an - associated unique tag which is an alphanumeric string. Commands MAY - be pipelined from the client to the server (that is, the client need - not wait for the response before sending the next command). The - server MUST execute the commands in the order they were received, - however. - - If the server supports an inactivity login timeout, it MUST be at - least 15 minutes. - - - - - - - -Siemborski Experimental [Page 3] - -RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003 - - - MUPDATE uses data formats similar to those used in [ACAP]. That is, - atoms and strings. All commands and tags in the protocol are - transmitted as atoms. All other data is considered to a string, and - must be quoted or transmitted as a literal. - - Outside of a literal, both clients and servers MUST support line - lengths of at least 1024 octets (including the trailing CR and LF - characters). If a line of a longer length must be transmitted, - implementations MUST make use of literals to do so. - -2.1. Atoms - - An atom consists of one or more alphanumeric characters. Atoms MUST - be less than 15 octets in length. - -2.2. Strings - - As in [ACAP], a string may be either literal or a quoted string. A - literal is a sequence of zero or more octets (including CR and LF), - prefix-quoted with an octet count in the form of an open brace ("{"), - the number of octets, an optional plus sign to indicate that the data - follows immediately (a non-synchronized literal), a close brace - ("}"), and a CRLF sequence. If the plus sign is omitted (a - synchronized literal), then the receiving side MUST send a "+ go - ahead" response, and the sending side MUST wait for this response. - Servers MUST support literals of atleast 4096 octets. - - Strings that are sent from server to client SHOULD NOT be in the - synchronized literal format. - - A quoted string is a sequence of zero or more 7-bit characters, - excluding CR, LF, and the double quote (<">), with double quote - characters at each end. - - The empty string is represented as either "" (a quoted string with - zero characters between double quotes) or as {0} followed by CRLF (a - literal with an octet count of 0). - -3. Server Responses - - Every client command in the MUPDATE protocol may receive one or more - tagged responses from the server. Each response is preceded by the - same tag as the command that elicited the response from the server. - - - - - - - - -Siemborski Experimental [Page 4] - -RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003 - - -3.1. Response: OK - - A tagged OK response indicates that the operation completed - successfully. There is a mandatory implementation-defined string - after the OK response. This response also indicates the beginning of - the streaming update mode when given in response to an UPDATE - command. - - Example: - -C: N01 NOOP -S: N01 OK "NOOP Complete" - -3.2. Response: NO - - A tagged NO response indicates that the operation was explicitly - denied by the server or otherwise failed. There is a mandatory - implementation-defined string after the NO response that SHOULD - explain the reason for denial. - - Example: - -C: A01 AUTHENTICATE "PLAIN" -S: A01 NO "PLAIN is not a supported SASL mechanism" - -3.3. Response: BAD - - A tagged BAD response indicates that the command from the client - could not be parsed or understood. There is a mandatory - implementation-defined string after the BAD response to provide - additional information about the error. Note that untagged BAD - responses are allowed if it is unclear what the tag for a given - command is (for example, if a blank line is received by the mupdate - server, it can generate an untagged BAD response). In the case of an - untagged response, the tag should be replaced with a "*". - - Example: - -C: C01 SELECT "INBOX" -S: C01 BAD "This is not an IMAP server" -C: -S: * BAD "Need Command" - - - - - - - - - -Siemborski Experimental [Page 5] - -RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003 - - -3.4. Response: BYE - - A tagged BYE response indicates that the server has decided to close - the connection. There is a mandatory implementation-defined string - after the BYE response that SHOULD explain the reason for closing the - connection. The server MUST close the connection immediately after - transmitting the BYE response. - - Example: - -C: L01 LOGOUT -S: L01 BYE "User Logged Out" - -3.5. Response: RESERVE - - A tagged RESERVE response may only be given in response to a FIND, - LIST, or UPDATE command. It includes two parameters: the name of the - mailbox that is being reserved (in mUTF-7 encoding, as specified in - [IMAP]) and a location string whose contents is defined by the - clients that are using the database, though it is RECOMMENDED that - the format of this string be the hostname of the server which is - storing the mailbox. - - This response indicates that the given name is no longer available in - the namespace, though it does not indicate that the given mailbox is - available to clients at the current time. - - Example: - -S: U01 RESERVE "internet.bugtraq" "mail2.example.org" - -3.6. Response: MAILBOX - - A tagged MAILBOX response may only be given in response to a FIND, - LIST, or UPDATE command. It includes three parameters: the name of - the mailbox, a location string (as with RESERVE), and a client- - defined string that specifies the IMAP ACL [IMAP-ACL] of the mailbox. - This message indicates that the given mailbox is ready to be accessed - by clients. - - Example: - -S: U01 MAILBOX "internet.bugtraq" "mail2.example.org" "anyone rls" - - - - - - - - -Siemborski Experimental [Page 6] - -RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003 - - -3.7. Response: DELETE - - A tagged DELETE response may only be given in response to an UPDATE - command, and MUST NOT be given before the OK response to the UPDATE - command is given. It contains a single parameter, that of the - mailbox that should be deleted from the slave's database. This - response indicates that the given mailbox no longer exists in the - namespace of the database, and may be given for any mailbox name, - active, reserved, or nonexistent. (Though implementations SHOULD NOT - issue DELETE responses for nonexistent mailboxes). - - Example: - -S: U01 DELETE "user.rjs3.sent-mail-jan-2002" - -3.8. Server Capability Response - - Upon connection of the client to the server, and directly following a - successful STARTTLS command, the server MUST issue a capabilities - banner, of the following format: - - The banner MUST contain a line that begins with "* AUTH" and contain - a space-separated list of SASL mechanisms that the server will accept - for authentication. The mechanism names are transmitted as atoms. - Servers MAY advertise no available mechanisms (to indicate that - STARTTLS must be completed before authentication may occur). If - STARTTLS is not supported by the server, then the line MUST contain - at least one mechanism. - - If the banner is being issued without a TLS layer, and the server - supports the STARTTLS command, the banner MUST contain the line "* - STARTTLS". If the banner is being issued under a TLS layer (or the - server does not support STARTTLS), the banner MUST NOT contain this - line. - - The last line of the banner MUST start with "* OK MUPDATE" and be - followed by four strings: the server's hostname, an implementation- - defined string giving the name of the implementation, an - implementation-defined string giving the version of the - implementation, and a string that indicates if the server is a master - or a slave. The master/slave indication MUST be either "(master)" or - an MUPDATE URL that defines where the master can be contacted. - - Any unrecognized responses before the "* OK MUPDATE" response MUST be - ignored by the client. - - - - - - -Siemborski Experimental [Page 7] - -RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003 - - - Example: - -S: * AUTH KERBEROS_V4 GSSAPI -S: * STARTTLS -S: * OK MUPDATE "mupdate.example.org" "Cyrus" "v2.1.2" "(master)" - -4. Client Commands - - The following are valid commands that a client may send to the - MUPDATE server: AUTHENTICATE, ACTIVATE, DEACTIVATE, DELETE, FIND, - LIST, LOGOUT, NOOP, RESERVE, STARTTLS, and UPDATE. - - Before a successful AUTHENTICATE command has occurred, the server - MUST NOT accept any commands except for AUTHENTICATE, STARTTLS, and - LOGOUT (and SHOULD reply with a NO response for all other commands). - -4.1. Command: ACTIVATE - - The ACTIVATE command has 3 parameters: the mailbox name, its - location, and its ACL. This command MUST NOT not be issued to a - slave server. - - This command can also be used to update the ACL or location - information of a mailbox. Note that it is not a requirement for a - mailbox to be reserved (or even exist in the database) for an - ACTIVATE command to succeed, implementations MUST allow this behavior - as it facilitates synchronization of the database with the current - state of the mailboxes. - -4.2. Command: AUTHENTICATE - - The AUTHENTICATE command initiates a [SASL] negotiation session - between the client and the server. It has two parameters. The first - parameter is mandatory, and is a string indicating the desired [SASL] - mechanism. The second is a string containing an optional BASE64 - encoded (as defined in section 6.8 of [MIME]) client first send. - - All of the remaining SASL blobs that are sent MUST be sent across the - wire must be in BASE64 encoded format, and followed by a CR and LF - combination. They MUST NOT be encoded as strings. - - Clients may cancel authentication by sending a * followed by a CR and - LF. - - The [SASL] service name for the MUPDATE protocol is "mupdate". - Implementations are REQUIRED to implement the GSSAPI [SASL] - mechanism, though they SHOULD implement as many mechanisms as - possible. - - - -Siemborski Experimental [Page 8] - -RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003 - - - If a security layer is negotiated, it should be used directly - following the CR and LF combination at the end of the server's OK - response (i.e., beginning with the client's next command) Only one - successful AUTHENTICATE command may be issued per session. - -4.3. Command: DEACTIVATE - - The DEACTIVATE command takes two parameters, the mailbox name and - location data. The mailbox MUST already exist and be activated on - the MUPDATE server. If the server responds OK, then the mailbox name - has been moved to the RESERVE state. If the server responds NO, then - the mailbox name has not been moved (for example, the mailbox was not - already active). Any ACL information that is known about the mailbox - MAY be lost when a DEACTIVATE succeeds. This command MUST NOT be - issued to a slave. - - Example: - -C: A01 DEACTIVATE "user.rjs3.new" "mail3.example.org!u4" -S: A01 OK "Mailbox Reserved." - -4.4. Command: DELETE - - The DELETE command takes only a single parameter, the mailbox name to - be removed from the database's namespace. The server SHOULD give a - NO response if the mailbox does not exist. This command MUST NOT be - issued to a slave server. - -4.5. Command: FIND - - The FIND command takes a single parameter, a mailbox name. The - server then responds with the current record for the given mailbox, - if any, and an OK response. - - Example (mailbox does not exist): - -C: F01 FIND "user.rjs3.xyzzy" -S: F01 OK "Search Complete" - - Example (mailbox is reserved): - -C: F01 FIND "user.rjs3" -S: F01 RESERVE "user.rjs3" "mail4.example.org" -S: F01 OK "Search Complete" - - - - - - - -Siemborski Experimental [Page 9] - -RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003 - - -4.6. Command: LIST - - The LIST command is similar to running FIND across the entire - database. The LIST command takes a single optional parameter, which - is a prefix to try to match against the location field of the - records. Without the parameter, LIST returns every record in the - database. - - For each mailbox that matches, either a MAILBOX or a RESERVE response - (as applicable) is sent to the client. When all responses are - complete, an OK response is issued. - - Example: - -C: L01 LIST -S: L01 RESERVE "user.rjs3" "mail4.example.org!u2" -S: L01 MAILBOX "user.leg" "mail2.example.org!u1" "leg lrswipcda" -S: L01 OK "List Complete" -C: L02 LIST "mail4.example.org!" -S: L02 RESERVE "user.rjs3" "mail4.example.org!u2" -S: L02 OK "List Complete" - -4.7. Command: LOGOUT - - The LOGOUT command tells the server to close the connection. Its - only valid response is the BYE response. The LOGOUT command takes no - parameters. - -4.8. Command: NOOP - - The NOOP command takes no parameters. Provided the client is - authenticated, its only acceptable response is an OK. Any idle - timeouts that the server may have on the connection SHOULD be reset - upon receipt of this command. - - If this command is issued after an UPDATE command has been issued, - then the OK response also indicates that all pending database updates - have been sent to the client. That is, the slave can guarantee that - its local database is up to date as of a certain time by issuing a - NOOP and waiting for the OK. The OK MUST NOT return until all - updates that were pending at the time of the NOOP have been sent. - -4.9. Command: RESERVE - - The RESERVE command takes two parameters (just like the RESERVE - response), the mailbox name to reserve and location data. If the - server responds OK, then the mailbox name has been reserved. If the - server responds NO, then the mailbox name has not been reserved (for - - - -Siemborski Experimental [Page 10] - -RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003 - - - example, another server has reserved it already). This command MUST - NOT be issued to a slave. - - The typical sequence for mailbox creation is: - -C: R01 RESERVE "user.rjs3.new" "mail3.example.org!u4" -S: R01 OK "Mailbox Reserved." -<client does local mailbox create operations> -C: A01 ACTIVATE "user.rjs3.new" "mail3.example.org!u4" "rjs3 lrswipcda" -S: A01 OK "Mailbox Activated." - -4.10. Command: STARTTLS - - The STARTTLS command requests the commencement of a [TLS] - negotiation. The negotiation begins immediately after the CRLF in - the OK response. After a client issues a STARTTLS command, it MUST - NOT issue further commands until a server response is seen and the - [TLS] negotiation is complete. - - The STARTTLS command is only valid in non-authenticated state. The - server remains in non-authenticated state, even if client credentials - are supplied during the [TLS] negotiation. The [SASL] EXTERNAL - mechanism MAY be used to authenticate once [TLS] client credentials - are successfully exchanged. Note that servers are not required to - support the EXTERNAL mechanism. - - After the [TLS] layer is established, the server MUST re-issue the - initial response banner (see Section 3.8). This is necessary to - protect against man-in-the-middle attacks which alter the - capabilities list prior to STARTTLS, as well as to advertise any new - SASL mechanisms (or other capabilities) that may be available under - the layer. The client MUST discard cached capability information and - replace it with the new information. - - After the a successful STARTTLS command, the server SHOULD return a - NO response to additional STARTTLS commands. - - Servers MAY choose to not implement STARTTLS. In this case, they - MUST NOT advertise STARTTLS in their capabilities banner, and SHOULD - return a BAD response to the STARTTLS command, if it is issued. - - Example: - -C: S01 STARTTLS -S: S01 OK "Begin TLS negotiation now" -<TLS negotiation, further commands are under TLS layer> -S: * AUTH KERBEROS_V4 GSSAPI PLAIN -S: * OK MUPDATE "mupdate.example.org" "Cyrus" "v2.1.2" "(master)" - - - -Siemborski Experimental [Page 11] - -RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003 - - -4.11. Command: UPDATE - - The UPDATE command is how a slave initializes an update stream from - the master (though it is also valid to issue this command to a - slave). In response to the command, the server returns a list of all - mailboxes in its database (the same results as a parameterless LIST - command) followed by an OK response. From this point forward, - whenever an update occurs to the master database, it MUST stream the - update to the slave within 30 seconds. That is, it will send - RESERVE, MAILBOX, or DELETE responses as they are applicable. - - After a client has issued an UPDATE command, it may only issue NOOP - and LOGOUT commands for the remainder of the session. - - Example: - -C: U01 UPDATE -S: U01 MAILBOX "user.leg" "mail2.example.org!u1" "leg lrswipcda" -S: U01 MAILBOX "user.rjs3" "mail3.example.org!u4" "rjs3 lrswipcda" -S: U01 RESERVE "internet.bugtraq" "mail1.example.org!u5" "anyone lrs" -S: U01 OK "Streaming Begins" -<some time goes by, and another client creates a new mailbox> -S: U01 RESERVE "user.leg.new" "mail2.example.org!u1" -<some more time passes, and the create succeeds> -S: U01 MAILBOX "user.leg.new" "mail2.example.org!u1" "leg lrswipcda" -<much more time passes, and the slave decides to send a NOOP to reset -its inactivity timer> -C: N01 NOOP -S: U01 DELETE "user.leg.new" -S: N01 OK "NOOP Complete" - -5. MUPDATE Formal Syntax - - The following syntax specification uses the Augmented Backus-Naur - Form (ABNF) notation as specified in [ABNF]. This uses the ABNF core - rules as specified in Appendix A of [ABNF]. - - Except as noted otherwise, all alphabetic characters are case- - insensitive. The use of upper or lower case characters to define - token strings is for editorial clarity only. Implementations MUST - accept these strings in a case-insensitive fashion. - - Note that this specification also uses some terminals from section 8 - of [ACAP]. - - cmd-activate = "ACTIVATE" SP string SP string SP string - - cmd-authenticate = "AUTHENTICATE" SP sasl-mech [ SP string ] - - - -Siemborski Experimental [Page 12] - -RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003 - - - cmd-delete = "DELETE" SP string - - cmd-find = "FIND" SP string - - cmd-list = "LIST" [ SP string ] - - cmd-logout = "LOGOUT" - - cmd-noop = "NOOP" - - cmd-reserve = "RESERVE" SP string SP string - - cmd-starttls = "STARTTLS" - - cmd-update = "UPDATE" - - command = tag SP command-type CRLF - - command-type = cmd-activate / cmd-authenticate / cmd-delete / - cmd-find / cmd-list / cmd-logout / cmd-noop / - cmd-reserve / cmd-starttls / cmd-update - - response = tag SP response-type CRLF - - response-type = rsp-ok / rsp-no / rsp-bad / rsp-bye / rsp-mailbox / - rsp-reserve / rsp-delete - - rsp-bad = "BAD" SP string - - rsp-bye = "BYE" SP string - - rsp-mailbox = "MAILBOX" SP string SP string SP string - - rsp-no = "NO" SP string - - rsp-ok = "OK" SP string - - rsp-reserve = "RESERVE" SP string SP string - - rsp-delete = "DELETE" SP string - - sasl-mech = 1*ATOM-CHAR - ; ATOM-CHAR is defined in [ACAP] - - string = quoted / literal - ; quoted and literal are defined in [ACAP] - - - - - -Siemborski Experimental [Page 13] - -RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003 - - - tag = 1*ATOM-CHAR - ; ATOM-CHAR is defined in [ACAP] - -6. MUPDATE URL Scheme - - This document defines the a URL scheme for the purposes of - referencing MUPDATE resources, according to the requirements in - [RFC2717]. This includes both MUPDATE servers as a whole, along with - individual mailbox entries on a given MUPDATE server. - - There is no MIME type associated with these resources. It is - intended that a URL consumer would either retrieve the MUPDATE record - in question, or simply connect to the MUPDATE server running on the - specified host. Note that the consumer will need to have - authentication credentials for the specified host. - - The MUPDATE URL scheme is similar to the IMAP URL scheme [IMAP-URL]. - However, it only takes one of two possible forms: - - mupdate://<iserver>/ - mupdate://<iserver>/<mailbox> - - The first form refers to a MUPDATE server as a whole, the second form - indicates both the server and a mailbox to run a FIND against once - authenticated to the server. Note that part of <iserver> may include - username and authentication information along with a hostname and - port. - -6.1. MUPDATE URL Scheme Registration Form - - URL scheme name: "mupdate" - - URL scheme syntax: - - This defines the MUPDATE URL Scheme in [ABNF]. Terminals from the - BNF of IMAP URLs [IMAP-URL] are also used. - - mupdateurl = "mupdate://" iserver "/" [ enc_mailbox ] - ; iserver and enc_mailbox are as defined in [IMAP-URL] - - Character encoding considerations: - - Identical to those described in [IMAP-URL] for the appropriate - terminals. - - - - - - - -Siemborski Experimental [Page 14] - -RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003 - - - Intended Usage: - - The form of the URL without an associated mailbox is intended to - designate a MUPDATE server only. If a mailbox name is included in - the URL, then the consumer is expected to execute a FIND command - for that mailbox on the specified server. - - Applications and/or protocols which use this URL scheme name: - - The protocol described in this document. - - Interoperability Considerations: - - None. - - Security Considerations: - - Users of the MUPDATE URL Scheme should review the security - considerations that are discussed in [IMAP-URL]. In particular, - the consequences of including authentication mechanism information - in a URL should be reviewed. - - Relevant Publications: - - This document and [IMAP-URL]. - - Author, Change Controller, and Contact for Further Information: - - Author of this document. - -7. Security Considerations - - While no unauthenticated users may make modifications or even perform - searches on the database, it is important to note that this - specification assumes no protections of any type for authenticated - users. - - All authenticated users have complete access to the database. For - this reason it is important to ensure that accounts that are making - use of the database are well secured. - - A more secure deployment might have all read only access go through a - slave, and only have accounts which need write access use the master. - This has the disadvantage of a marginally longer time for updates to - reach the clients. - - - - - - -Siemborski Experimental [Page 15] - -RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003 - - - The protocol assumes that all authenticated users are cooperating to - maintain atomic operations. Therefore, all new mailboxes SHOULD be - RESERVEd before they are ACTIVATEd, despite the fact that the - protocol does not require this, and it is therefore possible for a - set of participants which do not obey the provided locking to create - an inconsistent database. RESERVEing the mailbox first is not - required to perform an activate because this behavior simplifies - synchronization with the actual location of the mailboxes. - -8. IANA Considerations - - The IANA has assigned TCP port number 3905 to "mupdate". - - The IANA has registered a URL scheme for the MUPDATE protocol, as - defined in section 6.1 of this document. - - IANA has registered a GSSAPI service name of "mupdate" for the - MUPDATE protocol in the registry maintained at: - - http://www.iana.org/assignments/gssapi-service-names - -9. Intellectual Property Rights - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - - - - - - - - -Siemborski Experimental [Page 16] - -RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003 - - -10. References - -10.1. Normative References - - [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [IMAP] Crispin, M., "Internet Message Access Protocol - Version - 4", RFC 3501, March 2003. - - [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for - Syntax Specifications: ABNF", RFC 2234, November 1997. - - [MIME] Freed, N. and N. Bornstein, "Multipurpose Internet Mail - Extensions (MIME) Part One: Format of Internet Message - Bodies", RFC 2045, November 1996. - - [IMAP-ACL] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997. - - [SASL] Myers, J., "Simple Authentication and Security Layer - (SASL)", RFC 2222, October 1997. - - [IMAP-URL] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997. - - [ACAP] Newman, C. and J. Myers, "ACAP -- Application - Configuration Access Protocol", RFC 2244, November 1997. - - [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", - RFC 2246, January 1999. - -10.2. Informative References - - [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version - 3", STD 53, RFC 1939, May 1996. - - [RFC2717] Petke, R. and I. King, "Registration Procedures for URL - Scheme Names", BCP 35, RFC 2717, November 1999. - - - - - - - - - - - - - - -Siemborski Experimental [Page 17] - -RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003 - - -11. Acknowledgments - - Lawrence Greenfield and Ken Murchison, for a great deal of input on - both the protocol and the text of the documents. - -12. Author's Address - - Robert Siemborski - Carnegie Mellon, Andrew Systems Group - Cyert Hall 207 - 5000 Forbes Avenue - Pittsburgh, PA 15213 - - Phone: (412) 268-7456 - EMail: rjs3+@andrew.cmu.edu - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Siemborski Experimental [Page 18] - -RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003 - - -13. Full Copyright Statement - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Siemborski Experimental [Page 19] - |