Network Working Group N. Cook
Request for Comments: 5593 Cloudmark
Updates: 5092 June 2009
Category: Standards Track
Network Working Group N. Cook
Request for Comments: 5593 Cloudmark
Updates: 5092 June 2009
Category: Standards Track
Internet Message Access Protocol (IMAP) - URL Access Identifier Extension
Internet消息访问协议（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）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
The existing IMAP URL specification (RFC 5092) lists several <access> identifiers and <access> identifier prefixes that can be used to restrict access to URLAUTH-generated URLs. However, these identifiers do not provide facilities for new services such as streaming. This document proposes a set of new <access> identifiers as well as an IANA mechanism to register new <access> identifiers for future applications.
现有的IMAP URL规范（RFC 5092）列出了几个<access>标识符和<access>标识符前缀，可用于限制对URLAUTH生成的URL的访问。但是，这些标识符不为流式传输等新服务提供便利。本文档提出了一组新的<access>标识符以及一种IANA机制，用于为未来的应用程序注册新的<access>标识符。
This document updates RFC 5092.
本文档更新了RFC 5092。
Table of Contents
目录
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. Additional Authorized Access Identifiers ........................3
3.1. Existing Access Identifiers ................................3
3.2. Requirement for Additional Access Identifiers ..............3
3.3. Additional Access Identifier Specification .................4
3.4. Defining an Access Identifier for Streaming ................5
4. Formal Syntax ...................................................5
5. Acknowledgements ................................................6
6. IANA Considerations .............................................6
6.1. Access Identifier Registration Template ....................7
6.2. Stream Application Registration ............................7
6.3. Submit Application Registration ............................8
6.4. User Application Registration ..............................8
6.5. Authuser Application Registration ..........................9
6.6. Anonymous Application Registration .........................9
7. Security Considerations .........................................9
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. Additional Authorized Access Identifiers ........................3
3.1. Existing Access Identifiers ................................3
3.2. Requirement for Additional Access Identifiers ..............3
3.3. Additional Access Identifier Specification .................4
3.4. Defining an Access Identifier for Streaming ................5
4. Formal Syntax ...................................................5
5. Acknowledgements ................................................6
6. IANA Considerations .............................................6
6.1. Access Identifier Registration Template ....................7
6.2. Stream Application Registration ............................7
6.3. Submit Application Registration ............................8
6.4. User Application Registration ..............................8
6.5. Authuser Application Registration ..........................9
6.6. Anonymous Application Registration .........................9
7. Security Considerations .........................................9
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
The IMAP URL specification [RFC5092] provides a way to carry authorization information in IMAP URLs. Several authorization <access> identifiers are specified in the document that allow URLAUTH-authorized URLs to be used only by anonymous users, authenticated users, or message submission entities. However, there is no mechanism defined to create new <access> identifiers, and overloading the existing mechanisms has security as well as administrative implications.
IMAP URL规范[RFC5092]提供了一种在IMAP URL中携带授权信息的方法。文档中指定了多个授权<access>标识符，这些标识符允许URLAUTH授权URL仅由匿名用户、经过身份验证的用户或消息提交实体使用。但是，没有定义任何机制来创建新的<access>标识符，并且重载现有机制会带来安全性和管理方面的影响。
This document describes a new <access> identifier, "stream", to be used by message streaming entities (as described in [STREAMING]), and defines an IANA registration template, which can be used to register new <access> identifiers for future applications. IANA definitions for the existing access identifiers and prefixes from RFC 5092 are also defined in this document -- this document updates RFC 5092 and should be taken as the master in the event of any differences or discrepancies.
本文档描述了一个新的<access>标识符“stream”，将由消息流实体使用（如[streaming]中所述），并定义了一个IANA注册模板，该模板可用于注册新的<access>标识符以供将来的应用。本文件中还定义了RFC 5092中现有访问标识符和前缀的IANA定义——本文件更新了RFC 5092，如果存在任何差异或不一致，应将其视为主文件。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively. If a single "C:" or "S:" label applies to multiple lines, then some of the line breaks between those lines are for editorial clarity only and may not be part of the actual protocol exchange.
在示例中，“C:”和“S:”分别表示客户端和服务器发送的行。如果单个“C:”或“S:”标签适用于多行，则这些行之间的一些换行符仅用于编辑清晰性，可能不是实际协议交换的一部分。
The IMAP URL specification [RFC5092] specifies the following authorized <access> identifiers:
IMAP URL规范[RFC5092]指定了以下授权<access>标识符：
o "authuser" - Indicates that use of this URL is limited to authenticated IMAP sessions that are logged in as any non-anonymous user.
o “authuser”-表示此URL的使用仅限于以任何非匿名用户身份登录的经过身份验证的IMAP会话。
o "anonymous" - Indicates that use of this URL is not restricted by session authorization identity.
o “匿名”-表示此URL的使用不受会话授权标识的限制。
Additionally, the following <access> identifier prefixes are defined in [RFC5092]:
此外，[RFC5092]中定义了以下<access>标识符前缀：
o "submit+" - 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.
o “submit+”-后跟用户ID，表示仅允许代表指定用户ID授权为消息提交实体的用户ID使用此URL。
o "user+" - Followed by a userid, indicates that use of this URL is limited to IMAP sessions that are logged in as the specified userid.
o “user+”-后跟用户ID，表示此URL的使用仅限于以指定用户ID登录的IMAP会话。
The existing <access> identifiers are suitable for user-based authorization, but only the "submit+" <access> identifier prefix is suitable for entities acting on behalf of a user. Generic support for external entities acting on behalf of users is required for new services such as streaming [STREAMING].
现有的<access>标识符适用于基于用户的授权，但只有“submit+”<access>标识符前缀适用于代表用户的实体。对于流媒体[流媒体]等新服务，需要为代表用户的外部实体提供通用支持。
The "submit+" <access> identifier prefix is not suitable for use as a general mechanism to grant access to entities acting on behalf of users, for reasons that include:
“submit+”<access>标识符前缀不适合用作向代表用户的实体授予访问权限的一般机制，原因包括：
o Security - The IMAP server maintains a list of submission server entities that are entitled to retrieve IMAP URLs specifying the "submit+" <access> identifier prefix. If this list is extended to include the set of all external entities that could act on behalf of users, then the attack surface would be increased.
o 安全性-IMAP服务器维护有权检索IMAP URL的提交服务器实体列表，指定“提交+”<access>标识符前缀。如果将此列表扩展为包含可代表用户行事的所有外部实体的集合，则攻击面将增加。
o Administration - When URLAUTH-style IMAP URLs are presented to an IMAP server by entities acting on behalf of users, the server administrator has no way of determining the intended use of that URL from the server logs.
o 管理-当代表用户的实体将URLAUTH样式的IMAP URL呈现给IMAP服务器时，服务器管理员无法从服务器日志中确定该URL的预期用途。
o Resourcing - Without a mechanism to distinguish between the application for which an IMAP URL is to be used, the IMAP server has no way to prioritize resources for particular applications. For example, the server could prioritize "submit+" URL fetch requests over other access identifiers.
o 资源分配-如果没有一种机制来区分要使用IMAP URL的应用程序，IMAP服务器就无法对特定应用程序的资源进行优先级排序。例如，服务器可以将“提交+”URL获取请求优先于其他访问标识符。
The previous section establishes that additional access identifiers are required to support applications, such as streaming [STREAMING], that require entities to retrieve URLAUTH URLs on behalf of users. This section describes the scope and meaning of any additional <access> identifiers that are created.
上一节确定了需要额外的访问标识符来支持应用程序，例如流[streaming]，这些应用程序要求实体代表用户检索URLAUTH URL。本节描述创建的任何附加<access>标识符的范围和含义。
Additional <access> identifiers MUST take one of two forms (Section 4 gives the formal ABNF syntax):
附加<access>标识符必须采用两种形式之一（第4节给出了ABNF的正式语法）：
o <access> identifier - The name of the application, e.g., "exampleapp".
o <access>identifier—应用程序的名称，例如“exampleapp”。
o <access> identifier prefix - The name of the application, e.g., "exampleapp3", followed by a "+" and then a userid. For example, consider "exampleapp3+testuser".
o <access>标识符前缀-应用程序的名称，例如，“exampleapp3”，后跟“+”和用户ID。例如，考虑“ExpultApp3+TestPuthor”。
Note that an <access> identifier name can also be registered as an <access> identifier prefix. However, this would require 2 separate IANA registrations.
请注意，<access>标识符名称也可以注册为<access>标识符前缀。然而，这需要两个独立的IANA注册。
In both cases, the semantics are the same as those for "submit+", i.e., the <access> identifier or <access> identifier prefix (which MUST be followed by a userid) indicates that only a userid authorized as an application entity for the specified application is permitted to use this URL. In the case of <access> identifier prefixes, the IMAP server SHALL NOT validate the specified userid but MUST validate that the IMAP session has an authorization identity that is authorized as an application entity for the specified application.
在这两种情况下，语义与“submit+”的语义相同，即<access>标识符或<access>标识符前缀（后面必须跟一个userid）表示只有授权为指定应用程序的应用程序实体的userid才允许使用此URL。对于<access>标识符前缀，IMAP服务器不应验证指定的用户ID，但必须验证IMAP会话是否具有作为指定应用程序的应用程序实体授权的授权标识。
The application entity itself MAY choose to perform validation on any specified userid before attempting to retrieve the URL.
在尝试检索URL之前，应用程序实体本身可以选择对任何指定的用户ID执行验证。
The authorization granted by any <access> identifiers used as described above is self-describing, and so requires that the IMAP server provide an extensible mechanism for associating userids with new applications. For example, imagine a new application, "foo", is created that requires application entities to retrieve URLs on behalf of users. In this case, the IMAP server would need to provide a way to register the new application "foo" and to associate the set of userids to be used by those entities with the application "foo". Any attempt to retrieve URLs containing the <access> identifier "foo" would be checked for authorization against the list of userids associated with the application "foo".
如上所述使用的任何<access>标识符所授予的授权都是自描述的，因此需要IMAP服务器提供一种可扩展的机制，用于将用户ID与新应用程序关联起来。例如，假设创建了一个新的应用程序“foo”，它要求应用程序实体代表用户检索URL。在这种情况下，IMAP服务器需要提供一种方法来注册新的应用程序“foo”，并将这些实体使用的用户ID集与应用程序“foo”关联起来。任何检索包含<access>标识符“foo”的URL的尝试都将根据与应用程序“foo”关联的用户ID列表进行授权检查。
Section 6 provides the template required to register new <access> identifiers or prefixes with IANA.
第6节提供了向IANA注册新的<access>标识符或前缀所需的模板。
One application that makes use of URLAUTH-authorized URLs is that of streaming multimedia files that are received as internet-messaging attachments. This application is described in [STREAMING].
使用URLAUTH授权URL的一个应用程序是作为internet消息附件接收的流媒体文件。此应用程序在[STREAMING]中进行了描述。
See Section 6.2 for the IANA registration template for the "stream" <access> identifier.
有关“流”<access>标识符的IANA注册模板，请参见第6.2节。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234].
以下语法规范使用[RFC5234]中指定的增广巴科斯诺尔形式（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.
除非另有说明，否则所有字母字符都不区分大小写。使用大写或小写字符定义标记字符串仅用于编辑清晰性。实现必须以不区分大小写的方式接受这些字符串。
The ABNF specified below updates the formal syntax of <access> identifiers as defined in IMAP URL [RFC5092].
下面指定的ABNF更新了IMAP URL[RFC5092]中定义的<access>标识符的正式语法。
Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved.
版权所有（c）2009 IETF信托基金和被确定为代码作者的人员。版权所有。
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
在满足以下条件的情况下，允许以源代码和二进制格式重新分发和使用，无论是否修改：
- Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
- 源代码的重新分发必须保留上述版权声明、此条件列表和以下免责声明。
- Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
- 以二进制形式重新分发时，必须在分发时提供的文档和/或其他材料中复制上述版权声明、本条件列表和以下免责声明。
- Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission.
- 未经事先书面许可，不得使用互联网协会、IETF或IETF Trust的名称或特定贡献者的名称来认可或推广源自本软件的产品。
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
本软件由版权所有人和贡献者提供，仅限于以下内容，对适销性和特定用途适用性的默示保证不承担任何责任。在任何情况下，版权所有人或贡献者均不对任何直接、间接、偶然、特殊、惩戒性或后果性损害（包括但不限于替代商品或服务的采购；使用、数据或利润的损失；或业务中断）负责，无论是在合同中还是在任何责任理论下，严格责任，或因使用本软件而产生的侵权行为（包括疏忽或其他），即使告知可能发生此类损害。
application = 1*(ALPHA/DIGIT)
application = 1*(ALPHA/DIGIT)
access =/ application / (application "+" enc-user)
access =/ application / (application "+" enc-user)
This document was inspired by discussions in the Lemonade Working Group.
本文件受柠檬水工作组讨论的启发。
IANA created a new registry for IMAP URLAUTH access identifiers and prefixes.
IANA为IMAP URLAUTH访问标识符和前缀创建了一个新的注册表。
Access identifiers and prefixes MUST be registered using the "IETF Review" policy [RFC5226]. This section gives the IANA registration entries for the existing access identifiers and prefixes from RFC 5092 as well as the entry for the "stream" application.
必须使用“IETF审查”策略[RFC5226]注册访问标识符和前缀。本节给出了RFC 5092中现有访问标识符和前缀的IANA注册条目以及“流”应用程序的条目。
To: iana@iana.org Subject: IMAP URL Access Identifier Registration
致：iana@iana.org主题：IMAP URL访问标识符注册
Type: [Either "<access> identifier" or
"<access> identifier prefix"]
Type: [Either "<access> identifier" or
"<access> identifier prefix"]
Application: [Name of the application, e.g., "stream"]
应用程序：[应用程序的名称，例如，“流”]
Description: [A description of the application and its use of IMAP URLs]
Description:[应用程序及其IMAP URL使用的说明]
RFC Number: [Number of the RFC in which the application is defined]
RFC编号：[定义应用程序的RFC编号]
Contact: [Email and/or physical address to contact for additional information]
联系人：[有关更多信息，请发送电子邮件和/或实际联系地址]
To: iana@iana.org Subject: IMAP URL Access Identifier Registration
致：iana@iana.org主题：IMAP URL访问标识符注册
Type: <access> identifier
Type: <access> identifier
Application: stream
应用：流
Description: Used by SIP Media Servers to retrieve attachments for streaming to email clients
描述：由SIP媒体服务器用于检索附件，以便流式传输到电子邮件客户端
RFC Number: RFC 5593
RFC编号：RFC 5593
Contact: Neil Cook <neil.cook@noware.co.uk>
Contact: Neil Cook <neil.cook@noware.co.uk>
To: iana@iana.org Subject: IMAP URL Access Identifier Registration
致：iana@iana.org主题：IMAP URL访问标识符注册
Type: <access> identifier prefix
Type: <access> identifier prefix
Application: submit
申请：提交
Description: Used by message submission entities to retrieve attachments to be included in submitted messages
描述：邮件提交实体用于检索要包含在已提交邮件中的附件
RFC Number: RFC 5593 and RFC 5092
RFC编号：RFC 5593和RFC 5092
Contact: Lemonade WG <lemonade@ietf.org>
Contact: Lemonade WG <lemonade@ietf.org>
To: iana@iana.org Subject: IMAP URL Access Identifier Registration
致：iana@iana.org主题：IMAP URL访问标识符注册
Type: <access> identifier prefix
Type: <access> identifier prefix
Application: user
应用：用户
Description: Used to restrict access to IMAP sessions that are logged in as the specified userid
描述：用于限制对以指定用户ID登录的IMAP会话的访问
RFC Number: RFC 5593 and RFC 5092
RFC编号：RFC 5593和RFC 5092
Contact: Lemonade WG <lemonade@ietf.org>
Contact: Lemonade WG <lemonade@ietf.org>
To: iana@iana.org Subject: IMAP URL Access Identifier Registration
致：iana@iana.org主题：IMAP URL访问标识符注册
Type: <access> identifier
Type: <access> identifier
Application: authuser
应用程序：authuser
Description: Used to restrict access to IMAP sessions that are logged in as any non-anonymous user of that IMAP server
描述：用于限制以该IMAP服务器的任何非匿名用户身份登录的IMAP会话的访问
RFC Number: RFC 5593 and RFC 5092
RFC编号：RFC 5593和RFC 5092
Contact: Lemonade WG <lemonade@ietf.org>
Contact: Lemonade WG <lemonade@ietf.org>
To: iana@iana.org Subject: IMAP URL Access Identifier Registration
致：iana@iana.org主题：IMAP URL访问标识符注册
Type: <access> identifier
Type: <access> identifier
Application: anonymous
应用：匿名
Description: Indicates that use of this URL is not restricted by session authorization identity
描述：表示此URL的使用不受会话授权标识的限制
RFC Number: RFC 5593 and RFC 5092
RFC编号：RFC 5593和RFC 5092
Contact: Lemonade WG <lemonade@ietf.org>
Contact: Lemonade WG <lemonade@ietf.org>
The extension to <access> identifiers specified in this document provides a mechanism for extending the semantics of the "submit+" <access> prefix to arbitrary applications. The use of such additional <access> identifiers and prefixes is primarily for security purposes, i.e., to prevent the overloading of "submit+" as a generic mechanism to allow entities to retrieve IMAP URLs on behalf of userids. Other than this, the security implications are identical to those discussed in Section 10.1 of IMAPURL [RFC5092].
本文档中指定的<access>标识符扩展提供了一种机制，用于将“submit+”<access>前缀的语义扩展到任意应用程序。使用此类附加的<access>标识符和前缀主要是出于安全目的，即防止“submit+”过载，作为允许实体代表userid检索IMAP URL的通用机制。除此之外，安全含义与IMAPURL[RFC5092]第10.1节中讨论的内容相同。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5092] Melnikov, A., Ed., and C. Newman, "IMAP URL Scheme", RFC 5092, November 2007.
[RFC5092]Melnikov，A.，Ed.，和C.Newman，“IMAP URL方案”，RFC 5092，2007年11月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[STREAMING] Cook, N., "Streaming Internet Messaging Attachments", Work in Progress, May 2009.
[流媒体]库克，N.，“流媒体互联网信息附件”，正在进行的工作，2009年5月。
Author's Address
作者地址
Neil L Cook Cloudmark
尼尔·库克·克劳马克
EMail: neil.cook@noware.co.uk
EMail: neil.cook@noware.co.uk