Network Working Group R. Siemborski
Request for Comments: 3656 Carnegie Mellon University
Category: Experimental December 2003
Network Working Group R. Siemborski
Request for Comments: 3656 Carnegie Mellon University
Category: Experimental December 2003
The Mailbox Update (MUPDATE) Distributed Mailbox Database Protocol
邮箱更新（MUPDATE）分布式邮箱数据库协议
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.
版权所有（C）互联网协会（2003年）。版权所有。
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.
邮箱更新（MUPDATE）协议允许一组Internet邮件访问协议（IMAP）或邮局协议版本3（POP3）服务器与统一的邮箱命名空间一起工作。本文件旨在作为该议定书的参考指南。
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
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
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.
为了支持多台[IMAP，POP3]服务器共享一个公共邮箱数据库的体系结构，必须能够提供原子邮箱操作，并提供足够的数据库一致性保证。
The primary goal of the MUPDATE protocol is to be simple to implement yet allow for database consistency between participants.
MUPDATE协议的主要目标是实现简单，同时允许参与者之间的数据库一致性。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应该”、“不应该”、“建议”和“可能”应按照BCP 14、RFC 2119[关键词]中的定义进行解释。
In examples, "C:" and "S:" indicate lines sent by the client and server respectively.
在示例中，“C:”和“S:”分别表示客户端和服务器发送的行。
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.
MUPDATE协议假定有可靠的数据流，如TCP网络连接。IANA已为此注册了短名称为“mupdate”的端口3905。
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.
在MUPDATE协议的当前实现中，有三种类型的参与者：单个主服务器、从属（或副本）服务器和客户端。主服务器维护邮箱数据库的权威副本。从服务器作为客户端连接到MUPDATE主服务器，并从终端客户端的角度作为副本运行。终端客户端可以连接到主服务器或任何从服务器，并对数据库执行搜索，但是更改数据库的操作只能对主服务器执行。出于协议讨论的目的，我们将考虑一个从主机到任何其他客户端的连接。
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.
如果服务器支持非活动登录超时，则该超时必须至少为15分钟。
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.
MUPDATE使用与[ACAP]中使用的数据格式类似的数据格式。也就是说，原子和弦。协议中的所有命令和标签都作为原子传输。所有其他数据都被视为一个字符串，必须作为文本引用或传输。
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.
在文本之外，客户端和服务器都必须支持至少1024个八位字节的行长（包括尾部的CR和LF字符）。如果必须传输较长的行，则实现必须使用文字来传输。
An atom consists of one or more alphanumeric characters. Atoms MUST be less than 15 octets in length.
原子由一个或多个字母数字字符组成。原子长度必须小于15个八位组。
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.
与[ACAP]中一样，字符串可以是文字或带引号的字符串。文字是由零个或多个八位字节（包括CR和LF）组成的序列，前缀以开括号（“{”）的形式引用八位字节计数，八位字节数，可选加号表示数据立即跟随（非同步文字），闭括号（“}”）和CRLF序列。如果省略了加号（同步文字），则接收方必须发送“+继续”响应，并且发送端必须等待该响应。服务器必须支持至少4096个八位字节的文本。
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.
带引号的字符串是由零个或多个7位字符组成的序列，不包括CR、LF和双引号（<“>），每端都有双引号字符。
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).
空字符串表示为“”（双引号之间为零个字符的带引号字符串）或{0}后跟CRLF（八位字节计数为0的文本）。
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.
MUPDATE协议中的每个客户端命令都可以从服务器接收一个或多个标记响应。每个响应前面都有与从服务器获取响应的命令相同的标记。
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.
标记的OK响应表示操作已成功完成。在OK响应之后有一个强制实现定义的字符串。当响应更新命令时，此响应还指示流式更新模式的开始。
Example:
例子：
C: N01 NOOP
S: N01 OK "NOOP Complete"
C: N01 NOOP
S: N01 OK "NOOP Complete"
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.
标记的“无”响应表示操作被服务器明确拒绝或以其他方式失败。在NO响应之后有一个强制实现定义的字符串，它应该解释拒绝的原因。
Example:
例子：
C: A01 AUTHENTICATE "PLAIN"
S: A01 NO "PLAIN is not a supported SASL mechanism"
C: A01 AUTHENTICATE "PLAIN"
S: A01 NO "PLAIN is not a supported SASL mechanism"
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 "*".
标记的错误响应表示无法解析或理解来自客户端的命令。错误响应后有一个强制实现定义的字符串，用于提供有关错误的其他信息。请注意，如果不清楚给定命令的标记是什么，则允许使用未标记的错误响应（例如，如果mupdate服务器接收到一个空行，则可能会生成未标记的错误响应）。如果是未标记的响应，则标记应替换为“*”。
Example:
例子：
C: C01 SELECT "INBOX"
S: C01 BAD "This is not an IMAP server"
C:
S: * BAD "Need Command"
C: C01 SELECT "INBOX"
S: C01 BAD "This is not an IMAP server"
C:
S: * BAD "Need Command"
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.
标记的BYE响应表示服务器已决定关闭连接。BYE响应后有一个强制实现定义的字符串，它应该解释关闭连接的原因。服务器必须在发送BYE响应后立即关闭连接。
Example:
例子：
C: L01 LOGOUT
S: L01 BYE "User Logged Out"
C: L01 LOGOUT
S: L01 BYE "User Logged Out"
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.
标记的保留响应只能作为对FIND、LIST或UPDATE命令的响应。它包括两个参数：被保留邮箱的名称（采用mUTF-7编码，如[IMAP]中所述）和一个位置字符串，其内容由使用数据库的客户端定义，但建议该字符串的格式为存储邮箱的服务器的主机名。
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"
S:U01保留“internet.bugtraq”“mail2.example.org”
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.
标记的邮箱响应只能作为对FIND、LIST或UPDATE命令的响应。它包括三个参数：邮箱名称、位置字符串（与保留相同）和指定邮箱IMAP ACL[IMAP-ACL]的客户端定义字符串。此消息表示给定邮箱已准备好供客户端访问。
Example:
例子：
S: U01 MAILBOX "internet.bugtraq" "mail2.example.org" "anyone rls"
S:U01邮箱“internet.bugtraq”“mail2.example.org”“任何人rls”
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).
标记的删除响应只能响应UPDATE命令，在对UPDATE命令做出OK响应之前不得给出。它包含一个参数，即应该从从属数据库中删除的邮箱的参数。此响应表示给定邮箱在数据库的命名空间中不再存在，并且可以为任何邮箱名称（活动、保留或不存在）提供该邮箱。（尽管实现不应该对不存在的邮箱发出删除响应）。
Example:
例子：
S: U01 DELETE "user.rjs3.sent-mail-jan-2002"
S:U01删除“user.rjs3.sent-mail-jan-2002”
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:
将客户端连接到服务器后，并在成功执行STARTTLS命令后，服务器必须发出以下格式的功能横幅：
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.
横幅必须包含以“*AUTH”开头的行，并包含服务器将接受用于身份验证的SASL机制的空格分隔列表。机制名称以原子形式传输。服务器可能不会公布任何可用的机制（以表明必须先完成STARTTLS，然后才能进行身份验证）。如果服务器不支持STARTTLS，则该行必须至少包含一种机制。
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.
如果发布的横幅没有TLS层，并且服务器支持STARTTLS命令，则横幅必须包含行“*STARTTLS”。如果在TLS层下发布横幅（或服务器不支持STARTTLS），则横幅不得包含此行。
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.
横幅的最后一行必须以“*OK MUPDATE”开头，后跟四个字符串：服务器的主机名、提供实现名称的实现定义字符串、提供实现版本的实现定义字符串，以及指示服务器是主服务器还是从服务器的字符串。主/从指示必须是“（主）”或定义可以联系主设备的MUPDATE URL。
Any unrecognized responses before the "* OK MUPDATE" response MUST be ignored by the client.
客户端必须忽略“*OK MUPDATE”响应之前的任何无法识别的响应。
Example:
例子：
S: * AUTH KERBEROS_V4 GSSAPI
S: * STARTTLS
S: * OK MUPDATE "mupdate.example.org" "Cyrus" "v2.1.2" "(master)"
S: * AUTH KERBEROS_V4 GSSAPI
S: * STARTTLS
S: * OK MUPDATE "mupdate.example.org" "Cyrus" "v2.1.2" "(master)"
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.
以下是客户端可以发送到MUPDATE服务器的有效命令：身份验证、激活、停用、删除、查找、列出、注销、NOOP、RESERVE、STARTTLS和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).
在成功执行身份验证命令之前，服务器不得接受除AUTHENTICATE、STARTTLS和LOGOUT之外的任何命令（并且应以不响应所有其他命令的方式进行响应）。
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.
ACTIVATE命令有3个参数：邮箱名称、位置和ACL。不得向从属服务器发出此命令。
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.
此命令还可用于更新邮箱的ACL或位置信息。请注意，要使ACTIVATE命令成功，不需要保留邮箱（甚至不需要存在于数据库中），实现必须允许此行为，因为它有助于数据库与邮箱的当前状态同步。
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.
AUTHENTICATE命令启动客户端和服务器之间的[SASL]协商会话。它有两个参数。第一个参数是必需的，是一个字符串，指示所需的[SASL]机制。第二个字符串包含可选的BASE64编码（如[MIME]第6.8节所定义）客户端首次发送。
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.
发送的所有剩余SASL BLOB必须以BASE64编码格式通过线路发送，后跟CR和LF组合。它们不能被编码为字符串。
Clients may cancel authentication by sending a * followed by a CR and LF.
客户端可以通过发送*并后跟CR和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.
MUPDATE协议的[SASL]服务名称为“MUPDATE”。实现GSSAPI[SASL]机制需要实现，尽管它们应该实现尽可能多的机制。
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.
如果协商了安全层，则应在服务器的OK响应结束时（即，从客户端的下一个命令开始），在CR和LF组合之后直接使用该层。每个会话只能发出一个成功的AUTHENTICATE命令。
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.
DEACTIVATE命令接受两个参数，邮箱名称和位置数据。邮箱必须已存在，并且已在MUPDATE服务器上激活。如果服务器响应正常，则邮箱名称已移动到保留状态。如果服务器响应“否”，则邮箱名称尚未移动（例如，邮箱尚未处于活动状态）。当停用成功时，任何已知的有关邮箱的ACL信息都可能丢失。不得将此命令发送给从属设备。
Example:
例子：
C: A01 DEACTIVATE "user.rjs3.new" "mail3.example.org!u4"
S: A01 OK "Mailbox Reserved."
C: A01 DEACTIVATE "user.rjs3.new" "mail3.example.org!u4"
S: A01 OK "Mailbox Reserved."
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.
DELETE命令只接受一个参数，即要从数据库命名空间中删除的邮箱名称。如果邮箱不存在，服务器应不响应。不得向从属服务器发出此命令。
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.
FIND命令只接受一个参数，即邮箱名称。然后，服务器使用给定邮箱的当前记录（如果有）和OK响应进行响应。
Example (mailbox does not exist):
示例（邮箱不存在）：
C: F01 FIND "user.rjs3.xyzzy"
S: F01 OK "Search Complete"
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"
C: F01 FIND "user.rjs3"
S: F01 RESERVE "user.rjs3" "mail4.example.org"
S: F01 OK "Search Complete"
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.
LIST命令类似于在整个数据库中运行FIND。LIST命令接受一个可选参数，该参数是一个前缀，用于尝试与记录的位置字段进行匹配。如果没有参数，LIST将返回数据库中的每条记录。
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.
对于每个匹配的邮箱，将向客户端发送邮箱或保留响应（如适用）。当所有响应完成时，发出OK响应。
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"
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"
The LOGOUT command tells the server to close the connection. Its only valid response is the BYE response. The LOGOUT command takes no parameters.
LOGOUT命令告诉服务器关闭连接。它唯一有效的响应是BYE响应。注销命令不接受任何参数。
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.
NOOP命令不接受任何参数。如果客户机经过身份验证，则其唯一可接受的响应是OK。服务器在连接上可能出现的任何空闲超时都应在收到此命令后重置。
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.
如果此命令是在发出UPDATE命令之后发出的，则OK响应还指示所有挂起的数据库更新都已发送到客户端。也就是说，通过发出NOOP并等待OK，从机可以保证其本地数据库在某个时间是最新的。在发送NOOP时挂起的所有更新之前，OK不能返回。
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
RESERVE命令接受两个参数（就像RESERVE响应一样），即要保留的邮箱名称和位置数据。如果服务器响应正常，则邮箱名称已被保留。如果服务器响应“否”，则未保留邮箱名称（对于
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."
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."
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.
STARTTLS命令请求开始[TLS]协商。协商在确认响应中的CRLF之后立即开始。客户机发出STARTTLS命令后，在看到服务器响应且[TLS]协商完成之前，不得发出进一步的命令。
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.
STARTTLS命令仅在未经身份验证的状态下有效。即使在[TLS]协商期间提供了客户端凭据，服务器仍保持未经身份验证的状态。[SASL]外部机制可用于在成功交换[TLS]客户端凭据后进行身份验证。请注意，不需要服务器来支持外部机制。
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.
[TLS]层建立后，服务器必须重新发布初始响应横幅（见第3.8节）。这对于防止中间人攻击是必要的，因为中间人攻击会改变STARTTLS之前的功能列表，以及宣传该层下可用的任何新SASL机制（或其他功能）。客户端必须丢弃缓存的功能信息，并用新信息替换它。
After the a successful STARTTLS command, the server SHOULD return a NO response to additional STARTTLS commands.
成功执行STARTTLS命令后，服务器应返回对其他STARTTLS命令的NO响应。
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.
服务器可以选择不实现STARTTLS。在这种情况下，他们不得在其能力横幅中公布STARTTLS，如果发出STARTTLS命令，则应向其返回错误响应。
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)"
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)"
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.
UPDATE命令是从机初始化来自主机的更新流的方式（尽管向从机发出此命令也是有效的）。作为对该命令的响应，服务器返回其数据库中所有邮箱的列表（与无参数列表命令的结果相同），然后返回OK响应。从这一点开始，每当主数据库发生更新时，它必须在30秒内将更新流式传输到从数据库。也就是说，它将发送适用的保留、邮箱或删除响应。
After a client has issued an UPDATE command, it may only issue NOOP and LOGOUT commands for the remainder of the session.
客户端发出更新命令后，它只能在会话的其余部分发出NOOP和LOGOUT命令。
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"
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"
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].
以下语法规范使用[ABNF]中指定的增广Backus Naur Form（ABNF）表示法。这使用了[ABNF]附录A中规定的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].
请注意，本规范还使用了[ACAP]第8节中的一些端子。
cmd-activate = "ACTIVATE" SP string SP string SP string
cmd activate=“activate”SP string SP string SP string
cmd-authenticate = "AUTHENTICATE" SP sasl-mech [ SP string ]
cmd authenticate=“authenticate”SP sasl机械[SP字符串]
cmd-delete = "DELETE" SP string
cmd delete=“delete”SP字符串
cmd-find = "FIND" SP string
cmd find=“find”SP字符串
cmd-list = "LIST" [ SP string ]
cmd list=“list”[SP string]
cmd-logout = "LOGOUT"
cmd-logout = "LOGOUT"
cmd-noop = "NOOP"
cmd-noop = "NOOP"
cmd-reserve = "RESERVE" SP string SP string
cmd reserve=“reserve”SP string SP string
cmd-starttls = "STARTTLS"
cmd-starttls = "STARTTLS"
cmd-update = "UPDATE"
cmd-update = "UPDATE"
command = tag SP command-type CRLF
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
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 = tag SP response-type CRLF
response-type = rsp-ok / rsp-no / rsp-bad / rsp-bye / rsp-mailbox /
rsp-reserve / rsp-delete
response-type = rsp-ok / rsp-no / rsp-bad / rsp-bye / rsp-mailbox /
rsp-reserve / rsp-delete
rsp-bad = "BAD" SP string
rsp bad=“bad”SP字符串
rsp-bye = "BYE" SP string
rsp bye=“bye”SP字符串
rsp-mailbox = "MAILBOX" SP string SP string SP string
rsp mailbox=“mailbox”SP string SP string
rsp-no = "NO" SP string
rsp no=“no”SP字符串
rsp-ok = "OK" SP string
rsp ok=“ok”SP字符串
rsp-reserve = "RESERVE" SP string SP string
rsp reserve=“reserve”SP string SP string
rsp-delete = "DELETE" SP string
rsp delete=“delete”SP字符串
sasl-mech = 1*ATOM-CHAR
; ATOM-CHAR is defined in [ACAP]
sasl-mech = 1*ATOM-CHAR
; ATOM-CHAR is defined in [ACAP]
string = quoted / literal ; quoted and literal are defined in [ACAP]
字符串=引用/文字；引用和文字在[ACAP]中定义
tag = 1*ATOM-CHAR
; ATOM-CHAR is defined in [ACAP]
tag = 1*ATOM-CHAR
; ATOM-CHAR is defined in [ACAP]
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.
本文档根据[RFC2717]中的要求，定义了用于引用MUPDATE资源的URL方案。这包括作为一个整体的MUPDATE服务器，以及给定MUPDATE服务器上的单个邮箱条目。
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.
没有与这些资源关联的MIME类型。URL使用者可以检索有问题的MUPDATE记录，也可以直接连接到指定主机上运行的MUPDATE服务器。请注意，使用者需要具有指定主机的身份验证凭据。
The MUPDATE URL scheme is similar to the IMAP URL scheme [IMAP-URL]. However, it only takes one of two possible forms:
MUPDATE URL方案类似于IMAP URL方案[IMAP-URL]。但是，它仅采用两种可能形式中的一种：
mupdate://<iserver>/
mupdate://<iserver>/<mailbox>
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.
第一种形式是指作为一个整体的MUPDATE服务器，第二种形式是指服务器和邮箱，一旦对服务器进行了身份验证，就可以运行查找。请注意，<iserver>的一部分可能包括用户名和身份验证信息以及主机名和端口。
URL scheme name: "mupdate"
URL方案名称：“mupdate”
URL scheme syntax:
URL方案语法：
This defines the MUPDATE URL Scheme in [ABNF]. Terminals from the BNF of IMAP URLs [IMAP-URL] are also used.
这在[ABNF]中定义了MUPDATE URL方案。还使用来自IMAP URL[IMAP-URL]的BNF的终端。
mupdateurl = "mupdate://" iserver "/" [ enc_mailbox ]
; iserver and enc_mailbox are as defined in [IMAP-URL]
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.
与[IMAP-URL]中描述的相应终端相同。
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.
没有关联邮箱的URL形式仅用于指定MUPDATE服务器。如果URL中包含邮箱名称，则使用者应在指定服务器上为该邮箱执行查找命令。
Applications and/or protocols which use this URL scheme name:
使用此URL方案名称的应用程序和/或协议：
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.
MUPDATE URL方案的用户应查看[IMAP-URL]中讨论的安全注意事项。特别是，应审查在URL中包含身份验证机制信息的后果。
Relevant Publications:
相关出版物：
This document and [IMAP-URL].
此文档和[IMAP-URL]。
Author, Change Controller, and Contact for Further Information:
作者、变更控制者和联系人了解更多信息：
Author of this document.
本文件的作者。
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.
更安全的部署可能使所有只读访问都通过从机，并且只有需要写访问的帐户才能使用主机。这样做的缺点是更新到达客户端的时间稍长。
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.
该协议假设所有经过身份验证的用户都在合作维护原子操作。因此，所有新邮箱都应在激活之前保留，尽管协议不要求这样做，因此，不遵守提供的锁定的一组参与者可能会创建不一致的数据库。执行激活不需要先保留邮箱，因为此行为简化了与邮箱实际位置的同步。
The IANA has assigned TCP port number 3905 to "mupdate".
IANA已将TCP端口号3905分配给“mupdate”。
The IANA has registered a URL scheme for the MUPDATE protocol, as defined in section 6.1 of this document.
IANA已为MUPDATE协议注册了URL方案，如本文件第6.1节所定义。
IANA has registered a GSSAPI service name of "mupdate" for the MUPDATE protocol in the registry maintained at:
IANA已在注册表中为mupdate协议注册了GSSAPI服务名称“mupdate”，注册地址为：
http://www.iana.org/assignments/gssapi-service-names
http://www.iana.org/assignments/gssapi-service-names
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[IMAP] Crispin, M., "Internet Message Access Protocol - Version 4", RFC 3501, March 2003.
[IMAP]Crispin，M.，“互联网消息访问协议-第4版”，RFC 35012003年3月。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[MIME] Freed, N. and N. Bornstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME]Freed，N.和N.Bornstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[IMAP-ACL] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997.
[IMAP-ACL]迈尔斯，J.，“IMAP4 ACL扩展”，RFC 2086，1997年1月。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL]迈尔斯，J.，“简单认证和安全层（SASL）”，RFC22221997年10月。
[IMAP-URL] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
[IMAP-URL]纽曼，C.，“IMAP URL方案”，RFC 2192192191997年9月。
[ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[ACAP]Newman，C.和J.Myers，“ACAP——应用程序配置访问协议”，RFC22441997年11月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC 2246，1999年1月。
[POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[POP3]迈尔斯，J.和M.罗斯，“邮局协议-第3版”，STD 53，RFC 1939，1996年5月。
[RFC2717] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", BCP 35, RFC 2717, November 1999.
[RFC2717]Petke，R.和I.King，“URL方案名称的注册程序”，BCP 35，RFC 2717，1999年11月。
Lawrence Greenfield and Ken Murchison, for a great deal of input on both the protocol and the text of the documents.
劳伦斯·格林菲尔德（Lawrence Greenfield）和肯·默奇森（Ken Murchison）就协议和文件文本提供了大量意见。
Robert Siemborski Carnegie Mellon, Andrew Systems Group Cyert Hall 207 5000 Forbes Avenue Pittsburgh, PA 15213
罗伯特·西姆博斯基·卡内基·梅隆，安德鲁系统集团塞尔特大厅207号，美国宾夕法尼亚州匹兹堡福布斯大道5000号，邮编15213
Phone: (412) 268-7456
EMail: rjs3+@andrew.cmu.edu
Phone: (412) 268-7456
EMail: rjs3+@andrew.cmu.edu
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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.
RFC编辑功能的资金目前由互联网协会提供。