summaryrefslogtreecommitdiff
path: root/imap/docs/rfc/rfc3656.txt
diff options
context:
space:
mode:
authorEduardo Chappa <chappa@washington.edu>2013-06-03 10:30:56 -0600
committerEduardo Chappa <chappa@washington.edu>2013-06-03 10:30:56 -0600
commite4b35478c8b3ce7352a74b2fea0e067f068daf18 (patch)
tree0b8a97debddc8210c6696c252c26f03703b606fa /imap/docs/rfc/rfc3656.txt
parenta46157ba61f2c65f88b42abb31db60c4a714f87b (diff)
downloadalpine-e4b35478c8b3ce7352a74b2fea0e067f068daf18.tar.xz
* 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
Diffstat (limited to 'imap/docs/rfc/rfc3656.txt')
-rw-r--r--imap/docs/rfc/rfc3656.txt1067
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]
-