Network Working Group                                        K. Zeilenga
Request for Comments: 3673                           OpenLDAP Foundation
Category: Standards Track                                  December 2003
        
Network Working Group                                        K. Zeilenga
Request for Comments: 3673                           OpenLDAP Foundation
Category: Standards Track                                  December 2003

Lightweight Directory Access Protocol version 3 (LDAPv3): All Operational Attributes

轻型目录访问协议版本3（LDAPv3）：所有操作属性

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) The Internet Society (2003). All Rights Reserved.

版权所有（C）互联网协会（2003年）。版权所有。

Abstract

摘要

The Lightweight Directory Access Protocol (LDAP) supports a mechanism for requesting the return of all user attributes but not all operational attributes. This document describes an LDAP extension which clients may use to request the return of all operational attributes.

轻量级目录访问协议（LDAP）支持一种机制，用于请求返回所有用户属性，但不是所有操作属性。本文档描述了一个LDAP扩展，客户端可以使用该扩展请求返回所有操作属性。

1. Overview
1. 概述

X.500 [X.500] provides a mechanism for clients to request all operational attributes be returned with entries provided in response to a search operation. This mechanism is often used by clients to discover which operational attributes are present in an entry.

X.500[X.500]为客户端提供了一种机制，用于请求返回所有操作属性，并提供条目以响应搜索操作。客户端经常使用此机制来发现条目中存在哪些操作属性。

This documents extends the Lightweight Directory Access Protocol (LDAP) [RFC3377] to provide a simple mechanism which clients may use to request the return of all operational attributes. The mechanism is designed for use with existing general purpose LDAP clients (including web browsers which support LDAP URLs) and existing LDAP APIs.

本文档扩展了轻量级目录访问协议（LDAP）[RFC3377]以提供一种简单的机制，客户端可以使用该机制请求返回所有操作属性。该机制设计用于现有的通用LDAP客户端（包括支持LDAP URL的web浏览器）和现有LDAP API。

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 BCP 14 [RFC2119].

本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14[RFC2119]中所述进行解释。

2. All Operational Attributes
2. 所有作战属性

The presence of the attribute description "+" (ASCII 43) in the list of attributes in a Search Request [RFC2251] SHALL signify a request for the return of all operational attributes.

在搜索请求[RFC2251]的属性列表中，属性描述“+”（ASCII 43）的存在应表示请求返回所有操作属性。

As with all search requests, client implementors should note that results may not include all requested attributes due to access controls or other restrictions. Client implementors should also note that certain operational attributes may be returned only if requested by name even when "+" is present. This is because some operational attributes are very expensive to return.

与所有搜索请求一样，客户端实现人员应该注意，由于访问控制或其他限制，结果可能不包括所有请求的属性。客户机实现者还应该注意，即使存在“+”时，某些操作属性也只能在通过名称请求时返回。这是因为返回某些操作属性非常昂贵。

Servers supporting this feature SHOULD publish the Object Identifier 1.3.6.1.4.1.4203.1.5.1 as a value of the 'supportedFeatures' [RFC3674] attribute in the root DSE.

支持此功能的服务器应将对象标识符1.3.6.1.4.1.4203.1.5.1发布为根DSE中“supportedFeatures”[RFC3674]属性的值。

3. Interoperability Considerations
3. 互操作性注意事项

This mechanism is specifically designed to allow users to request all operational attributes using existing LDAP clients. In particular, the mechanism is designed to be compatible with existing general purpose LDAP clients including those supporting LDAP URLs [RFC2255].

此机制专门设计用于允许用户使用现有LDAP客户端请求所有操作属性。特别是，该机制设计为与现有的通用LDAP客户端兼容，包括那些支持LDAP URL的客户端[RFC2255]。

The addition of this mechanism to LDAP is not believed to cause any significant interoperability issues (this has been confirmed through testing). Servers which have yet to implement this specification should ignore the "+" as an unrecognized attribute description per [RFC2251, Section 4.5.1]. From the client's perspective, a server which does not return all operational attributes when "+" is requested should be viewed as having other restrictions.

将此机制添加到LDAP中不会导致任何重大的互操作性问题（这已通过测试得到确认）。根据[RFC2251，第4.5.1节]，尚未实现本规范的服务器应忽略“+”作为无法识别的属性描述。从客户机的角度来看，当请求“+”时未返回所有操作属性的服务器应被视为具有其他限制。

It is also noted that this mechanism is believed to require no modification of existing LDAP APIs.

还需要注意的是，这种机制被认为不需要修改现有的LDAP API。

4. Security Considerations
4. 安全考虑

This document provides a general mechanism which clients may use to discover operational attributes. Prior to the introduction of this mechanism, operational attributes were only returned when requested by name. Some might have viewed this as obscurity feature. However, this feature offers a false sense of security as the attributes were still transferable.

本文档提供了客户端可用于发现操作属性的通用机制。在引入此机制之前，仅当名称请求时才返回操作属性。有些人可能认为这是一个晦涩难懂的特征。但是，此功能提供了一种错误的安全感，因为属性仍然是可转移的。

Implementations SHOULD implement appropriate access controls mechanisms to restricts access to operational attributes.

实现应实现适当的访问控制机制，以限制对操作属性的访问。

5. IANA Considerations
5. IANA考虑

This document uses the OID 1.3.6.1.4.1.4203.1.5.1 to identify the feature described above. This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its IANA-assigned private enterprise allocation [PRIVATE], for use in this specification.

本文件使用OID 1.3.6.1.4.1.4203.1.5.1识别上述特征。此OID由OpenLDAP基金会指派（赋值），在其IANA分配的私有企业分配（私有）下，用于本规范中。

Registration of this feature has been completed by IANA [RFC3674], [RFC3383].

IANA[RFC3674]、[RFC3383]已完成此功能的注册。

Subject: Request for LDAP Protocol Mechanism Registration

主题：请求LDAP协议机制注册

Object Identifier: 1.3.6.1.4.1.4203.1.5.1

对象标识符：1.3.6.1.4.1.4203.1.5.1

Description: All Op Attrs

描述：所有操作属性 

   Person & email address to contact for further information:
        Kurt Zeilenga <kurt@openldap.org>
        
   Person & email address to contact for further information:
        Kurt Zeilenga <kurt@openldap.org>

Usage: Feature

用法：功能

Specification: RFC3673

规格：RFC3673

Author/Change Controller: IESG

作者/变更控制员：IESG

Comments: none

评论：无

6. Acknowledgment
6. 致谢

The "+" mechanism is believed to have been first suggested by Bruce Greenblatt in a November 1998 post to the IETF LDAPext Working Group mailing list.

布鲁斯·格林布拉特（Bruce Greenblatt）于1998年11月在IETF LDAPext工作组邮件列表中首次提出了“+”机制。

7. Intellectual Property Statement
7. 知识产权声明

The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.

IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.

IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。

8. References
8. 工具书类
8.1. Normative References
8.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月。

[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.

[RFC2251]Wahl，M.，Howes，T.和S.Kille，“轻量级目录访问协议（v3）”，RFC 2251，1997年12月。

[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.

[RFC3377]Hodges，J.和R.Morgan，“轻量级目录访问协议（v3）：技术规范”，RFC 3377，2002年9月。

[RFC3674] Zeilenga, K., "Feature Discovery in Lightweight Directory Access Protocol (LDAP)", RFC 3674, December 2003.

[RFC3674]Zeilenga，K.，“轻量级目录访问协议（LDAP）中的功能发现”，RFC 3674，2003年12月。

8.2. Informative References
8.2. 资料性引用

[RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, December 1997.

[RFC2255]Howes，T.和M.Smith，“LDAP URL格式”，RFC2255，1997年12月。

[RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 3383, September 2002.

[RFC3383]Zeilenga，K.，“轻量级目录访问协议（LDAP）的互联网分配号码管理局（IANA）注意事项”，BCP 64，RFC 3383，2002年9月。

[X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts, Models and Service", 1993.

[X.500]ITU-T Rec.X.500，“目录：概念、模型和服务概述”，1993年。

[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", http://www.openldap.org/foundation/oid-delegate.txt.

[分配] OpenLDAP基金会，“OpenLDAP类委托”，http://www.openldap.org/foundation/oid-delegate.txt.

[PRIVATE] IANA, "Private Enterprise Numbers", http://www.iana.org/assignments/enterprise-numbers.

[私人]IANA，“私人企业编号”，http://www.iana.org/assignments/enterprise-numbers.

9. Author's Address
9. 作者地址

Kurt D. Zeilenga OpenLDAP Foundation

库尔特D.Zeeliga OpenLDAP基金会 

   EMail: Kurt@OpenLDAP.org
        
   EMail: Kurt@OpenLDAP.org
10. Full Copyright Statement
10. 完整版权声明

Copyright (C) The Internet Society (2003). All Rights Reserved.

版权所有（C）互联网协会（2003年）。版权所有。

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.

上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。

Acknowledgement

确认

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC编辑功能的资金目前由互联网协会提供。