* Changes to configure.ac to add -lkrb5 to the link

  * Changes to avoud errors in compilation when -Wformat-security is used
  * Remove RFC files from source code

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