Network Working Group A. Melnikov, Ed.
Request for Comments: 5092 Isode Ltd.
Obsoletes: 2192 C. Newman
Updates: 4467 Sun Microsystems
Category: Standards Track November 2007
Network Working Group A. Melnikov, Ed.
Request for Comments: 5092 Isode Ltd.
Obsoletes: 2192 C. Newman
Updates: 4467 Sun Microsystems
Category: Standards Track November 2007
IMAP URL Scheme
IMAP URL方案
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
IMAP (RFC 3501) is a rich protocol for accessing remote message stores. It provides an ideal mechanism for accessing public mailing list archives as well as private and shared message stores. This document defines a URL scheme for referencing objects on an IMAP server.
IMAP（RFC3501）是用于访问远程消息存储的丰富协议。它为访问公共邮件列表存档以及私有和共享邮件存储提供了理想的机制。本文档定义了用于引用IMAP服务器上对象的URL方案。
This document obsoletes RFC 2192. It also updates RFC 4467.
本文件淘汰了RFC 2192。它还更新了RFC4467。
Table of Contents
目录
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. IMAP userinfo Component (iuserinfo) .............................4
3.1. IMAP Mailbox Naming Scope ..................................4
3.2. IMAP User Name and Authentication Mechanism ................4
3.3. Limitations of enc-user ....................................6
4. IMAP Server .....................................................7
5. Lists of Messages ...............................................7
6. A Specific Message or Message Part ..............................8
6.1. URLAUTH Authorized URL .....................................9
6.1.1. Concepts ............................................9
6.1.1.1. URLAUTH ....................................9
6.1.1.2. Mailbox Access Key .........................9
6.1.1.3. Authorized Access Identifier ...............9
6.1.1.4. Authorization Mechanism ...................10
6.1.1.5. Authorization Token .......................10
6.1.2. URLAUTH Extensions to IMAP URL .....................10
7. Relative IMAP URLs .............................................11
7.1. absolute-path References ..................................12
7.2. relative-path References ..................................12
8. Internationalization Considerations ............................13
9. Examples .......................................................13
9.1. Examples of Relative URLs .................................16
10. Security Considerations .......................................16
10.1. Security Considerations Specific to URLAUTH Authorized
URL ......................................................17
11. ABNF for IMAP URL Scheme ......................................17
12. IANA Considerations ...........................................21
12.1. IANA Registration of imap: URI Scheme ....................21
13. References ....................................................22
13.1. Normative References .....................................22
13.2. Informative References ...................................23
Appendix A. Sample Code............................................24
Appendix B. List of Changes since RFC 2192.........................30
Appendix C. List of Changes since RFC 4467.........................31
Appendix D. Acknowledgments........................................31
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. IMAP userinfo Component (iuserinfo) .............................4
3.1. IMAP Mailbox Naming Scope ..................................4
3.2. IMAP User Name and Authentication Mechanism ................4
3.3. Limitations of enc-user ....................................6
4. IMAP Server .....................................................7
5. Lists of Messages ...............................................7
6. A Specific Message or Message Part ..............................8
6.1. URLAUTH Authorized URL .....................................9
6.1.1. Concepts ............................................9
6.1.1.1. URLAUTH ....................................9
6.1.1.2. Mailbox Access Key .........................9
6.1.1.3. Authorized Access Identifier ...............9
6.1.1.4. Authorization Mechanism ...................10
6.1.1.5. Authorization Token .......................10
6.1.2. URLAUTH Extensions to IMAP URL .....................10
7. Relative IMAP URLs .............................................11
7.1. absolute-path References ..................................12
7.2. relative-path References ..................................12
8. Internationalization Considerations ............................13
9. Examples .......................................................13
9.1. Examples of Relative URLs .................................16
10. Security Considerations .......................................16
10.1. Security Considerations Specific to URLAUTH Authorized
URL ......................................................17
11. ABNF for IMAP URL Scheme ......................................17
12. IANA Considerations ...........................................21
12.1. IANA Registration of imap: URI Scheme ....................21
13. References ....................................................22
13.1. Normative References .....................................22
13.2. Informative References ...................................23
Appendix A. Sample Code............................................24
Appendix B. List of Changes since RFC 2192.........................30
Appendix C. List of Changes since RFC 4467.........................31
Appendix D. Acknowledgments........................................31
The IMAP URL scheme is used to designate IMAP servers, mailboxes, messages, MIME bodies [MIME], and search programs on Internet hosts accessible using the IMAP protocol over TCP.
IMAP URL方案用于指定IMAP服务器、邮箱、消息、MIME正文[MIME]，以及可通过TCP使用IMAP协议访问的Internet主机上的搜索程序。
The IMAP URL follows the common Internet scheme syntax as defined in [URI-GEN]. If :<port> is omitted, the port defaults to 143 (as defined in Section 2.1 of [IMAP4]).
IMAP URL遵循[URI-GEN]中定义的通用Internet方案语法。如果省略：<port>，则端口默认为143（定义见[IMAP4]第2.1节）。
An absolute IMAP URL takes one of the following forms:
绝对IMAP URL采用以下形式之一：
imap://<iserver>[/]
imap://<iserver>[/]
imap://<iserver>/<enc-mailbox>[<uidvalidity>][?<enc-search>]
imap://<iserver>/<enc-mailbox>[<uidvalidity>][?<enc-search>]
imap://<iserver>/<enc-mailbox>[<uidvalidity>]<iuid>
[<isection>][<ipartial>][<iurlauth>]
imap://<iserver>/<enc-mailbox>[<uidvalidity>]<iuid>
[<isection>][<ipartial>][<iurlauth>]
The first form is used to refer to an IMAP server (see Section 4), the second form refers to the contents of a mailbox or a set of messages resulting from a search (see Section 5), and the final form refers to a specific message or message part, and possibly a byte range in that part (see Section 6). If [URLAUTH] extension is supported, then the final form can have the <iurlauth> component (see Section 6.1 for more details).
第一种形式是指IMAP服务器（见第4节），第二种形式是指邮箱的内容或搜索产生的一组邮件（见第5节），最后一种形式是指特定的邮件或邮件部分，可能还有该部分的字节范围（见第6节）。如果支持[URLAUTH]扩展，则最终表单可以包含<iurlauth>组件（有关更多详细信息，请参阅第6.1节）。
The <iserver> component common to all types of absolute IMAP URLs has the following syntax expressed in ABNF [ABNF]:
所有类型的绝对IMAP URL通用的<iserver>组件具有以下语法，用ABNF[ABNF]表示：
[iuserinfo "@"] host [ ":" port ]
[iuserinfo”@“]主机[”：“端口]
The <iserver> component is the same as "authority" defined in [URI-GEN]. The syntax and uses of the <iuserinfo> ("IMAP userinfo component") are described in detail in Section 3. The syntax of <host> and <port> is described in [URI-GEN].
<iserver>组件与[URI-GEN]中定义的“authority”相同。第3节详细介绍了<iuserinfo>（“IMAP用户信息组件”）的语法和用法。[URI-GEN]中描述了<host>和<port>的语法。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[关键词]中所述进行解释。
This document references many productions from [URI-GEN]. When the document needs to emphasize IMAP URI-specific differences from [URI-GEN] (i.e., for parts of IMAP URIs that have more restricted syntax than generic URIs), it uses a non-terminal i<foo> to define an IMAP-specific version of the non-terminal <foo> from [URI-GEN].
本文档引用了[URI-GEN]中的许多产品。当文档需要强调与[URI-GEN]的IMAP URI特定差异时（即，对于语法比通用URI更受限制的IMAP URI部分），它使用非终端i<foo>从[URI-GEN]定义非终端<foo>的IMAP特定版本。
Note that the ABNF syntax shown in Section 11 is normative. Sections 2-6 may use a less formal syntax that does not necessarily match the normative ABNF shown in Section 11. If there are any differences between the syntax shown in Sections 2-6 and Section 11, then the syntax shown in Section 11 must be treated as authoritative. Non-syntax requirements included in Sections 2-6 are, of course, normative.
请注意，第11节中显示的ABNF语法是规范性的。第2-6节可能使用不太正式的语法，不一定与第11节所示的规范性ABNF相匹配。如果第2-6节和第11节中显示的语法之间存在任何差异，则第11节中显示的语法必须视为权威。当然，第2-6节中包含的非语法要求是规范性的。
The <iuserinfo> component conforms to the generic syntax of <userinfo> defined in [URI-GEN]. It has the following syntax expressed in ABNF [ABNF]:
<iuserinfo>组件符合[URI-GEN]中定义的<userinfo>的通用语法。它使用ABNF[ABNF]表示以下语法：
enc-user [iauth] / [enc-user] iauth
加密用户[iauth]/[enc用户]iauth
The meaning of the different parts is described in subsections of this section.
本节各小节描述了不同部分的含义。
The "enc-user" part of the "iuserinfo" component, if present, denotes mailbox naming scope. If it is absent, the IMAP URL can only reference mailboxes with globally unique names, i.e., mailboxes with names that don't change depending on the user the client authenticated as to the IMAP server. Note that not all IMAP implementations support globally unique names.
“iuserinfo”组件的“enc user”部分（如果存在）表示邮箱命名范围。如果不存在，IMAP URL只能引用具有全局唯一名称的邮箱，即名称不随客户端对IMAP服务器进行身份验证的用户而变化的邮箱。请注意，并非所有IMAP实现都支持全局唯一的名称。
For example, a personal mailbox described by the following URL <imap://michael@example.org/INBOX> is most likely different from a personal mailbox described by <imap://bester@example.org/INBOX>, even though both URLs use the same mailbox name.
例如，由以下URL描述的个人邮箱<imap://michael@org/INBOX>很可能不同于<imap://bester@org/INBOX>，即使两个URL使用相同的邮箱名称。
The userinfo component (see [URI-GEN]) of an IMAP URI may contain an IMAP user name (a.k.a. authorization identity [SASL], "enc-user") and/or an authentication mechanism. (Note that the "enc-user" also defines a mailbox naming scope as described in Section 3.1). The IMAP user name and the authentication mechanism are used in the "LOGIN" or "AUTHENTICATE" commands after making the connection to the IMAP server.
IMAP URI的userinfo组件（参见[URI-GEN]）可以包含IMAP用户名（也称为授权标识[SASL]、“enc用户”）和/或身份验证机制。（请注意，“enc用户”还定义了第3.1节所述的邮箱命名范围）。在连接到IMAP服务器后，“登录”或“身份验证”命令中将使用IMAP用户名和身份验证机制。
If no user name and no authentication mechanism are supplied, the client MUST authenticate as anonymous to the server. If the server advertises AUTH=ANONYMOUS IMAP capability, the client MUST use the AUTHENTICATE command with ANONYMOUS [ANONYMOUS] SASL mechanism. If SASL ANONYMOUS is not available, the (case-insensitive) user name "anonymous" is used with the "LOGIN" command and the Internet email address of the end user accessing the resource is supplied as the password. The latter option is given in order to provide for interoperability with deployed servers.
如果未提供用户名和身份验证机制，则客户端必须以匿名身份向服务器进行身份验证。如果服务器播发AUTH=ANONYMOUS IMAP功能，则客户端必须使用带有ANONYMOUS[ANONYMOUS]SASL机制的AUTHENTICATE命令。如果SASL ANONYMOUS不可用，则（不区分大小写）用户名“ANONYMOUS”与“LOGIN”命令一起使用，并且访问资源的最终用户的Internet电子邮件地址作为密码提供。提供后一个选项是为了提供与已部署服务器的互操作性。
Note that, as described in RFC 3501, the "LOGIN" command MUST NOT be used when the IMAP server advertises the LOGINDISABLED capability.
请注意，如RFC 3501中所述，当IMAP服务器公布LOGINDISABLED功能时，不得使用“LOGIN”命令。
An authentication mechanism (as used by the IMAP AUTHENTICATE command) can be expressed by adding ";AUTH=<enc-auth-type>" to the end of the user name in an IMAP URL. When such an <enc-auth-type> is indicated, the client SHOULD request appropriate credentials from that mechanism and use the "AUTHENTICATE" command instead of the "LOGIN" command. If no user name is specified, one MUST be obtained from the mechanism or requested from the user/configuration as appropriate.
可以通过在IMAP URL的用户名末尾添加“AUTH=<enc AUTH type>”来表示身份验证机制（由IMAP AUTHENTICATE命令使用）。当指示这样一个<enc auth type>时，客户端应该从该机制请求适当的凭据，并使用“AUTHENTICATE”命令而不是“LOGIN”命令。如果未指定用户名，则必须从机制中获取用户名，或根据需要从用户/配置中请求用户名。
The string ";AUTH=*" indicates that the client SHOULD select an appropriate authentication mechanism. (Though the '*' character in this usage is not strictly a delimiter, it is being treated like a sub-delim [URI-GEN] in this instance. It MUST NOT be percent-encoded in this usage, as ";AUTH=%2A" will not match this production.) It MAY use any mechanism listed in the response to the CAPABILITY command (or CAPABILITY response code) or use an out-of-band security service resulting in a PREAUTH connection. If no user name is specified and no appropriate authentication mechanisms are available, the client SHOULD fall back to anonymous login as described above. The behavior prescribed in this section allows a URL that grants read-write access to authorized users and read-only anonymous access to other users.
字符串“AUTH=*”表示客户端应选择适当的身份验证机制。（尽管此用法中的“*”字符并非严格意义上的分隔符，但在本例中，它被视为子delim[URI-GEN]。在此用法中，它不能进行百分比编码，因为“AUTH=%2A”将与此产品不匹配。）它可以使用对CAPABILITY命令（或CAPABILITY response code）的响应中列出的任何机制或者使用带外安全服务，从而实现预授权连接。如果未指定用户名且没有适当的身份验证机制可用，则客户端应返回到如上所述的匿名登录。本节中规定的行为允许URL向授权用户授予读写访问权限，并向其他用户授予只读匿名访问权限。
If a user name is included with no authentication mechanism, then ";AUTH=*" is assumed.
如果用户名不包含身份验证机制，则假定为“AUTH=*”。
Clients must take care when resolving a URL that requires or requests any sort of authentication, since URLs can easily come from untrusted sources. Supplying authentication credentials to the wrong server may compromise the security of the user's account; therefore, the program resolving the URL should meet at least one of the following criteria in this case:
客户端在解析需要或请求任何身份验证的URL时必须小心，因为URL很容易来自不受信任的源。向错误的服务器提供身份验证凭据可能会损害用户帐户的安全性；因此，在这种情况下，解析URL的程序应至少满足以下标准之一：
1) The URL comes from a trusted source, such as a referral server that the client has validated and trusts according to site policy. Note that user entry of the URL may or may not count as a trusted source, depending on the experience level of the user and site policy.
1) URL来自受信任的源，例如客户端已验证并根据站点策略信任的引用服务器。请注意，URL的用户输入可能算作或不算作可信源，这取决于用户的体验级别和站点策略。
2) Explicit local site policy permits the client to connect to the server in the URL. For example, a company example.com may have a site policy to trust all IMAP server names ending in example.com, whereas such a policy would be unwise for example.edu where random students can set up IMAP servers.
2) 显式本地站点策略允许客户端连接到URL中的服务器。例如，一家公司example.com可能有一个站点策略来信任以example.com结尾的所有IMAP服务器名称，而这样的策略对于example.edu来说是不明智的，在example.edu中，随机学生可以设置IMAP服务器。
3) The user confirms that connecting to that domain name with the specified credentials and/or mechanism is permitted. For example, when using "LOGIN" or SASL PLAIN with Transport Layer Security
3) 用户确认允许使用指定的凭据和/或机制连接到该域名。例如，使用具有传输层安全性的“登录”或SASL平原时
(TLS), the IMAP URL client presents a dialog box "Is it OK to send your password to server "example.com"? Please be aware the owners of example.com will be able to reuse your password to connect to other servers on your behalf".
（TLS），IMAP URL客户端会显示一个对话框“是否可以将您的密码发送到服务器“example.com”？请注意example.com的所有者将能够重用您的密码以代表您连接到其他服务器”。
4) A mechanism is used that validates the server before passing potentially compromising client credentials. For example, a site has a designated TLS certificate used to certify site-trusted IMAP server certificates, and this has been configured explicitly into the IMAP URL client. Another example is use of a Simple Authentication and Security Layer (SASL) mechanism such as DIGEST-MD5 [DIGEST-MD5], which supports mutual authentication.
4) 使用了一种机制，在传递可能造成危害的客户端凭据之前验证服务器。例如，站点具有用于认证站点受信任IMAP服务器证书的指定TLS证书，并且该证书已显式配置到IMAP URL客户端中。另一个例子是使用简单身份验证和安全层（SASL）机制，如DIGEST-MD5[DIGEST-MD5]，它支持相互身份验证。
5) An authentication mechanism is used that will not reveal any information to the server that could be used to compromise future connections. Examples are SASL ANONYMOUS [ANONYMOUS] or GSSAPI [GSSAPI].
5) 使用的身份验证机制不会向服务器透露任何可能用于破坏未来连接的信息。例如SASL ANONYMOUS[匿名]或GSSAPI[GSSAPI]。
URLs that do not include a user name but include an authentication mechanism (";AUTH=<mech>") must be treated with extra care, since for some <mech>s they are more likely to compromise the user's primary account. A URL containing ";AUTH=*" must also be treated with extra care since it might fall back on a weaker security mechanism. Finally, clients are discouraged from using a plaintext password as a fallback with ";AUTH=*" unless the connection has strong encryption.
对于不包含用户名但包含身份验证机制（“AUTH=<mech>”）的URL，必须格外小心，因为对于某些<mech>URL，它们更可能危害用户的主帐户。包含“AUTH=*”的URL也必须格外小心，因为它可能依赖于较弱的安全机制。最后，不鼓励客户端使用纯文本密码作为带“AUTH=*”的备用密码，除非连接具有强加密。
A program interpreting IMAP URLs MAY cache open connections to an IMAP server for later reuse. If a URL contains a user name, only connections authenticated as that user may be reused. If a URL does not contain a user name or authentication mechanism, then only an anonymous connection may be reused.
解释IMAP URL的程序可能会缓存到IMAP服务器的打开连接，以便以后重用。如果URL包含用户名，则只能重用作为该用户身份验证的连接。如果URL不包含用户名或身份验证机制，则只能重用匿名连接。
Note that if unsafe or reserved characters such as " " (space) or ";" are present in the user name or authentication mechanism, they MUST be percent-encoded as described in [URI-GEN].
请注意，如果用户名或身份验证机制中存在不安全或保留字符，如“”（空格）或“；”，则必须按照[URI-GEN]中的说明对其进行百分比编码。
As per Sections 3.1 and 3.2 of this document, the IMAP URI enc-user has two purposes:
根据本文件第3.1节和第3.2节，IMAP URI enc用户有两个目的：
1) It provides context for user-specific mailbox paths such as "INBOX" (Section 3.1).
1) 它为特定于用户的邮箱路径（如“收件箱”）提供上下文（第3.1节）。
2) It specifies that resolution of the URL requires logging in as that user and limits use of that URL to only that user (Section 3.2).
2) 它指定URL解析需要以该用户身份登录，并将该URL的使用限制为仅限该用户（第3.2节）。
An obvious limitation of using the same field for both purposes is that the URL can be resolved only by the mailbox owner. In order to avoid this restriction, implementations should use globally unique mailbox names (see Section 3.1) whenever possible.
将同一字段用于两个目的的一个明显限制是URL只能由邮箱所有者解析。为了避免此限制，实现应尽可能使用全局唯一的邮箱名称（请参阅第3.1节）。
Note: There is currently no general way in IMAP of learning a globally unique name for a mailbox. However, by looking at the NAMESPACE [NAMESPACE] command result, it is possible to determine whether or not a mailbox name is globally unique.
注意：目前在IMAP中没有学习邮箱全局唯一名称的通用方法。但是，通过查看NAMESPACE[NAMESPACE]命令结果，可以确定邮箱名称是否全局唯一。
The URLAUTH component overrides the second purpose of the enc-user in the IMAP URI and by default permits the URI to be resolved by any user permitted by the <access> identifier. URLAUTH and <access> identifier are described in Section 6.1.
URLAUTH组件覆盖IMAP URI中enc用户的第二个目的，默认情况下允许<access>标识符允许的任何用户解析URI。第6.1节描述了URLAUTH和<access>标识符。
An IMAP URL referring to an IMAP server has the following form:
引用IMAP服务器的IMAP URL具有以下形式：
imap://<iserver>[/]
imap://<iserver>[/]
This URL type is frequently used to describe a location of an IMAP server, both in referrals and in configuration. It may optionally contain the <iuserinfo> component (see Sections 3 and 11). A program interpreting this URL would issue the standard set of commands it uses to present a view of the content of the IMAP server, as visible to the user described by the "enc-user" part of the <iuserinfo> component, if the "enc-user" part is specified.
此URL类型通常用于描述IMAP服务器在引用和配置中的位置。它可以选择性地包含<iuserinfo>组件（参见第3节和第11节）。解释此URL的程序将发出一组标准命令，用于显示IMAP服务器内容的视图，如果指定了“enc user”部分，则该视图由<iuserinfo>组件的“enc user”部分描述，对用户可见。
An IMAP URL referring to a list of messages has the following form:
引用消息列表的IMAP URL具有以下形式：
imap://<iserver>/<enc-mailbox>[<uidvalidity>][?<enc-search>]
imap://<iserver>/<enc-mailbox>[<uidvalidity>][?<enc-search>]
The <enc-mailbox> field is used as the argument to the IMAP4 "SELECT" or "EXAMINE" command. Note that if unsafe or reserved characters such as " " (space), ";", or "?" are present in <enc-mailbox>, they MUST be percent-encoded as described in [URI-GEN].
<enc mailbox>字段用作IMAP4“选择”或“检查”命令的参数。请注意，如果<enc mailbox>中存在不安全或保留字符，如“”（空格）、“；”或“”，则必须按照[URI-GEN]中的说明对其进行百分比编码。
The <uidvalidity> field is optional. If it is present, it MUST be the same as the value of IMAP4 UIDVALIDITY response code at the time the URL was created. This MUST be used by the program interpreting the IMAP URL to determine if the URL is stale. If the IMAP URL is stale, then the program should behave as if the corresponding mailbox doesn't exist.
<uidvalidity>字段是可选的。如果存在，则它必须与创建URL时IMAP4 UIDVality响应代码的值相同。解释IMAP URL的程序必须使用它来确定URL是否过时。如果IMAP URL过时，则程序的行为应与相应的邮箱不存在一样。
Note that the <uidvalidity> field is a modifier to the <enc-mailbox>, i.e., it is considered a part of the last "component" (as used in [URI-GEN]) of the <enc-mailbox>. This is significant during relative URI resolution.
请注意，<uidvalidity>字段是<enc mailbox>的一个修饰符，即它被视为<enc mailbox>的最后一个“组件”（如[URI-GEN]中所用）的一部分。这在相对URI解析期间非常重要。
The "?<enc-search>" field is optional. If it is not present, the program interpreting the URL will present the entire content of the mailbox.
“<enc search>”字段是可选的。如果不存在，则解释URL的程序将显示邮箱的全部内容。
If the "?<enc-search>" field is present, the program interpreting the URL should use the contents of this field as arguments following an IMAP4 SEARCH command. These arguments are likely to contain unsafe characters such as " " (space) (which are likely to be present in the <enc-search>). If unsafe characters are present, they MUST be percent-encoded as described in [URI-GEN].
如果存在“<enc search>”字段，则解释URL的程序应使用该字段的内容作为IMAP4搜索命令后的参数。这些参数可能包含不安全的字符，如“”（空格）（可能出现在<enc search>中）。如果存在不安全字符，则必须按照[URI-GEN]中的说明对其进行百分比编码。
Note that quoted strings and non-synchronizing literals [LITERAL+] are allowed in the <enc-search> content; however, synchronizing literals are not allowed, as their presence would effectively mean that the agent interpreting IMAP URLs needs to parse an <enc-search> content, find all synchronizing literals, and perform proper command continuation request handling (see Sections 4.3 and 7 of [IMAP4]).
请注意，<enc search>内容中允许使用带引号的字符串和非同步文本[LITERAL+]；但是，不允许同步文本，因为它们的存在实际上意味着解释IMAP URL的代理需要解析<enc search>内容，查找所有同步文本，并执行正确的命令继续请求处理（请参阅[IMAP4]第4.3和7节）。
An IMAP URL referring to a specific message or message part has the following form:
引用特定消息或消息部分的IMAP URL具有以下形式：
imap://<iserver>/<enc-mailbox>[<uidvalidity>]<iuid>
[<isection>][<ipartial>][<iurlauth>]
imap://<iserver>/<enc-mailbox>[<uidvalidity>]<iuid>
[<isection>][<ipartial>][<iurlauth>]
The <enc-mailbox> and [uidvalidity] are as defined in Section 5 above.
<enc邮箱>和[UIDVality]如上文第5节所述。
If <uidvalidity> is present in this form, it SHOULD be used by the program interpreting the URL to determine if the URL is stale.
如果此表单中存在<uidvalidity>，则解释URL的程序应使用它来确定URL是否过时。
The <iuid> refers to an IMAP4 message Unique Identifier (UID), and it SHOULD be used as the <set> argument to the IMAP4 "UID FETCH" command.
<iuid>引用IMAP4消息唯一标识符（UID），它应该用作IMAP4“UID FETCH”命令的<set>参数。
The <isection> field is optional. If not present, the URL refers to
the entire Internet message as returned by the IMAP command "UID
FETCH <uid> BODY.PEEK[]". If present, the URL refers to the object
returned by a "UID FETCH <uid> BODY.PEEK[<section>]" command. The
type of the object may be determined by using a "UID FETCH <uid>
BODYSTRUCTURE" command and locating the appropriate part in the
The <isection> field is optional. If not present, the URL refers to
the entire Internet message as returned by the IMAP command "UID
FETCH <uid> BODY.PEEK[]". If present, the URL refers to the object
returned by a "UID FETCH <uid> BODY.PEEK[<section>]" command. The
type of the object may be determined by using a "UID FETCH <uid>
BODYSTRUCTURE" command and locating the appropriate part in the
resulting BODYSTRUCTURE. Note that unsafe characters in [isection] MUST be percent-encoded as described in [URI-GEN].
由此产生的车身结构。请注意，[isection]中的不安全字符必须按照[URI-GEN]中的说明进行百分比编码。
The <ipartial> field is optional. If present, it effectively appends "<<partial-range>>" to the end of the UID FETCH BODY.PEEK[<section>] command constructed as described in the previous paragraph. In other words, it allows the client to request a byte range of the message/message part.
<ipartial>字段是可选的。如果存在，它将有效地在UID FETCH BODY.PEEK[<section>]命令的末尾追加“<<partial range>>”，该命令的构造如前一段所述。换句话说，它允许客户端请求消息/消息部分的字节范围。
The <iurlauth> field is described in detail in Section 6.1.
第6.1节详细描述了<iurlauth>字段。
URLAUTH authorized URLs are only supported by an IMAP server advertising the URLAUTH IMAP capability [URLAUTH].
URLAUTH授权的URL仅由宣传URLAUTH IMAP功能[URLAUTH]的IMAP服务器支持。
URLAUTH is a component, appended at the end of a URL, that conveys authorization to access the data addressed by that URL. It contains an authorized access identifier, an authorization mechanism name, and an authorization token. The authorization token is generated from the URL, the authorized access identifier, authorization mechanism name, and a mailbox access key.
URLAUTH是一个附加在URL末尾的组件，它传递访问该URL寻址的数据的授权。它包含授权访问标识符、授权机制名称和授权令牌。授权令牌由URL、授权访问标识符、授权机制名称和邮箱访问密钥生成。
Note: This specification only allows for the URLAUTH component in IMAP URLs describing a message or its part.
注意：本规范仅允许IMAP URL中描述消息或其部分的URLAUTH组件。
The mailbox access key is an unpredictable, random string. To ensure unpredictability, the random string with at least 128 bits of entropy is generated by software or hardware (not by the human user).
邮箱访问密钥是不可预测的随机字符串。为了确保不可预测性，至少具有128位熵的随机字符串由软件或硬件（而不是人类用户）生成。
Each user has a table of mailboxes and an associated mailbox access key for each mailbox. Consequently, the mailbox access key is per-user and per-mailbox. In other words, two users sharing the same mailbox each have a different mailbox access key for that mailbox, and each mailbox accessed by a single user also has a different mailbox access key.
每个用户都有一个邮箱表和每个邮箱的关联邮箱访问密钥。因此，邮箱访问密钥为每个用户和每个邮箱。换句话说，共享同一邮箱的两个用户各自具有该邮箱的不同邮箱访问密钥，并且单个用户访问的每个邮箱也具有不同的邮箱访问密钥。
The authorized <access> identifier restricts use of the URLAUTH authorized URL to certain users authorized on the server, as described in Section 6.1.2.
如第6.1.2节所述，授权的<access>标识符将URLAUTH授权URL的使用限制为在服务器上授权的某些用户。
The authorization mechanism is the algorithm by which the URLAUTH is generated and subsequently verified, using the mailbox access key.
授权机制是使用邮箱访问密钥生成并随后验证URLAUTH的算法。
The authorization token is a deterministic string of at least 128 bits that an entity with knowledge of the secret mailbox access key and URL authorization mechanism can use to verify the URL.
授权令牌是至少128位的确定性字符串，了解秘密邮箱访问密钥和URL授权机制的实体可以使用它来验证URL。
A specific message or message part IMAP URL can optionally contain ";EXPIRE=<datetime>" and/or ";URLAUTH=<access>:<mech>:<token>".
特定消息或消息部分IMAP URL可以选择性地包含“EXPIRE=<datetime>”和/或“URLAUTH=<access>：<mech>：<token>”。
When ";EXPIRE=<datetime>" is used, this indicates the latest date and time that the URL is valid. After that date and time, the URL has expired and server implementations MUST reject the URL. If ";EXPIRE=<datetime>" is not used, the URL has no expiration, but can still be revoked using the RESETKEY command [URLAUTH].
当使用“EXPIRE=<datetime>”时，这表示URL有效的最新日期和时间。在该日期和时间之后，URL已过期，服务器实现必须拒绝该URL。如果未使用“EXPIRE=<datetime>，则URL不会过期，但仍可使用RESETKEY命令[URLAUTH]撤销。
The URLAUTH takes the form ";URLAUTH=<access>:<mech>:<token>", and it MUST be at the end of the URL. It is composed of three parts. The <access> portion provides the authorized access identifiers that may constrain the operations and users that are permitted to use this URL. The <mech> portion provides the authorization mechanism used by the IMAP server to generate the authorization token that follows. The <token> portion provides the authorization token, which can be generated using the GENURLAUTH command [URLAUTH].
URLAUTH的格式为“URLAUTH=<access>：<mech>：<token>”，它必须位于URL的末尾。它由三部分组成。<access>部分提供授权访问标识符，这些标识符可以约束允许使用此URL的操作和用户。<mech>部分提供IMAP服务器用于生成以下授权令牌的授权机制。<token>部分提供授权令牌，可以使用GENURLAUTH命令[URLAUTH]生成授权令牌。
The "submit+" <access> identifier prefix, followed by a userid, indicates that only a userid authorized as a message submission entity on behalf of the specified userid is permitted to use this URL. The IMAP server does not validate the specified userid but does validate that the IMAP session has an authorization identity that is authorized as a message submission entity. The authorized message submission entity MUST validate the userid prior to contacting the IMAP server.
“submit+”<access>标识符前缀后跟一个userid，表示仅允许代表指定userid授权为消息提交实体的userid使用此URL。IMAP服务器不验证指定的用户ID，但验证IMAP会话是否具有作为消息提交实体授权的授权标识。授权邮件提交实体必须在联系IMAP服务器之前验证用户ID。
The "user+" <access> identifier prefix, followed by a userid, indicates that use of this URL is limited to IMAP sessions that are logged in as the specified userid (that is, have authorization identity as that userid).
“user+”<access>标识符前缀后跟一个userid，表示此URL的使用仅限于作为指定userid登录的IMAP会话（即，具有作为该userid的授权标识）。
Note: If a SASL mechanism that provides both authorization and authentication identifiers is used to authenticate to the IMAP server, the "user+" <access> identifier MUST match the
注意：如果使用同时提供授权和身份验证标识符的SASL机制对IMAP服务器进行身份验证，“用户+”<access>标识符必须与
authorization identifier. If the SASL mechanism can't transport the authorization identifier, the "user+" <access> identifier MUST match the authorization identifier derived from the authentication identifier (see [SASL]).
授权标识符。如果SASL机制无法传输授权标识符，“用户+”<access>标识符必须与从身份验证标识符派生的授权标识符匹配（请参见[SASL]）。
The "authuser" <access> identifier indicates that use of this URL is limited to authenticated IMAP sessions that are logged in as any non-anonymous user (that is, have authorization identity as a non-anonymous user) of that IMAP server. To restate this: use of this type of URL is prohibited to anonymous IMAP sessions, i.e., any URLFETCH command containing this type of URL issued in an anonymous session MUST return NIL in the URLFETCH response.
“authuser”<access>标识符表示此URL的使用仅限于作为该IMAP服务器的任何非匿名用户（即具有非匿名用户的授权标识）登录的经过身份验证的IMAP会话。重申这一点：禁止匿名IMAP会话使用此类型的URL，即在匿名会话中发出的包含此类型URL的任何URLFETCH命令在URLFETCH响应中必须返回NIL。
The "anonymous" <access> identifier indicates that use of this URL is not restricted by session authorization identity; that is, any IMAP session in authenticated or selected state (as defined in [IMAP4]), including anonymous sessions, may issue a URLFETCH [URLAUTH] using this URL.
“匿名”<access>标识符表示此URL的使用不受会话授权标识的限制；也就是说，任何处于已验证或选定状态（如[IMAP4]中定义）的IMAP会话，包括匿名会话，都可以使用此URL发出URLFETCH[URLAUTH]。
The authorization token is represented as an ASCII-encoded hexadecimal string, which is used to authorize the URL. The length and the calculation of the authorization token depend upon the mechanism used, but in all cases, the authorization token is at least 128 bits (and therefore at least 32 hexadecimal digits).
授权令牌表示为ASCII编码的十六进制字符串，用于授权URL。授权令牌的长度和计算取决于所使用的机制，但在所有情况下，授权令牌至少为128位（因此至少为32位十六进制数字）。
Example:
例子：
<imap://joe@example.com/INBOX/;uid=20/;section=1.2;urlauth=
submit+fred:internal:91354a473744909de610943775f92038>
<imap://joe@example.com/INBOX/;uid=20/;section=1.2;urlauth=
submit+fred:internal:91354a473744909de610943775f92038>
Relative IMAP URLs are permitted and are resolved according to the rules defined in [URI-GEN]. In particular, in IMAP URLs parameters (such as ";uid=" or ";section=") are treated as part of the normal path with respect to relative URL resolution.
允许使用相对IMAP URL，并根据[URI-GEN]中定义的规则进行解析。特别是，在IMAP URL中，参数（如“uid=”或“section=”）被视为相对于相对URL解析的正常路径的一部分。
[URI-GEN] defines four forms of relative URLs: <inetwork-path>, <iabsolute-path>, <irelative-path>, and <ipath-empty>. Their syntax is defined in Section 11.
[URI-GEN]定义了四种形式的相对URL:<inetwork path>、<iabsolute path>、<irelative path>和<ipath empty>。第11节定义了它们的语法。
A relative reference that begins with two slash characters is termed a network-path reference (<inetwork-path>); such references are rarely used, because in most cases they can be replaced with an equivalent absolute URL. A relative reference that begins with a single slash character is termed an absolute-path reference (<iabsolute-path>; see also Section 7.1). A relative reference that does not begin with a slash character is termed a relative-path
以两个斜杠字符开头的相对引用称为网络路径引用（<inetwork path>）；这种引用很少使用，因为在大多数情况下，它们可以替换为等效的绝对URL。以单个斜杠字符开头的相对引用称为绝对路径引用（<iabsolute path>；另请参见第7.1节）。不以斜杠字符开头的相对引用称为相对路径
reference (<irelative-path>; see also Section 7.2). The final form is <ipath-empty>, which is "same-document reference" (see Section 4.4 of [URI-GEN]).
参考（参见第7.2节）。最后一种形式是<ipath empty>，即“同一文档参考”（见[URI-GEN]第4.4节）。
The following observations about relative URLs are important:
以下关于相对URL的观察非常重要：
The <iauth> grammar element (which is a part of <iuserinfo>, which is, in turn, a part of <iserver>; see Section 3) is considered part of the user name for purposes of resolving relative IMAP URLs. This means that unless a new user name/server specification is included in the relative URL, the authentication mechanism is inherited from the base IMAP URL.
<iauth>语法元素（它是<iuserinfo>的一部分，反过来又是<iserver>的一部分；参见第3节）被视为用户名的一部分，用于解析相对IMAP URL。这意味着，除非在相对URL中包含新的用户名/服务器规范，否则身份验证机制将从基本IMAP URL继承。
URLs always use "/" as the hierarchy delimiter for the purpose of resolving paths in relative URLs. IMAP4 permits the use of any hierarchy delimiter in mailbox names. For this reason, relative mailbox paths will only work if the mailbox uses "/" as the hierarchy delimiter. Relative URLs may be used on mailboxes that use other delimiters, but in that case, the entire mailbox name MUST be specified in the relative URL or inherited as a whole from the base URL.
URL始终使用“/”作为层次分隔符，以便解析相对URL中的路径。IMAP4允许在邮箱名称中使用任何层次分隔符。因此，只有当邮箱使用“/”作为层次结构分隔符时，相对邮箱路径才会起作用。可以在使用其他分隔符的邮箱上使用相对URL，但在这种情况下，必须在相对URL中指定整个邮箱名称，或者从基本URL整体继承整个邮箱名称。
If an IMAP server allows for mailbox names starting with "./" or "../", ending with "/." or "/..", or containing sequences "/../" or "/./", then such mailbox names MUST be percent-encoded as described in [URI-GEN]. Otherwise, they would be misinterpreted as dot-segments (see Section 3.3 of [URI-GEN]), which are processed specially during the relative path resolution process.
如果IMAP服务器允许邮箱名称以“/”或“./”开头，以“/”或“/…”结尾，或包含序列“/…/”或“/…”，则此类邮箱名称必须按照[URI-GEN]中的说明进行百分比编码。否则，它们将被误解为点段（见[URI-GEN]第3.3节），在相对路径解析过程中进行特殊处理。
A relative reference that begins with a single slash character is termed an absolute-path reference (see Section 4.2 of [URI-GEN]). If an IMAP server permits mailbox names with a leading "/", then the leading "/" MUST be percent-encoded as described in [URI-GEN]. Otherwise, the produced absolute-path reference URI will be misinterpreted as a network-path reference [URI-GEN] described by the <inetwork-path> non-terminal.
以单个斜杠字符开头的相对引用称为绝对路径引用（参见[URI-GEN]第4.2节）。如果IMAP服务器允许邮箱名称使用前导“/”，则前导“/”必须按照[URI-GEN]中的说明进行百分比编码。否则，生成的绝对路径参考URI将被误解为<inetwork path>非终端描述的网络路径参考[URI-GEN]。
A relative reference that does not begin with a slash character is termed a relative-path reference [URI-GEN]. Implementations MUST NOT generate or accept relative-path IMAP references.
不以斜杠字符开头的相对引用称为相对路径引用[URI-GEN]。实现不能生成或接受相对路径IMAP引用。
See also Section 4.2 of [URI-GEN] for restrictions on relative-path references.
有关相对路径引用的限制，请参见[URI-GEN]的第4.2节。
IMAP4, Section 5.1.3 [IMAP4] includes a convention for encoding non-US-ASCII characters in IMAP mailbox names. Because this convention is private to IMAP, it is necessary to convert IMAP's encoding to one that can be more easily interpreted by a URL display program. For this reason, IMAP's modified UTF-7 encoding for mailboxes MUST be converted to UTF-8 [UTF-8]. Since 8-bit octets are not permitted in URLs, the UTF-8 octets are percent-encoded as required by the URL specification [URI-GEN], Section 2.1. Sample code is included in Appendix A to demonstrate this conversion.
IMAP4第5.1.3节[IMAP4]包括一个在IMAP邮箱名称中编码非美国ASCII字符的约定。由于此约定是IMAP专用的，因此有必要将IMAP的编码转换为URL显示程序更容易解释的编码。因此，IMAP修改后的邮箱UTF-7编码必须转换为UTF-8[UTF-8]。由于URL中不允许使用8位八位字节，UTF-8八位字节按照URL规范[URI-GEN]第2.1节的要求进行百分比编码。示例代码包含在附录A中，以演示此转换。
IMAP user names are UTF-8 strings and MUST be percent-encoded as required by the URL specification [URI-GEN], Section 2.1.
IMAP用户名是UTF-8字符串，必须按照URL规范[URI-GEN]第2.1节的要求进行百分比编码。
Also note that IMAP SEARCH criteria can contain non-US-ASCII characters. 8-bit octets in those strings MUST be percent-encoded as required by the URL specification [URI-GEN], Section 2.1.
还请注意，IMAP搜索条件可以包含非美国ASCII字符。这些字符串中的8位八位字节必须按照URL规范[URI-GEN]第2.1节的要求进行百分比编码。
The following examples demonstrate how an IMAP4 client program might translate various IMAP4 URLs into a series of IMAP4 commands. Commands sent from the client to the server are prefixed with "C:", and responses sent from the server to the client are prefixed with "S:".
以下示例演示了IMAP4客户端程序如何将各种IMAP4 URL转换为一系列IMAP4命令。从客户端发送到服务器的命令前缀为“C:”，从服务器发送到客户端的响应前缀为“S:”。
The URL:
网址：
<imap://minbari.example.org/gray-council;UIDVALIDITY=385759045/;
UID=20/;PARTIAL=0.1024>
<imap://minbari.example.org/gray-council;UIDVALIDITY=385759045/;
UID=20/;PARTIAL=0.1024>
may result in the following client commands and server responses:
可能导致以下客户端命令和服务器响应：
<connect to minbari.example.org, port 143>
S: * OK [CAPABILITY IMAP4rev1 STARTTLS AUTH=ANONYMOUS] Welcome
C: A001 AUTHENTICATE ANONYMOUS
S: +
C: c2hlcmlkYW5AYmFieWxvbjUuZXhhbXBsZS5vcmc=
S: A001 OK Welcome sheridan@babylon5.example.org
C: A002 SELECT gray-council
<client verifies the UIDVALIDITY matches>
C: A003 UID FETCH 20 BODY.PEEK[]<0.1024>
<connect to minbari.example.org, port 143>
S: * OK [CAPABILITY IMAP4rev1 STARTTLS AUTH=ANONYMOUS] Welcome
C: A001 AUTHENTICATE ANONYMOUS
S: +
C: c2hlcmlkYW5AYmFieWxvbjUuZXhhbXBsZS5vcmc=
S: A001 OK Welcome sheridan@babylon5.example.org
C: A002 SELECT gray-council
<client verifies the UIDVALIDITY matches>
C: A003 UID FETCH 20 BODY.PEEK[]<0.1024>
The URL:
网址：
<imap://psicorp.example.org/~peter/%E6%97%A5%E6%9C%AC%E8%AA%9E/
%E5%8F%B0%E5%8C%97>
<imap://psicorp.example.org/~peter/%E6%97%A5%E6%9C%AC%E8%AA%9E/
%E5%8F%B0%E5%8C%97>
may result in the following client commands:
可能导致以下客户端命令：
<connect to psicorp.example.org, port 143>
S: * OK [CAPABILITY IMAP4rev1 STARTTLS AUTH=CRAM-MD5] Welcome
C: A001 LOGIN ANONYMOUS bester@psycop.psicorp.example.org
C: A002 SELECT ~peter/&ZeVnLIqe-/&U,BTFw-
<commands the client uses for viewing the contents of
the mailbox>
<connect to psicorp.example.org, port 143>
S: * OK [CAPABILITY IMAP4rev1 STARTTLS AUTH=CRAM-MD5] Welcome
C: A001 LOGIN ANONYMOUS bester@psycop.psicorp.example.org
C: A002 SELECT ~peter/&ZeVnLIqe-/&U,BTFw-
<commands the client uses for viewing the contents of
the mailbox>
The URL:
网址：
<imap://;AUTH=GSSAPI@minbari.example.org/gray-council/;uid=20/
;section=1.2>
<imap://;AUTH=GSSAPI@minbari.example.org/gray-council/;uid=20/
;section=1.2>
may result in the following client commands:
可能导致以下客户端命令：
<connect to minbari.example.org, port 143>
S: * OK Greetings
C: A000 CAPABILITY
S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI
S: A000 OK
C: A001 AUTHENTICATE GSSAPI
<authentication exchange>
C: A002 SELECT gray-council
C: A003 UID FETCH 20 BODY.PEEK[1.2]
<connect to minbari.example.org, port 143>
S: * OK Greetings
C: A000 CAPABILITY
S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI
S: A000 OK
C: A001 AUTHENTICATE GSSAPI
<authentication exchange>
C: A002 SELECT gray-council
C: A003 UID FETCH 20 BODY.PEEK[1.2]
If the following relative URL is located in that body part:
如果以下相对URL位于该身体部位：
<;section=1.4>
<;section=1.4>
this could result in the following client commands:
这可能导致以下客户端命令：
C: A004 UID FETCH 20 (BODY.PEEK[1.2.MIME]
BODY.PEEK[1.MIME]
BODY.PEEK[HEADER.FIELDS (Content-Location)])
<Client looks for Content-Location headers in
result. If no such headers, then it does the following>
C: A005 UID FETCH 20 BODY.PEEK[1.4]
C: A004 UID FETCH 20 (BODY.PEEK[1.2.MIME]
BODY.PEEK[1.MIME]
BODY.PEEK[HEADER.FIELDS (Content-Location)])
<Client looks for Content-Location headers in
result. If no such headers, then it does the following>
C: A005 UID FETCH 20 BODY.PEEK[1.4]
The URL:
网址：
<imap://;AUTH=*@minbari.example.org/gray%20council?
SUBJECT%20shadows>
<imap://;AUTH=*@minbari.example.org/gray%20council?
SUBJECT%20shadows>
could result in the following:
可能导致以下情况：
<connect to minbari.example.org, port 143>
S: * OK Welcome
C: A001 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=DIGEST-MD5
S: A001 OK
C: A002 AUTHENTICATE DIGEST-MD5
<authentication exchange>
S: A002 OK user lennier authenticated
C: A003 SELECT "gray council"
...
C: A004 SEARCH SUBJECT shadows
S: * SEARCH 8 10 13 14 15 16
S: A004 OK SEARCH completed
C: A005 FETCH 8,10,13:16 ALL
...
<connect to minbari.example.org, port 143>
S: * OK Welcome
C: A001 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=DIGEST-MD5
S: A001 OK
C: A002 AUTHENTICATE DIGEST-MD5
<authentication exchange>
S: A002 OK user lennier authenticated
C: A003 SELECT "gray council"
...
C: A004 SEARCH SUBJECT shadows
S: * SEARCH 8 10 13 14 15 16
S: A004 OK SEARCH completed
C: A005 FETCH 8,10,13:16 ALL
...
In the example above, the client has implementation-dependent choices. The authentication mechanism could be anything, including PREAUTH. The final FETCH command could fetch more or less information about the messages, depending on what it wishes to display to the user.
在上面的示例中，客户机具有依赖于实现的选项。身份验证机制可以是任何东西，包括预授权。最后的FETCH命令可以获取关于消息的更多或更少的信息，这取决于它希望向用户显示的内容。
The URL:
网址：
<imap://john;AUTH=*@minbari.example.org/babylon5/personel?
charset%20UTF-8%20SUBJECT%20%7B14+%7D%0D%0A%D0%98%D0%B2%
D0%B0%D0%BD%D0%BE%D0%B2%D0%B0>
<imap://john;AUTH=*@minbari.example.org/babylon5/personel?
charset%20UTF-8%20SUBJECT%20%7B14+%7D%0D%0A%D0%98%D0%B2%
D0%B0%D0%BD%D0%BE%D0%B2%D0%B0>
shows that 8-bit data can be sent using non-synchronizing literals [LITERAL+]. This could result in the following:
显示可以使用非同步文本[LITERAL+]发送8位数据。这可能导致以下情况：
<connect to minbari.example.org, port 143>
S: * OK Hi there
C: A001 CAPABILITY
S: * CAPABILITY IMAP4rev1 LITERAL+ AUTH=DIGEST-MD5
S: A001 OK
C: A002 AUTHENTICATE DIGEST-MD5
<authentication exchange>
S: A002 OK user john authenticated
C: A003 SELECT babylon5/personel
...
C: A004 SEARCH CHARSET UTF-8 SUBJECT {14+}
C: XXXXXXXXXXXXXX
S: * SEARCH 7 10 12
S: A004 OK SEARCH completed
C: A005 FETCH 7,10,12 ALL
<connect to minbari.example.org, port 143>
S: * OK Hi there
C: A001 CAPABILITY
S: * CAPABILITY IMAP4rev1 LITERAL+ AUTH=DIGEST-MD5
S: A001 OK
C: A002 AUTHENTICATE DIGEST-MD5
<authentication exchange>
S: A002 OK user john authenticated
C: A003 SELECT babylon5/personel
...
C: A004 SEARCH CHARSET UTF-8 SUBJECT {14+}
C: XXXXXXXXXXXXXX
S: * SEARCH 7 10 12
S: A004 OK SEARCH completed
C: A005 FETCH 7,10,12 ALL
...
...
where XXXXXXXXXXXXXX is 14 bytes of UTF-8 encoded data as specified in the URL above.
其中，XXXXXXXXXXXXX是上述URL中指定的14字节UTF-8编码数据。
The following absolute-path reference
下面是绝对路径引用
</foo/;UID=20/..>
</foo/;UID=20/..>
is the same as
与
</foo>
</foo>
That is, both of them reference the mailbox "foo" located on the IMAP server described by the corresponding Base URI.
也就是说，它们都引用位于IMAP服务器上的邮箱“foo”，该邮箱由相应的基本URI描述。
The following relative-path reference
以下是相对路径引用
<;UID=20>
<;UID=20>
references a message with UID in the mailbox specified by the Base URI.
在基URI指定的邮箱中引用UID为的邮件。
The following edge case example demonstrates that the ;UIDVALIDITY= modifier is a part of the mailbox name as far as relative URI resolution is concerned:
下面的edge案例示例表明：；就相对URI解析而言，UIDVALIDITY=修饰符是邮箱名称的一部分：
<..;UIDVALIDITY=385759045/;UID=20>
<..;UIDVALIDITY=385759045/;UID=20>
In this example, ".." is not a dot-segment [URI-GEN].
在本例中，“…”不是点段[URI-GEN]。
Security considerations discussed in the IMAP specification [IMAP4] and the URI specification [URI-GEN] are relevant. Security considerations related to authenticated URLs are discussed in Section 3.2 of this document.
IMAP规范[IMAP4]和URI规范[URI-GEN]中讨论的安全注意事项是相关的。本文档第3.2节讨论了与已验证URL相关的安全注意事项。
Many email clients store the plaintext password for later use after logging into an IMAP server. Such clients MUST NOT use a stored password in response to an IMAP URL without explicit permission from the user to supply that password to the specified host name.
许多电子邮件客户端存储明文密码，以便在登录IMAP服务器后使用。未经用户明确许可，此类客户端不得使用存储的密码响应IMAP URL，以将该密码提供给指定的主机名。
Clients resolving IMAP URLs that wish to achieve data confidentiality and/or integrity SHOULD use the STARTTLS command (if supported by the
解析希望实现数据机密性和/或完整性的IMAP URL的客户端应使用STARTTLS命令（如果
server) before starting authentication, or use a SASL mechanism, such as GSSAPI, that provides a confidentiality security layer.
服务器），或使用SASL机制（如GSSAPI）提供机密性安全层。
The "user+<userid>" <access> identifier limits resolution of that URL to a particular userid, whereas the "submit+<userid>" <access> identifier is more general and simply requires that the session be authorized by a user that has been granted a "submit" role within the authentication system. Use of either of these mechanisms limits the scope of the URL. An attacker who cannot authenticate using the appropriate credentials cannot make use of the URL.
“user+<userid>”<access>标识符将该URL的解析限制为特定的userid，而“submit+<userid>”<access>标识符更一般，只要求会话由在身份验证系统中被授予“submit”角色的用户授权。使用这两种机制都会限制URL的范围。无法使用适当凭据进行身份验证的攻击者无法使用URL。
The "authuser" and "anonymous" <access> identifiers do not have this level of protection. These access identifiers are primarily useful for public export of data from an IMAP server, without requiring that it be copied to a web or anonymous FTP server.
“authuser”和“anonymous”<access>标识符没有此级别的保护。这些访问标识符主要用于从IMAP服务器公开导出数据，而无需将数据复制到web或匿名FTP服务器。
The decision to use the "authuser" <access> identifier should be made with caution. An "authuser" <access> identifier can be used by any authorized user of the IMAP server; therefore, use of this access identifier should be limited to content that may be disclosed to any authorized user of the IMAP server.
决定使用“authuser”<access>标识符时应谨慎。IMAP服务器的任何授权用户都可以使用“authuser”<access>标识符；因此，该访问标识符的使用应限于可公开给IMAP服务器的任何授权用户的内容。
The decision to use the "anonymous" <access> identifier should be made with extreme caution. An "anonymous" <access> identifier can be used by anyone; therefore, use of this access identifier should be limited to content that may be disclosed to anyone.
决定使用“匿名”<access>标识符时应格外小心。任何人都可以使用“匿名”<access>标识符；因此，该访问标识符的使用应限于可能向任何人公开的内容。
Formal syntax is defined using ABNF [ABNF], extending the ABNF rules in Section 9 of [IMAP4]. Elements not defined here can be found in [ABNF], [IMAP4], [IMAPABNF], or [URI-GEN]. Strings are not case sensitive, and free insertion of linear white space is not permitted.
形式语法是使用ABNF[ABNF]定义的，扩展了[IMAP4]第9节中的ABNF规则。此处未定义的元素可以在[ABNF]、[IMAP4]、[IMAPABNF]或[URI-GEN]中找到。字符串不区分大小写，不允许自由插入线性空白。
sub-delims-sh = "!" / "$" / "'" / "(" / ")" /
"*" / "+" / ","
;; Same as [URI-GEN] sub-delims,
;; but without ";", "&" and "=".
sub-delims-sh = "!" / "$" / "'" / "(" / ")" /
"*" / "+" / ","
;; Same as [URI-GEN] sub-delims,
;; but without ";", "&" and "=".
uchar = unreserved / sub-delims-sh / pct-encoded
uchar = unreserved / sub-delims-sh / pct-encoded
achar = uchar / "&" / "="
;; Same as [URI-GEN] 'unreserved / sub-delims /
;; pct-encoded', but ";" is disallowed.
achar = uchar / "&" / "="
;; Same as [URI-GEN] 'unreserved / sub-delims /
;; pct-encoded', but ";" is disallowed.
bchar = achar / ":" / "@" / "/"
bchar = achar / ":" / "@" / "/"
enc-auth-type = 1*achar
; %-encoded version of [IMAP4] "auth-type"
enc-auth-type = 1*achar
; %-encoded version of [IMAP4] "auth-type"
enc-mailbox = 1*bchar
; %-encoded version of [IMAP4] "mailbox"
enc-mailbox = 1*bchar
; %-encoded version of [IMAP4] "mailbox"
enc-search = 1*bchar
; %-encoded version of [IMAPABNF]
; "search-program". Note that IMAP4
; literals may not be used in
; a "search-program", i.e., only
; quoted or non-synchronizing
; literals (if the server supports
; LITERAL+ [LITERAL+]) are allowed.
enc-search = 1*bchar
; %-encoded version of [IMAPABNF]
; "search-program". Note that IMAP4
; literals may not be used in
; a "search-program", i.e., only
; quoted or non-synchronizing
; literals (if the server supports
; LITERAL+ [LITERAL+]) are allowed.
enc-section = 1*bchar
; %-encoded version of [IMAP4] "section-spec"
enc-section = 1*bchar
; %-encoded version of [IMAP4] "section-spec"
enc-user = 1*achar
; %-encoded version of [IMAP4] authorization
; identity or "userid".
enc-user = 1*achar
; %-encoded version of [IMAP4] authorization
; identity or "userid".
imapurl = "imap://" iserver ipath-query
; Defines an absolute IMAP URL
imapurl = "imap://" iserver ipath-query
; Defines an absolute IMAP URL
ipath-query = ["/" [ icommand ]]
; Corresponds to "path-abempty [ "?" query ]"
; in [URI-GEN]
ipath-query = ["/" [ icommand ]]
; Corresponds to "path-abempty [ "?" query ]"
; in [URI-GEN]
Generic syntax for relative URLs is defined in Section 4.2 of [URI-GEN]. For ease of implementation, the relative IMAP URL syntax is defined below:
[URI-GEN]第4.2节定义了相对URL的通用语法。为便于实施，相对IMAP URL语法定义如下：
imapurl-rel = inetwork-path
imapurl-rel = inetwork-path
/ iabsolute-path
/ irelative-path
/ ipath-empty
/ iabsolute-path
/ irelative-path
/ ipath-empty
inetwork-path = "//" iserver ipath-query
; Corresponds to '"//" authority path-abempty
; [ "?" query ]' in [URI-GEN]
inetwork-path = "//" iserver ipath-query
; Corresponds to '"//" authority path-abempty
; [ "?" query ]' in [URI-GEN]
iabsolute-path = "/" [ icommand ]
; icommand, if present, MUST NOT start with '/'.
;
; Corresponds to 'path-absolute [ "?" query ]'
; in [URI-GEN]
iabsolute-path = "/" [ icommand ]
; icommand, if present, MUST NOT start with '/'.
;
; Corresponds to 'path-absolute [ "?" query ]'
; in [URI-GEN]
irelative-path = imessagelist / imsg-or-part ; Corresponds to 'path-noscheme [ "?" query ]' ; in [URI-GEN]
i相对路径=imessagelist/imsg或部分；对应于“路径noscheme[“？”查询]”；在[URI-GEN]中
imsg-or-part = ( imailbox-ref "/" iuid-only ["/" isection-only]
["/" ipartial-only] ) /
( iuid-only ["/" isection-only]
["/" ipartial-only] ) /
( isection-only ["/" ipartial-only] ) /
ipartial-only
imsg-or-part = ( imailbox-ref "/" iuid-only ["/" isection-only]
["/" ipartial-only] ) /
( iuid-only ["/" isection-only]
["/" ipartial-only] ) /
( isection-only ["/" ipartial-only] ) /
ipartial-only
ipath-empty = 0<pchar> ; Zero characters. ; The same-document reference.
ipath空=0<pchar>；零个字符；同一文件参考。
The following three rules are only used in the presence of the IMAP [URLAUTH] extension:
以下三条规则仅在存在IMAP[URLAUTH]扩展时使用：
authimapurl = "imap://" iserver "/" imessagepart
; Same as "imapurl" when "[icommand]" is
; "imessagepart"
authimapurl = "imap://" iserver "/" imessagepart
; Same as "imapurl" when "[icommand]" is
; "imessagepart"
authimapurlfull = authimapurl iurlauth ; Same as "imapurl" when "[icommand]" is ; "imessagepart iurlauth"
authimapurlfull=authimapurl iurlauth；当“[icommand]”为时，与“imapurl”相同；“imessagepart iurlauth”
authimapurlrump = authimapurl iurlauth-rump
authimapurlrump = authimapurl iurlauth-rump
enc-urlauth = 32*HEXDIG
enc urlauth=32*HEXDIG
iurlauth = iurlauth-rump iua-verifier
iurlauth = iurlauth-rump iua-verifier
iua-verifier = ":" uauth-mechanism ":" enc-urlauth
iua-verifier = ":" uauth-mechanism ":" enc-urlauth
iurlauth-rump = [expire] ";URLAUTH=" access
iurlauth-rump = [expire] ";URLAUTH=" access
access = ("submit+" enc-user) / ("user+" enc-user) /
"authuser" / "anonymous"
access = ("submit+" enc-user) / ("user+" enc-user) /
"authuser" / "anonymous"
expire = ";EXPIRE=" date-time
; date-time is defined in [DATETIME]
expire = ";EXPIRE=" date-time
; date-time is defined in [DATETIME]
uauth-mechanism = "INTERNAL" / 1*(ALPHA / DIGIT / "-" / ".")
; Case-insensitive.
; New mechanisms MUST be registered with IANA.
uauth-mechanism = "INTERNAL" / 1*(ALPHA / DIGIT / "-" / ".")
; Case-insensitive.
; New mechanisms MUST be registered with IANA.
iauth = ";AUTH=" ( "*" / enc-auth-type )
iauth = ";AUTH=" ( "*" / enc-auth-type )
icommand = imessagelist / imessagepart [iurlauth]
icommand=imessagelist/imessagepart[iurlauth]
imailbox-ref = enc-mailbox [uidvalidity]
imailbox ref=enc邮箱[UIDVality]
imessagelist = imailbox-ref [ "?" enc-search ] ; "enc-search" is [URI-GEN] "query".
imessagelist=iMail框参考[“？”加密搜索]；“enc搜索”是[URI-GEN]“查询”。
imessagepart = imailbox-ref iuid [isection] [ipartial]
imessagepart=iMail框参考iuid[isection][ipartial]
ipartial = "/" ipartial-only
ipartial=“/”仅ipartial
ipartial-only = ";PARTIAL=" partial-range
ipartial-only = ";PARTIAL=" partial-range
isection = "/" isection-only
isection=“/”仅isection
isection-only = ";SECTION=" enc-section
isection-only = ";SECTION=" enc-section
iserver = [iuserinfo "@"] host [ ":" port ]
; This is the same as "authority" defined
; in [URI-GEN]. See [URI-GEN] for "host"
; and "port" definitions.
iserver = [iuserinfo "@"] host [ ":" port ]
; This is the same as "authority" defined
; in [URI-GEN]. See [URI-GEN] for "host"
; and "port" definitions.
iuid = "/" iuid-only
iuid=“/”仅限iuid
iuid-only = ";UID=" nz-number
; See [IMAP4] for "nz-number" definition
iuid-only = ";UID=" nz-number
; See [IMAP4] for "nz-number" definition
iuserinfo = enc-user [iauth] / [enc-user] iauth ; conforms to the generic syntax of ; "userinfo" as defined in [URI-GEN].
iuserinfo=enc user[iauth]/[enc user]iauth；符合的通用语法；[URI-GEN]中定义的“用户信息”。
partial-range = number ["." nz-number]
; partial FETCH. The first number is
; the offset of the first byte,
; the second number is the length of
; the fragment.
partial-range = number ["." nz-number]
; partial FETCH. The first number is
; the offset of the first byte,
; the second number is the length of
; the fragment.
uidvalidity = ";UIDVALIDITY=" nz-number
; See [IMAP4] for "nz-number" definition
uidvalidity = ";UIDVALIDITY=" nz-number
; See [IMAP4] for "nz-number" definition
IANA has updated the "imap" definition in the "Uniform Resource Identifier scheme registry" to point to this document.
IANA已更新“统一资源标识符方案注册表”中的“imap”定义，以指向本文档。
The registration template (as per [URI-REG]) is specified in Section 12.1 of this document.
本文件第12.1节规定了注册模板（根据[URI-REG]）。
This section provides the information required to register the imap: URI scheme.
本节提供注册imap:URI方案所需的信息。
URI scheme name: imap
URI方案名称：imap
Status: permanent
地位：永久
URI scheme syntax:
URI方案语法：
See Section 11 of [RFC5092].
参见[RFC5092]第11节。
URI scheme semantics:
URI方案语义：
The imap: URI scheme is used to designate IMAP servers, mailboxes, messages, MIME bodies [MIME] and their parts, and search programs on Internet hosts accessible using the IMAP protocol.
imap:URI方案用于指定imap服务器、邮箱、消息、MIME主体[MIME]及其部分，以及使用imap协议访问的Internet主机上的搜索程序。
There is no MIME type associated with this URI.
没有与此URI关联的MIME类型。
Encoding considerations:
编码注意事项：
See Section 8 of [RFC5092].
参见[RFC5092]第8节。
Applications/protocols that use this URI scheme name:
使用此URI方案名称的应用程序/协议：
The imap: URI is intended to be used by applications that might need access to an IMAP mailstore. Such applications may include (but are not limited to) IMAP-capable web browsers; IMAP clients that wish to access a mailbox, message, or edit a message on the server using [CATENATE]; [SUBMIT] clients and servers that are requested to assemble a complete message on submission using [BURL].
imap:URI用于可能需要访问imap邮件存储的应用程序。此类应用程序可能包括（但不限于）支持IMAP的web浏览器；希望使用[CATENATE]访问服务器上的邮箱、邮件或编辑邮件的IMAP客户端；[SUBMIT]被请求使用[BURL]在提交时汇编完整消息的客户端和服务器。
Interoperability considerations:
互操作性注意事项：
A widely deployed IMAP client Netscape Mail (and possibly Mozilla/Thunderbird/Seamonkey) uses a different imap: scheme internally.
广泛部署的IMAP客户端Netscape Mail（可能还有Mozilla/Thunderbird/Seamonkey）在内部使用不同的IMAP:scheme。
Security considerations:
安全考虑：
See Security Considerations (Section 10) of [RFC5092].
参见[RFC5092]的安全注意事项（第10节）。
Contact:
联系人：
Alexey Melnikov <alexey.melnikov@isode.com>
Alexey Melnikov <alexey.melnikov@isode.com>
Author/Change controller:
作者/变更控制员：
IESG
IESG
References:
参考资料：
[RFC5092] and [IMAP4].
[RFC5092]和[IMAP4]。
[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月。
[IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP4]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[IMAPABNF] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006.
[IMAPABNF]Melnikov，A.和C.Daboo，“IMAP4 ABNF的收集扩展”，RFC 4466，2006年4月。
[ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[ABNF]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 42342005年10月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[URI-GEN] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[URI-GEN]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF-8]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, May 1998.
[名称空间]Gahrns，M.和C.Newman，“IMAP4名称空间”，RFC 23421998年5月。
[LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, January 1997.
[LITERAL+]Myers，J.，“IMAP4非同步文字”，RFC2088，1997年1月。
[ANONYMOUS] Zeilenga, K., "Anonymous Simple Authentication and Security Layer (SASL) Mechanism", RFC 4505, June 2006.
[匿名]Zeilenga，K.，“匿名简单身份验证和安全层（SASL）机制”，RFC 45052006年6月。
[DATETIME] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[日期时间]Klyne，G.和C.Newman，“互联网上的日期和时间：时间戳”，RFC 3339，2002年7月。
[URLAUTH] Crispin, M., "Internet Message Access Protocol (IMAP) - URLAUTH Extension", RFC 4467, May 2006.
[URLAUTH]Crispin，M.，“互联网消息访问协议（IMAP）-URLAUTH扩展”，RFC 4467，2006年5月。
[SUBMIT] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[提交]Gellens，R.和J.Klensin，“邮件信息提交”，RFC 4409，2006年4月。
[BURL] Newman, C., "Message Submission BURL Extension", RFC 4468, May 2006.
[BURL]Newman，C.，“消息提交BURL扩展”，RFC 4468，2006年5月。
[CATENATE] Resnick, P., "Internet Message Access Protocol (IMAP) CATENATE Extension", RFC 4469, April 2006.
[CATENATE]Resnick，P.，“互联网消息访问协议（IMAP）CATENATE扩展”，RFC 4469，2006年4月。
[SASL] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[SASL]Melnikov，A.，Ed.，和K.Zeilenga，Ed.，“简单身份验证和安全层（SASL）”，RFC 4422，2006年6月。
[GSSAPI] Melnikov, A., Ed., "The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism", RFC 4752, November 2006.
[GSSAPI]Melnikov，A.，Ed.，“Kerberos V5（“GSSAPI”）简单身份验证和安全层（SASL）机制”，RFC 47522006年11月。
[DIGEST-MD5] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000.
[DIGEST-MD5]Leach，P.和C.Newman，“使用摘要认证作为SASL机制”，RFC 28312000年5月。
[URI-REG] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 115, RFC 4395, February 2006.
[URI-REG]Hansen，T.，Hardie，T.，和L.Masinter，“新URI方案的指南和注册程序”，BCP 115，RFC 4395，2006年2月。
Here is sample C source code to convert between URL paths and IMAP mailbox names, taking into account mapping between IMAP's modified UTF-7 [IMAP4] and hex-encoded UTF-8, which is more appropriate for URLs. This code has not been rigorously tested nor does it necessarily behave reasonably with invalid input, but it should serve as a useful example. This code just converts the mailbox portion of the URL and does not deal with parameters, query, or server components of the URL.
下面是在URL路径和IMAP邮箱名称之间转换的示例C源代码，考虑到IMAP修改的UTF-7[IMAP4]和十六进制编码的UTF-8之间的映射，后者更适合URL。这段代码没有经过严格测试，也不一定在输入无效时表现合理，但它应该作为一个有用的示例。这段代码只转换URL的邮箱部分，不处理URL的参数、查询或服务器组件。
/* Copyright (C) The IETF Trust (2007). This version of
sample C code is part of RFC XXXX; see the RFC itself
for full legal notices.
/* Copyright (C) The IETF Trust (2007). This version of
sample C code is part of RFC XXXX; see the RFC itself
for full legal notices.
Regarding this sample C code (or any portion of it), the authors make no guarantees and are not responsible for any damage resulting from its use. The authors grant irrevocable permission to anyone to use, modify, and distribute it in any way that does not diminish the rights of anyone else to use, modify, and distribute it, provided that redistributed derivative works do not contain misleading author or version information.
关于此示例C代码（或其任何部分），作者不作任何保证，也不对其使用造成的任何损坏负责。作者向任何人授予不可撤销的许可，允许其以任何方式使用、修改和分发该作品，但不得削弱任何其他人使用、修改和分发该作品的权利，前提是重新分发的衍生作品不包含误导性的作者或版本信息。
Derivative works need not be licensed under similar terms. */
衍生作品无需根据类似条款获得许可*/
#include <stdio.h>
#include <string.h>
#include <stdio.h>
#include <string.h>
/* hexadecimal lookup table */
static const char hex[] = "0123456789ABCDEF";
/* hexadecimal lookup table */
static const char hex[] = "0123456789ABCDEF";
#define XX 127
/*
* Table for decoding hexadecimal in %encoding
*/
static const char index_hex[256] = {
XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
0, 1, 2, 3, 4, 5, 6, 7, 8, 9,XX,XX, XX,XX,XX,XX,
XX,10,11,12, 13,14,15,XX, XX,XX,XX,XX, XX,XX,XX,XX,
XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
XX,10,11,12, 13,14,15,XX, XX,XX,XX,XX, XX,XX,XX,XX,
XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
#define XX 127
/*
* Table for decoding hexadecimal in %encoding
*/
static const char index_hex[256] = {
XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
0, 1, 2, 3, 4, 5, 6, 7, 8, 9,XX,XX, XX,XX,XX,XX,
XX,10,11,12, 13,14,15,XX, XX,XX,XX,XX, XX,XX,XX,XX,
XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
XX,10,11,12, 13,14,15,XX, XX,XX,XX,XX, XX,XX,XX,XX,
XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, }; #define HEXCHAR(c) (index_hex[(unsigned char)(c)])
二十、 XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX，XX#定义HEXCHAR（c）（索引_hex[（无符号字符）（c）]）
/* "gen-delims" excluding "/" but including "%" */
#define GENERAL_DELIMS_NO_SLASH ":?#[]@" "%"
/* "gen-delims" excluding "/" but including "%" */
#define GENERAL_DELIMS_NO_SLASH ":?#[]@" "%"
/* "gen-delims" (excluding "/", but including "%")
plus subset of "sub-delims" */
#define GENERAL_UNSAFE_NO_SLASH GENERAL_DELIMS_NO_SLASH ";&=+"
#define OTHER_UNSAFE " \"<>\\^`{|}"
/* "gen-delims" (excluding "/", but including "%")
plus subset of "sub-delims" */
#define GENERAL_UNSAFE_NO_SLASH GENERAL_DELIMS_NO_SLASH ";&=+"
#define OTHER_UNSAFE " \"<>\\^`{|}"
/* URL unsafe printable characters */
static const char mailbox_url_unsafe[] = GENERAL_UNSAFE_NO_SLASH
OTHER_UNSAFE;
/* URL unsafe printable characters */
static const char mailbox_url_unsafe[] = GENERAL_UNSAFE_NO_SLASH
OTHER_UNSAFE;
/* UTF7 modified base64 alphabet */
static const char base64chars[] =
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+,";
/* UTF7 modified base64 alphabet */
static const char base64chars[] =
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+,";
#define UNDEFINED 64
#定义未定义的64
/* UTF16 definitions */
#define UTF16MASK 0x03FFUL
#define UTF16SHIFT 10
#define UTF16BASE 0x10000UL
#define UTF16HIGHSTART 0xD800UL
#define UTF16HIGHEND 0xDBFFUL
#define UTF16LOSTART 0xDC00UL
#define UTF16LOEND 0xDFFFUL
/* UTF16 definitions */
#define UTF16MASK 0x03FFUL
#define UTF16SHIFT 10
#define UTF16BASE 0x10000UL
#define UTF16HIGHSTART 0xD800UL
#define UTF16HIGHEND 0xDBFFUL
#define UTF16LOSTART 0xDC00UL
#define UTF16LOEND 0xDFFFUL
/* Convert an IMAP mailbox to a URL path
* dst needs to have roughly 4 times the storage space of src
* Hex encoding can triple the size of the input
* UTF-7 can be slightly denser than UTF-8
* (worst case: 8 octets UTF-7 becomes 9 octets UTF-8)
*/
void MailboxToURL(char *dst, char *src)
{
unsigned char c, i, bitcount;
unsigned long ucs4, utf16, bitbuf;
unsigned char base64[256], utf8[6];
/* Convert an IMAP mailbox to a URL path
* dst needs to have roughly 4 times the storage space of src
* Hex encoding can triple the size of the input
* UTF-7 can be slightly denser than UTF-8
* (worst case: 8 octets UTF-7 becomes 9 octets UTF-8)
*/
void MailboxToURL(char *dst, char *src)
{
unsigned char c, i, bitcount;
unsigned long ucs4, utf16, bitbuf;
unsigned char base64[256], utf8[6];
/* initialize modified base64 decoding table */
/* initialize modified base64 decoding table */
memset(base64, UNDEFINED, sizeof (base64));
for (i = 0; i < sizeof (base64chars); ++i) {
base64[(int) base64chars[i]] = i;
}
memset(base64, UNDEFINED, sizeof (base64));
for (i = 0; i < sizeof (base64chars); ++i) {
base64[(int) base64chars[i]] = i;
}
/* loop until end of string */
while (*src != '\0') {
c = *src++;
/* deal with literal characters and &- */
if (c != '&' || *src == '-') {
/* NB: There are no "URL safe" characters after the '~' */
if (c < ' ' || c > '~' ||
strchr(mailbox_url_unsafe, c) != NULL) {
/* hex encode if necessary */
dst[0] = '%';
dst[1] = hex[c >> 4];
dst[2] = hex[c & 0x0f];
dst += 3;
} else {
/* encode literally */
*dst++ = c;
}
/* skip over the '-' if this is an &- sequence */
if (c == '&') ++src;
/* loop until end of string */
while (*src != '\0') {
c = *src++;
/* deal with literal characters and &- */
if (c != '&' || *src == '-') {
/* NB: There are no "URL safe" characters after the '~' */
if (c < ' ' || c > '~' ||
strchr(mailbox_url_unsafe, c) != NULL) {
/* hex encode if necessary */
dst[0] = '%';
dst[1] = hex[c >> 4];
dst[2] = hex[c & 0x0f];
dst += 3;
} else {
/* encode literally */
*dst++ = c;
}
/* skip over the '-' if this is an &- sequence */
if (c == '&') ++src;
} else {
/* convert modified UTF-7 -> UTF-16 -> UCS-4 -> UTF-8 -> HEX */
bitbuf = 0;
bitcount = 0;
ucs4 = 0;
while ((c = base64[(unsigned char) *src]) != UNDEFINED) {
++src;
bitbuf = (bitbuf << 6) | c;
bitcount += 6;
/* enough bits for a UTF-16 character? */
if (bitcount >= 16) {
bitcount -= 16;
utf16 = (bitcount ? bitbuf >> bitcount
: bitbuf) & 0xffff;
/* convert UTF16 to UCS4 */
if
(utf16 >= UTF16HIGHSTART && utf16 <= UTF16HIGHEND) {
ucs4 = (utf16 - UTF16HIGHSTART) << UTF16SHIFT;
continue;
} else if
(utf16 >= UTF16LOSTART && utf16 <= UTF16LOEND) {
ucs4 += utf16 - UTF16LOSTART + UTF16BASE;
} else {
} else {
/* convert modified UTF-7 -> UTF-16 -> UCS-4 -> UTF-8 -> HEX */
bitbuf = 0;
bitcount = 0;
ucs4 = 0;
while ((c = base64[(unsigned char) *src]) != UNDEFINED) {
++src;
bitbuf = (bitbuf << 6) | c;
bitcount += 6;
/* enough bits for a UTF-16 character? */
if (bitcount >= 16) {
bitcount -= 16;
utf16 = (bitcount ? bitbuf >> bitcount
: bitbuf) & 0xffff;
/* convert UTF16 to UCS4 */
if
(utf16 >= UTF16HIGHSTART && utf16 <= UTF16HIGHEND) {
ucs4 = (utf16 - UTF16HIGHSTART) << UTF16SHIFT;
continue;
} else if
(utf16 >= UTF16LOSTART && utf16 <= UTF16LOEND) {
ucs4 += utf16 - UTF16LOSTART + UTF16BASE;
} else {
ucs4 = utf16;
}
/* convert UTF-16 range of UCS4 to UTF-8 */
if (ucs4 <= 0x7fUL) {
utf8[0] = (unsigned char) ucs4;
i = 1;
} else if (ucs4 <= 0x7ffUL) {
utf8[0] = 0xc0 | (unsigned char) (ucs4 >> 6);
utf8[1] = 0x80 | (unsigned char) (ucs4 & 0x3f);
i = 2;
} else if (ucs4 <= 0xffffUL) {
utf8[0] = 0xe0 | (unsigned char) (ucs4 >> 12);
utf8[1] = 0x80 | (unsigned char) ((ucs4 >> 6) & 0x3f);
utf8[2] = 0x80 | (unsigned char) (ucs4 & 0x3f);
i = 3;
} else {
utf8[0] = 0xf0 | (unsigned char) (ucs4 >> 18);
utf8[1] = 0x80 | (unsigned char) ((ucs4 >> 12) & 0x3f);
utf8[2] = 0x80 | (unsigned char) ((ucs4 >> 6) & 0x3f);
utf8[3] = 0x80 | (unsigned char) (ucs4 & 0x3f);
i = 4;
}
/* convert utf8 to hex */
for (c = 0; c < i; ++c) {
dst[0] = '%';
dst[1] = hex[utf8[c] >> 4];
dst[2] = hex[utf8[c] & 0x0f];
dst += 3;
}
}
}
/* skip over trailing '-' in modified UTF-7 encoding */
if (*src == '-') ++src;
}
}
/* terminate destination string */
*dst = '\0';
}
ucs4 = utf16;
}
/* convert UTF-16 range of UCS4 to UTF-8 */
if (ucs4 <= 0x7fUL) {
utf8[0] = (unsigned char) ucs4;
i = 1;
} else if (ucs4 <= 0x7ffUL) {
utf8[0] = 0xc0 | (unsigned char) (ucs4 >> 6);
utf8[1] = 0x80 | (unsigned char) (ucs4 & 0x3f);
i = 2;
} else if (ucs4 <= 0xffffUL) {
utf8[0] = 0xe0 | (unsigned char) (ucs4 >> 12);
utf8[1] = 0x80 | (unsigned char) ((ucs4 >> 6) & 0x3f);
utf8[2] = 0x80 | (unsigned char) (ucs4 & 0x3f);
i = 3;
} else {
utf8[0] = 0xf0 | (unsigned char) (ucs4 >> 18);
utf8[1] = 0x80 | (unsigned char) ((ucs4 >> 12) & 0x3f);
utf8[2] = 0x80 | (unsigned char) ((ucs4 >> 6) & 0x3f);
utf8[3] = 0x80 | (unsigned char) (ucs4 & 0x3f);
i = 4;
}
/* convert utf8 to hex */
for (c = 0; c < i; ++c) {
dst[0] = '%';
dst[1] = hex[utf8[c] >> 4];
dst[2] = hex[utf8[c] & 0x0f];
dst += 3;
}
}
}
/* skip over trailing '-' in modified UTF-7 encoding */
if (*src == '-') ++src;
}
}
/* terminate destination string */
*dst = '\0';
}
/* Convert hex coded UTF-8 URL path to modified UTF-7 IMAP mailbox
* dst should be about twice the length of src to deal with non-hex
* coded URLs
*/
int URLtoMailbox(char *dst, char *src)
{
unsigned int utf8pos = 0;
unsigned int utf8total, i, c, utf7mode, bitstogo, utf16flag;
unsigned long ucs4 = 0, bitbuf = 0;
/* Convert hex coded UTF-8 URL path to modified UTF-7 IMAP mailbox
* dst should be about twice the length of src to deal with non-hex
* coded URLs
*/
int URLtoMailbox(char *dst, char *src)
{
unsigned int utf8pos = 0;
unsigned int utf8total, i, c, utf7mode, bitstogo, utf16flag;
unsigned long ucs4 = 0, bitbuf = 0;
utf7mode = 0; /* is the output UTF7 currently in base64 mode? */
utf8total = 0; /* how many octets is the current input UTF-8 char;
0 == between characters */
bitstogo = 0; /* bits that need to be encoded into base64; if
bitstogo != 0 then utf7mode == 1 */
while ((c = (unsigned char)*src) != '\0') {
++src;
/* undo hex-encoding */
if (c == '%' && src[0] != '\0' && src[1] != '\0') {
c = HEXCHAR(src[0]);
i = HEXCHAR(src[1]);
if (c == XX || i == XX) {
return 0;
} else {
c = (char)((c << 4) | i);
}
src += 2;
}
/* normal character? */
if (c >= ' ' && c <= '~') {
/* switch out of UTF-7 mode */
if (utf7mode) {
if (bitstogo) {
*dst++ = base64chars[(bitbuf << (6 - bitstogo)) & 0x3F];
}
*dst++ = '-';
utf7mode = 0;
bitstogo = bitbuf = 0;
}
*dst++ = c;
/* encode '&' as '&-' */
if (c == '&') {
*dst++ = '-';
}
continue;
}
/* switch to UTF-7 mode */
if (!utf7mode) {
*dst++ = '&';
utf7mode = 1;
}
/* Encode US-ASCII characters as themselves */
if (c < 0x80) {
ucs4 = c;
utf8total = 1;
} else if (utf8total) {
/* this is a subsequent octet of a multi-octet character */
/* save UTF8 bits into UCS4 */
utf7mode = 0; /* is the output UTF7 currently in base64 mode? */
utf8total = 0; /* how many octets is the current input UTF-8 char;
0 == between characters */
bitstogo = 0; /* bits that need to be encoded into base64; if
bitstogo != 0 then utf7mode == 1 */
while ((c = (unsigned char)*src) != '\0') {
++src;
/* undo hex-encoding */
if (c == '%' && src[0] != '\0' && src[1] != '\0') {
c = HEXCHAR(src[0]);
i = HEXCHAR(src[1]);
if (c == XX || i == XX) {
return 0;
} else {
c = (char)((c << 4) | i);
}
src += 2;
}
/* normal character? */
if (c >= ' ' && c <= '~') {
/* switch out of UTF-7 mode */
if (utf7mode) {
if (bitstogo) {
*dst++ = base64chars[(bitbuf << (6 - bitstogo)) & 0x3F];
}
*dst++ = '-';
utf7mode = 0;
bitstogo = bitbuf = 0;
}
*dst++ = c;
/* encode '&' as '&-' */
if (c == '&') {
*dst++ = '-';
}
continue;
}
/* switch to UTF-7 mode */
if (!utf7mode) {
*dst++ = '&';
utf7mode = 1;
}
/* Encode US-ASCII characters as themselves */
if (c < 0x80) {
ucs4 = c;
utf8total = 1;
} else if (utf8total) {
/* this is a subsequent octet of a multi-octet character */
/* save UTF8 bits into UCS4 */
ucs4 = (ucs4 << 6) | (c & 0x3FUL);
if (++utf8pos < utf8total) {
continue;
}
} else {
/* this is the first octet of a multi-octet character */
utf8pos = 1;
if (c < 0xE0) {
utf8total = 2;
ucs4 = c & 0x1F;
} else if (c < 0xF0) {
utf8total = 3;
ucs4 = c & 0x0F;
} else {
/* NOTE: can't convert UTF8 sequences longer than 4 */
utf8total = 4;
ucs4 = c & 0x03;
}
continue;
}
/* Finished with UTF-8 character. Make sure it isn't an
overlong sequence. If it is, return failure. */
if ((ucs4 < 0x80 && utf8total > 1) ||
(ucs4 < 0x0800 && utf8total > 2) ||
(ucs4 < 0x00010000 && utf8total > 3) ||
(ucs4 < 0x00200000 && utf8total > 4) ||
(ucs4 < 0x04000000 && utf8total > 5) ||
(ucs4 < 0x80000000 && utf8total > 6)) {
return 0;
}
/* loop to split ucs4 into two utf16 chars if necessary */
utf8total = 0;
do {
if (ucs4 >= UTF16BASE) {
ucs4 -= UTF16BASE;
bitbuf = (bitbuf << 16) | ((ucs4 >> UTF16SHIFT)
+ UTF16HIGHSTART);
ucs4 = (ucs4 & UTF16MASK) + UTF16LOSTART;
utf16flag = 1;
} else {
bitbuf = (bitbuf << 16) | ucs4;
utf16flag = 0;
}
bitstogo += 16;
/* spew out base64 */
while (bitstogo >= 6) {
bitstogo -= 6;
*dst++ = base64chars[(bitstogo ? (bitbuf >> bitstogo)
ucs4 = (ucs4 << 6) | (c & 0x3FUL);
if (++utf8pos < utf8total) {
continue;
}
} else {
/* this is the first octet of a multi-octet character */
utf8pos = 1;
if (c < 0xE0) {
utf8total = 2;
ucs4 = c & 0x1F;
} else if (c < 0xF0) {
utf8total = 3;
ucs4 = c & 0x0F;
} else {
/* NOTE: can't convert UTF8 sequences longer than 4 */
utf8total = 4;
ucs4 = c & 0x03;
}
continue;
}
/* Finished with UTF-8 character. Make sure it isn't an
overlong sequence. If it is, return failure. */
if ((ucs4 < 0x80 && utf8total > 1) ||
(ucs4 < 0x0800 && utf8total > 2) ||
(ucs4 < 0x00010000 && utf8total > 3) ||
(ucs4 < 0x00200000 && utf8total > 4) ||
(ucs4 < 0x04000000 && utf8total > 5) ||
(ucs4 < 0x80000000 && utf8total > 6)) {
return 0;
}
/* loop to split ucs4 into two utf16 chars if necessary */
utf8total = 0;
do {
if (ucs4 >= UTF16BASE) {
ucs4 -= UTF16BASE;
bitbuf = (bitbuf << 16) | ((ucs4 >> UTF16SHIFT)
+ UTF16HIGHSTART);
ucs4 = (ucs4 & UTF16MASK) + UTF16LOSTART;
utf16flag = 1;
} else {
bitbuf = (bitbuf << 16) | ucs4;
utf16flag = 0;
}
bitstogo += 16;
/* spew out base64 */
while (bitstogo >= 6) {
bitstogo -= 6;
*dst++ = base64chars[(bitstogo ? (bitbuf >> bitstogo)
: bitbuf)
& 0x3F];
}
} while (utf16flag);
}
/* if in UTF-7 mode, finish in ASCII */
if (utf7mode) {
if (bitstogo) {
*dst++ = base64chars[(bitbuf << (6 - bitstogo)) & 0x3F];
}
*dst++ = '-';
}
/* tie off string */
*dst = '\0';
return 1;
}
: bitbuf)
& 0x3F];
}
} while (utf16flag);
}
/* if in UTF-7 mode, finish in ASCII */
if (utf7mode) {
if (bitstogo) {
*dst++ = base64chars[(bitbuf << (6 - bitstogo)) & 0x3F];
}
*dst++ = '-';
}
/* tie off string */
*dst = '\0';
return 1;
}
Updated boilerplate, list of editor's, etc. Updated references. Updated ABNF not to use _, to use SP instead of SPACE, etc. Updated example domains to use example.org. Fixed ABNF error in "imessagelist" non-terminal. Updated ABNF, due to changes in RFC 3501, RFC 4466, and RFC 3986. Renamed "iuserauth" non-terminal to <iuserinfo>. Clarified that the userinfo component describes both authorization identity and mailbox naming scope. Allow for non-synchronizing literals in "enc-search". Added "ipartial" specifier that denotes a partial FETCH. Moved URLAUTH text from RFC 4467 to this document. Updated ABNF for the whole server to allow missing trailing "/" (e.g., "imap://imap.example.com" is now valid and is the same as "imap://imap.example.com/"). Clarified how relative-path references are constructed. Added more examples demonstrating relative-path references. Added rules for relative URLs and restructured ABNF as the result. Removed text on use of relative URLs in MHTML. Added examples demonstrating security considerations when resolving URLs. Recommend usage of STARTTLS/SASL security layer to protect confidential data. Removed some advices about connection reuse that were incorrect. Removed URLs referencing a list of mailboxes, as this feature hasn't seen any deployments. Clarified that user name "anonymous" is case-insensitive.
更新的样板文件、编辑列表等。更新的参考资料。更新了ABNF以不使用u，使用SP而不是空格等。更新了示例域以使用example.org。修复了“imessagelist”非终端中的ABNF错误。由于RFC 3501、RFC 4466和RFC 3986的变更，更新了ABNF。将“iuserauth”非终端重命名为<iuserinfo>。阐明userinfo组件描述授权标识和邮箱命名范围。允许在“enc搜索”中使用非同步文字。添加了表示部分提取的“ipartial”说明符。已将URLAUTH文本从RFC 4467移动到此文档。已更新整个服务器的ABNF，以允许缺少尾随“/”（例如“imap://imap.example.com“现在有效，与”imap://imap.example.com/"). 阐明了如何构造相对路径引用。添加了更多演示相对路径引用的示例。添加了相对URL的规则，并因此重组了ABNF。删除了在MHTML中使用相对URL的文本。添加了示例，演示解析URL时的安全注意事项。建议使用STARTTLS/SASL安全层来保护机密数据。删除了一些关于连接重用的不正确建议。已删除引用邮箱列表的URL，因为此功能尚未看到任何部署。澄清用户名“匿名”不区分大小写。
Renamed <mechanism> to <uauth-mechanism>. Restructured ABNF.
将<mechanism>重命名为<uauth mechanism>。重组荷兰银行。
Text describing URLAUTH was lifted from [URLAUTH] by Mark Crispin.
描述URLAUTH的文本由Mark Crispin从[URLAUTH]中提取。
Stephane H. Maes contributed some ideas to this document; he also co-edited early versions of this document.
Stephane H.Maes为本文件提供了一些想法；他还共同编辑了该文件的早期版本。
The editors would like to thank Mark Crispin, Ken Murchison, Ted Hardie, Zoltan Ordogh, Dave Cridland, Kjetil Torgrim Homme, Lisa Dusseault, Spencer Dawkins, Filip Navara, Shawn M. Emery, Sam Hartman, Russ Housley, and Lars Eggert for the time they devoted to reviewing this document and/or for the comments received.
编辑们要感谢马克·克里斯宾、肯·默奇森、特德·哈迪、佐尔坦·奥多格、戴夫·克里德兰、克杰蒂尔·托格里姆·霍姆、丽莎·杜肖奥、斯宾塞·道金斯、菲利普·纳瓦拉、肖恩·埃默里、萨姆·哈特曼、罗斯·霍斯利和拉尔斯·艾格特，感谢他们花时间审查本文件和/或收到的评论。
Authors' Addresses
作者地址
Chris Newman (Author/Editor) Sun Microsystems 3401 Centrelake Dr., Suite 410 Ontario, CA 91761 EMail: chris.newman@sun.com
Chris Newman（作者/编辑）Sun Microsystems 3401 Centrelake Dr.，加利福尼亚州安大略省410号套房91761电子邮件：Chris。newman@sun.com
Alexey Melnikov (Editor) Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX, UK EMail: Alexey.Melnikov@isode.com URI: http://www.melnikov.ca/
Alexey Melnikov（编辑）英国米德尔塞克斯郡汉普顿车站路36号城堡商业村5号有限公司TW12 2BX电子邮件：Alexey。Melnikov@isode.comURI:http://www.melnikov.ca/
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.