path: root/imap/docs/rfc/rfc3656.txt

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]