The Mailbox Update (MUPDATE) Distributed Mailbox Database Protocol
draft-siemborski-mupdate-04

Network Working Group                                  Robert Siemborski
INTERNET-DRAFT                                Carnegie Mellon University
Intended Category: Experimental                                May, 2003

           The MUPDATE Distributed Mailbox Database Protocol

                   <draft-siemborski-mupdate-04.txt>

Status of this Memo
    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC2026.

    Internet-Drafts are working documents of the Internet Task Force
    (IETF), its areas, and its working groups.  Note that other groups
    may also distribute working documents as Internet-Drafts.

    Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other documents
    at any time.  It is inappropriate to use Internet Drafts as
    reference material or to cite them other than as "work in progress."

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.

    Distribution of this memo is unlimited.

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 IMAP (or
    POP3) servers to function with a unified mailbox namespace.  This
    document is intended to serve as a reference guide to that protocol.

    Please note that this specification is provided to give information
    to the Internet community; it is anticipated that it would need to
    be revised before widespread adaption.

Siemborski               Expires November, 2003                 [Page 1]

The MUPDATE Protocol                                           May, 2003

                           Table of Contents

1. Changes Since -03 . . . . . . . . . . . . . . . . . . . . . . . .   3
2. Changes Since -02 . . . . . . . . . . . . . . . . . . . . . . . .   3
3. Changes Since -01 . . . . . . . . . . . . . . . . . . . . . . . .   3
4. Changes Since -00 . . . . . . . . . . . . . . . . . . . . . . . .   3
5. How to Read This Document . . . . . . . . . . . . . . . . . . . .   3
6. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
7. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . .   4
7.1. Atoms . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
7.2. Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
8. Server Responses  . . . . . . . . . . . . . . . . . . . . . . . .   5
8.1. Response: OK  . . . . . . . . . . . . . . . . . . . . . . . . .   5
8.2. Response: NO  . . . . . . . . . . . . . . . . . . . . . . . . .   5
8.3. Response: BAD . . . . . . . . . . . . . . . . . . . . . . . . .   6
8.4. Response: BYES  . . . . . . . . . . . . . . . . . . . . . . . .   6
8.5. Response: RESERVE . . . . . . . . . . . . . . . . . . . . . . .   6
8.6. Response: MAILBOX . . . . . . . . . . . . . . . . . . . . . . .   7
8.7. Response: DELETE  . . . . . . . . . . . . . . . . . . . . . . .   7
8.8. Server Capability Response  . . . . . . . . . . . . . . . . . .   8
9. Client Commands . . . . . . . . . . . . . . . . . . . . . . . . .   9
9.1. Command: ACTIVATE . . . . . . . . . . . . . . . . . . . . . . .   9
9.2. Command: AUTHENTICATE . . . . . . . . . . . . . . . . . . . . .   9
9.3. Command: DEACTIVATE . . . . . . . . . . . . . . . . . . . . . .  10
9.4. Command: DELETE . . . . . . . . . . . . . . . . . . . . . . . .  10
9.5. Command: FIND . . . . . . . . . . . . . . . . . . . . . . . . .  10
9.6. Command: LIST . . . . . . . . . . . . . . . . . . . . . . . . .  11
9.7. Command: LOGOUT . . . . . . . . . . . . . . . . . . . . . . . .  11
9.8. Command: NOOP . . . . . . . . . . . . . . . . . . . . . . . . .  11
9.9. Command: RESERVE  . . . . . . . . . . . . . . . . . . . . . . .  12
9.10. Command: STARTTLS  . . . . . . . . . . . . . . . . . . . . . .  12
9.11. Command: UPDATE  . . . . . . . . . . . . . . . . . . . . . . .  13
10. MUPDATE Formal Syntax  . . . . . . . . . . . . . . . . . . . . .  13
11. MUPDATE URL Scheme . . . . . . . . . . . . . . . . . . . . . . .  15
11.1. MUPDATE URL Scheme Registration Form . . . . . . . . . . . . .  15
12. Security Considerations  . . . . . . . . . . . . . . . . . . . .  17
13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . .  17
14. Intellectual Property Rights . . . . . . . . . . . . . . . . . .  17
15. Copyright  . . . . . . . . . . . . . . . . . . . . . . . . . . .  18
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . .  18
17. Author's Address . . . . . . . . . . . . . . . . . . . . . . . .  19
18. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . .  20

Siemborski               Expires November, 2003                 [Page 1]

The MUPDATE Protocol                                           May, 2003

1.  Changes Since -03 (RFC Editor: Remove Before Publication)

     1.   Correct registration of URL scheme to confirm with RFC2717.

     2.   Add maximums for line length, atom size, literal size, and
          minimum time before an update is pushed to the client.

     3.   Add a minimum idle timeout.

     4.   Add IPR Boilerplate

2.  Changes Since -02 (RFC Editor: Remove Before Publication)

     1.   Add STARTTLS Command

3.  Changes Since -01 (RFC Editor: Remove Before Publication)

     1.   Add IANA considerations section requesting a TCP port number.

     2.   Split references into normative/informative.

4.  Changes Since -00 (RFC Editor: Remove Before Publication)

     1.   Added required-to-implement SASL mechanism: GSSAPI.

     2.   Slight wording change in Server Initial Response section.

     3.   Allow untagged BAD responses.

5.  How to Read This Document

    The key words "MUST, "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
    "RECOMMENDED", and "MAY" in this document are to be interpreted as
    defined in "Key words for use in RFCs to Indicate Requirement Lev-
    els" [KEYWORDS]

    In examples, "C:" and "S:" indicate lines sent by the client and
    server respectively.

6.  Introduction

    In order to support an architecture where there are multiple [IMAP]
    servers sharing a common mailbox database, it is necessary to be
    able to provide atomic mailbox operations, as well as offer suffi-
    cient guarantees about database consistency.

    The primary goal of the MUPDATE protocol is to be simple to imple-
    ment yet allow for database consistency between participants.

Siemborski               Expires November, 2003                 [Page 3]

The MUPDATE Protocol                                           May, 2003

7.  Protocol Overview

    The MUPDATE protocol assumes a reliable data stream such as a TCP
    network connection.  This document requests that the IANA register a
    TCP port number with the short name of "mupdate" for this purpose.
    Current implementations are using port 2004.

    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 discus-
    sion 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
    atleast 15 minutes.

    MUPDATE uses data formats similar to those used in [ACAP]. That is,
    atoms and strings.  All commands and tags in the protocol are trans-
    mitted 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 atleast 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.

7.1.  Atoms

    An atom consists of one or more alphanumeric characters.  Atoms MUST
    be less than 15 octets in length.

7.2.  Strings

    As in [ACAP], a string may be either literal or a quoted string.

Siemborski               Expires November, 2003                 [Page 4]

The MUPDATE Protocol                                           May, 2003

    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).

8.  Server Responses

    Every client command in the MUPDATE protocol may receive one or more
    tagged responses from the server.  Each response is preceeded by the
    same tag as the command that elicited the response from the server.

8.1.  Response: OK

    A tagged OK response indicates that the operation completed success-
    fully.  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"

Siemborski               Expires November, 2003                 [Page 5]

The MUPDATE Protocol                                           May, 2003

8.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"

8.3.  Response: BAD

    A tagged BAD response indicates that the command from the client
    could not be parsed or understood.  There is a mandatory implementa-
    tion-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"

8.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 bad 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"

Siemborski               Expires November, 2003                 [Page 6]

The MUPDATE Protocol                                           May, 2003

8.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.andrew.cmu.edu"

8.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 that is currently reserved, 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.andrew.cmu.edu" "anyone rls"

Siemborski               Expires November, 2003                 [Page 7]

The MUPDATE Protocol                                           May, 2003

8.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 mail-
    box 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"

8.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 con-
    tain 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 implementa-
    tion-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               Expires November, 2003                 [Page 8]

The MUPDATE Protocol                                           May, 2003

    Example:

     S: * AUTH KERBEROS_V4 GSSAPI
     S: * STARTTLS
     S: * OK MUPDATE "mupdate.andrew.cmu.edu" "Cyrus" "v2.1.2" "(master)"

9.  Client Commands

    The following are valid commands that a client may send to the MUP-
    DATE 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).

9.1.  Command: ACTIVATE

    The ACTIVATE command has 3 parameters: the mailbox name, its loca-
    tion, 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 informa-
    tion 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 com-
    mand to succeed, implementations MUST allow this behavior as it
    facilitates synchronization of the database with the current state
    of the mailboxes.

9.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]

Siemborski               Expires November, 2003                 [Page 9]

The MUPDATE Protocol                                           May, 2003

    mechanism, though they SHOULD implement as many mechanisms as possi-
    ble.

    If a security layer is negotiated, it should be used directly fol-
    lowing 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.

9.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 mail-
    box was not already active).  Any ACL information that is known
    about the mailbox MAY be lost when a DEACTIVATE succeeds.  This com-
    mand MUST NOT be issued to a slave.

    The typical sequence for mailbox creation is:

     C: R01 ACTIVATE "user.rjs3.new" "mail3.andrew.cmu.edu!u4"
     S: R01 OK "Mailbox Reserved."
     C: A01 DEACTIVATE "user.rjs3.new" "mail3.andrew.cmu.edu!u4"
     S: A01 OK "Mailbox Reserved."

9.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.

9.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"

Siemborski               Expires November, 2003                [Page 10]

The MUPDATE Protocol                                           May, 2003

    Example (mailbox is reserved):

     C: F01 FIND "user.rjs3"
     S: F01 RESERVE "user.rjs3" "mail4.andrew.cmu.edu"
     S: F01 OK "Search Complete"

9.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.andrew.cmu.edu!u2"
     S: L01 MAILBOX "user.leg" "mail2.andrew.cmu.edu!u1" "leg  lrswipcda"
     S: L01 OK "List Complete"
     C: L02 LIST "mail4.andrew.cmu.edu!"
     S: L02 RESERVE "user.rjs3" "mail4.andrew.cmu.edu!u2"
     S: L02 OK "List Complete"

9.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.

9.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 guar-
    antee 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

Siemborski               Expires November, 2003                [Page 11]

The MUPDATE Protocol                                           May, 2003

    all updates that were pending at the time of the NOOP have been
    sent.

9.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
    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.andrew.cmu.edu!u4"
     S: R01 OK "Mailbox Reserved."
     <client does local mailbox create operations>
     C: A01 ACTIVATE "user.rjs3.new" "mail3.andrew.cmu.edu!u4" "rjs3  lrswipcda"
     S: A01 OK "Mailbox Activated."

9.10.  Command: STARTTLS

    The STARTTLS command requests the commencement of a [TLS] negotia-
    tion.  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 creden-
    tials 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 7.8). This is necessary to pro-
    tect against man-in-the-middle attacks which alter the capabilities
    list prior to STARTTLS, as well as to advertise any new SASL mecha-
    nisms (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

Siemborski               Expires November, 2003                [Page 12]

The MUPDATE Protocol                                           May, 2003

    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.andrew.cmu.edu" "Cyrus" "v2.1.2" "(master)"

9.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.andrew.cmu.edu!u1" "leg lrswipcda"
     S: U01 MAILBOX "user.rjs3" "mail3.andrew.cmu.edu!u4" "rjs3  lrswipcda"
     S: U01 RESERVE "internet.bugtraq" "mail1.andrew.cmu.edu!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.andrew.cmu.edu!u1"
     <some more time passes, and the create succeeds>
     S: U01 MAILBOX "user.leg.new" "mail2.andrew.cmu.edu!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"

10.  MUPDATE Formal Syntax

    The following syntax specification uses the Augmented Backus-Naur
    Form (ABNF) notation as specified in [ABNF]. This uses the ABNF core

Siemborski               Expires November, 2003                [Page 13]

The MUPDATE Protocol                                           May, 2003

    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 ]

       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

       rep-bye = "BYE" SP string

       rsp-mailbox = "MAILBOX" SP string SP string SP string

       rsp-no = "NO" SP string

Siemborski               Expires November, 2003                [Page 14]

The MUPDATE Protocol                                           May, 2003

       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]

       tag = 1*ATOM-CHAR
          ; ATOM-CHAR is defined in [ACAP]

11.  MUPDATE URL Scheme

    This document defines the a URL scheme for the purposes of referenc-
    ing 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 host-
    name and port.

Siemborski               Expires November, 2003                [Page 15]

The MUPDATE Protocol                                           May, 2003

11.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.

    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 com-
        mand 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 con-
        siderations that are discussed in [IMAP-URL].  In particular,
        the consequences of including authentication mechanism informa-
        tion 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.

Siemborski               Expires November, 2003                [Page 16]

The MUPDATE Protocol                                           May, 2003

12.  Security Considerations

    While no unauthenticated users may make modifications or even per-
    form 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 mas-
    ter.  This has the disadvantage of a marginally longer time for
    updates to reach the clients.

    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 proto-
    col 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 synchroniza-
    tion with the actual location of the mailboxes.

13.  IANA Considerations

    This document requests that the IANA provide a TCP port number with
    the short name of "mupdate".

    This document requests that the IANA register a URL scheme for the
    MUPDATE protocol, as defined in section 11.1 of this document.

14.  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 per-
    tain 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 pro-
    prietary rights by implementors or users of this specification can
    be obtained from the IETF Secretariat.

Siemborski               Expires November, 2003                [Page 17]

The MUPDATE Protocol                                           May, 2003

    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.

15.  Copyright

    Copyright (C) The Internet Society (2002). 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 devel-
    oping 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.

    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.

Siemborski               Expires November, 2003                [Page 18]

The MUPDATE Protocol                                           May, 2003

16.  References

The following documents contain normative definitions or specifications
that are necessary for correct understanding of this protocol:

[KEYWORDS]  Bradner, S., "Key words for use in RFCs to Indicate Require-
            ment Levels", BCP 14, RFC 2119, March 1997

[IMAP]      Crispin, M., "Internet Message Access Protocol", RFC 2060,
            December 1996.

[ABNF]      Crocker, D., "Augmented BNF for Syntax Specifications:
            ABNF", RFC 2234, November, 1997.

[MIME]      Freed, N. & Bornstein, N., "Multipurpose Internet Mail
            Extentions (MIME) Part One: Format of Internet Message Bod-
            ies", RFC 2045, November 1996.

[IMAP-ACL]  Myers, J., "IMAP4 ACL extention", 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. & Myers, J., "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.

The following references are for informational purposes only:

[POP3]      Myers, J. & Rose, M., "Post Office Protocol - Version 3",
            STD 53, RFC 1939, May 1996.

[RFC2717]   Petke, R. and I. King, "Registration Procedures for URL
            Scheme Names", RFC 2717, November 1999.

Siemborski               Expires November, 2003                [Page 19]

The MUPDATE Protocol                                           May, 2003

17.  Author's  Address:

    Robert Siemborski
    Carnegie Mellon, Andrew Systems Group
    Cyert Hall 207
    5000 Forbes Avenue
    Pittsburgh, PA  15213
    +1 412 268 7456
    rjs3+@andrew.cmu.edu

18.  Acknowledgments:

    Lawrence Greenfield and Ken Murchison, for a great deal of input on
    both the protocol and the text of the drafts.

Siemborski               Expires November, 2003                [Page 20]