rfc2252.Lightweight Directory Access Protocol (v3) Attribute Syntax Definitions

合集下载

《计算机网络基础与应用（第三版）》课后自我测试（参考答案）

《计算机网络基础与应用（第三版）》课后自我测试（参考答案）《计算机网络基础与应用》教材课后自我测试参考答案模块一计算机网络基础自我测试一、填空题1．计算机网络是将多个具有独立工作能力的计算机系统通过通信设备和线路由功能完善的网络软件实现资源共享和数据通信的系统。

2．计算机网络的发展分两阶段，即：面向终端的网络和计算机的网络。

3．计算机网络按分布距离分为：局域网、城域网和广域网。

4．局域网是指有限的地理范围内构作的计算机网络，它是计算机硬件和传输介质的结合，典型特征是位于一个建筑物或一个单位内。

英文简称LAN 。

5．在局域网中的计算机可分为两种角色。

即：工作站和服务器。

6．从网络架构方法看，局域网有3种类型对等网、工作站服务器网络和无盘工作站。

7．目前网络中经常接触到的3个团体是ISO 、ARPA 和IEEE 。

8．TCP/IP协议中，TCP是指传输控制协议，IP是指网际协议。

9．IEEE 802.3标准是关于有线以太网络的标准。

二、选择题1．下列哪方面是构作计算机网络不会涉及到的。

（ C ）A．计算机互联B．通信设备与传输介质C．计算机性能与交换技术D．网络软件，通信协议和网络操作系统（NOS）2．下列说法正确的是（BC ）。

A．远程网就是通常说的InternetB．城域网构作距离在10Km~100KmC．局域网是速度最快的网络D．局域网只是计算机硬件和传输介质的结合，不需要其他辅助的东西。

3．下列哪项不是局域网的特点。

（D ）A．网络的经营权和管理权属于某个单位B．通信处理一般由网卡完成C．网络所覆盖的地理范围比较小D．所有通信都可用4．局域网的基本组成部分中，下列哪项是没有的。

（A ）A．网络基本结构B．计算机及智能型外围设备C．网络接口卡及电缆D．网络操作系统及有关软件三、判断题1．计算机网络是计算机与通讯技术密切结合的结果。

（对）2．在所有的网络中，局域网的传输距离最小。

（对）四、简答题1．计算机网络发展分几个阶段？各有什么特点？答：第一阶段计算机网络是以单个计算机为中心的远程联机系统，它是由一台计算机和多个终端组成的应用系统，网络终端无数据处理能力，只作为数据的输入输出。

LDAP协议

LDAP协议与LDAP Server目录服务目录服务就是按照树状模式组织信息，实现信息管理和服务接口的一种方式。

目录服务中一般包括两个方面的内容：第一个组成部分是：数据库，这种数据库有别于日常所用到的关系型数据库，它是一种分布型的数据库，并且需要一个描述数据的规则；第二个组成部分是：访问和处理数据库的相关的协议。

目录服务和关系数据库不同，目录服务不支持批量更新事务处理能力，目录一般只执行简单的更新操作，适合于进行大量数据的检索；目录具有广泛的复制信息的能力，从而在缩短响应时间的同时，提高了可用性和可靠性；目前，目录服务技术的国际标准有两个，即较早的X.500标准和近年迅速发展的LDAP标准。

X.500虽然是一个完整协议群组，但是其目录访问协议DAP这种应用层的协议是严格按照复杂的ISO七层协议模型制定的，对相关层协议环境要求过多，主要运行在unix机器上，在许多小系统上，如PC和Macintosh（苹果机）上无法使用，因此没有多少人按照DAP开发应用程序，TCP/IP 协议体系的普及，更使得这种协议越来越不适应需要。

LDAP协议LDAP全称为Light Directory Access Protocol，轻量级目录访问协议，LDAP协议从1993年批准，有了V1版本，1997年发布了第三个版本LDAP v3，使得LDAP协议不仅仅做为X.500的简化版，同时提供了LDAP协议许多自有功能特性，LDAP V3协议也不是一个单一的协议，而是一个协议群组，包括内容如下：1，RFC2251－LDAP V3协议核心协议，定义了LDAP V3协议的基本模型和操作；2，RFC2252－定义了LDAP V3基本数据模式(Schema)以及标准的系统数据模式,Schema包括语法、匹配规则、属性类型和对象类；RFC2253－定义了LDAP V3中的分辨名(Differentiate Name, DN)表达方式；3，RFC2254－定义了LDAP V3中过滤器的表达方式；4，RFC2255－定义了LDAP V3中统一资源地址格式；5，RFC2256－定义了在LDAP V3中使用X.500的Schema列表；6，RFC2829－定义了LDAP V3的认证方式；7，RFC2830－定义了LDAP V3如何通过扩展使用TLS服务；8，RFC1823－定义了C的关于LDAP V3客户端开发接口；9，RFC2847－定义了LDAP数据导入、导出的文件接口LDIF；在这些协议中，主要定义了LDAP的内容，同时定义了信息模型，确定了LDAP目录中所存储的信息的格式和字符集，如何表示目录信息（定义对象类、属性、匹配规则和语法等模式）。

电子公文系统中基于LDAP访问控制的动态配置设计与实现

电子公文系统中基于LDAP访问控制的动态配置设计与实现【关键词】oa系统；动态配置；访问控制；管理安全；ldap1 ldap访问控制的概述随着近年来电子公文系统的广泛发展和应用，处理公文的功能实现越来越需要逼近现实。

处理公文的电子化势不可挡，建立电子公文系统也呈现白热化趋势。

而网络带给大家很多信息安全隐患，因此电子公文系统中也存在很多安全问题。

访问控制是指按用户身份及其归属的某项定义组来限制用户对某些信息项的访问，或限制对某些控制功能的使用。

访问控制通常用于系统管理员控制用户对服务器、目录、文件等网络资源的访问。

ldap的访问控制是指管理员对服务器中资源被浏览、修改、删除权限的配置。

论文背景的课题系统中ldap服务器用在公文系统和数据库之间，作为用户管理服务器使用。

ldap服务器的应用在很大程度上保证了数据库的安全，进而保障了公文系统的安全可靠。

访问控制权限是确定用户只能做到权限规定范围之内的操作，任何用户都不能越权操作。

对公文系统中的用户管理服务器进行动态配置访问控制权限是保证oa系统相对安全行之有效的方法之一。

oa系统中，访问控制是保证公文系统中数据库中的目录信息安全性的一种重要措施。

在ldap服务器中既可以发挥轻型目录访问协议本身的优势，进行快速的查询，修改，增加删除用户和资源的功能，还能进行配置用户的访问控制权限，即对服务器中的资源进行特定操作的权限的配置。

在一个完整安全的oa系统中，实现访问控制是该系统必须实现的功能，它不仅能设置用户的访问权限，而且提高了系统查询，运行的效率。

动态的实现访问控制技术又是目前最灵活方便，有效的方式，它避免了静态配置方式中时间，地域的限制。

一般的，配置用户管理服务器的访问控制权限是通过静态的控制服务器的启动和停止，配合修改slapd.conf文件配置实现的。

但是很多用户使用这种静态配置的方法都会遇到这样的问题：这种静态实现的方法是一种操作的方法，需要考虑实现周期，这是越来越不能被接受的。

RFC 2026

Network Working Group T. HowesRequest for Comments: 2254 Netscape Communications Corp. Category: Standards Track December 1997The String Representation of LDAP Search Filters1. Status of this MemoThis document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions forimprovements. 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.Copyright NoticeCopyright (C) The Internet Society (1997). All Rights Reserved. IESG NoteThis document describes a directory access protocol that provides both read and update access. Update access requires secureauthentication, but this document does not mandate implementation of any satisfactory authentication mechanisms.In accordance with RFC 2026, section 4.4.1, this specification is being approved by IESG as a Proposed Standard despite thislimitation, for the following reasons:a. to encourage implementation and interoperability testing ofthese protocols (with or without update access) before theyare deployed, andb. to encourage deployment and use of these protocols in read-only applications. (e.g. applications where LDAPv3 is used asa query language for directories which are updated by somesecure mechanism other than LDAP), andc. to avoid delaying the advancement and deployment of other Internet standards-track protocols which require the ability to query, but not update, LDAPv3 directory servers.Howes Standards Track [Page 1]RFC 2254 String Representation of LDAP December 1997Readers are hereby warned that until mandatory authenticationmechanisms are standardized, clients and servers written according to this specification which make use of update functionality areUNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.Implementors are hereby discouraged from deploying LDAPv3 clients or servers which implement the update functionality, until a Proposed Standard for mandatory authentication in LDAPv3 has been approved and published as an RFC.2. AbstractThe Lightweight Directory Access Protocol (LDAP) [1] defines anetwork representation of a search filter transmitted to an LDAP server. Some applications may find it useful to have a common way of representing these search filters in a human-readable form. This document defines a human-readable string format for representing LDAP search filters.This document replaces RFC 1960, extending the string LDAP filter definition to include support for LDAP version 3 extended matchfilters, and including support for representing the full range ofpossible LDAP search filters.Howes Standards Track [Page 2]RFC 2254 String Representation of LDAP December 19973. LDAP Search Filter DefinitionAn LDAPv3 search filter is defined in Section 4.5.1 of [1] asfollows:Filter ::= CHOICE {and [0] SET OF Filter,or [1] SET OF Filter,not [2] Filter,equalityMatch [3] AttributeValueAssertion,substrings [4] SubstringFilter,greaterOrEqual [5] AttributeValueAssertion,lessOrEqual [6] AttributeValueAssertion,present [7] AttributeDescription,approxMatch [8] AttributeValueAssertion,extensibleMatch [9] MatchingRuleAssertion}SubstringFilter ::= SEQUENCE {type AttributeDescription,SEQUENCE OF CHOICE {initial [0] LDAPString,any [1] LDAPString,final [2] LDAPString}}AttributeValueAssertion ::= SEQUENCE {attributeDesc AttributeDescription,attributeValue AttributeValue}MatchingRuleAssertion ::= SEQUENCE {matchingRule [1] MatchingRuleID OPTIONAL,type [2] AttributeDescription OPTIONAL,matchValue [3] AssertionValue,dnAttributes [4] BOOLEAN DEFAULT FALSE}AttributeDescription ::= LDAPStringAttributeValue ::= OCTET STRINGMatchingRuleID ::= LDAPStringAssertionValue ::= OCTET STRINGLDAPString ::= OCTET STRINGHowes Standards Track [Page 3]RFC 2254 String Representation of LDAP December 1997where the LDAPString above is limited to the UTF-8 encoding of the ISO 10646 character set [4]. The AttributeDescription is a string representation of the attribute description and is defined in [1]. The AttributeValue and AssertionValue OCTET STRING have the form defined in [2]. The Filter is encoded for transmission over anetwork using the Basic Encoding Rules defined in [3], withsimplifications described in [1].4. String Search Filter DefinitionThe string representation of an LDAP search filter is defined by the following grammar, following the ABNF notation defined in [5]. The filter format uses a prefix notation.filter = "(" filtercomp ")"filtercomp = and / or / not / itemand = "&" filterlistor = "|" filterlistnot = "!" filterfilterlist = 1*filteritem = simple / present / substring / extensiblesimple = attr filtertype valuefiltertype = equal / approx / greater / lessequal = "="approx = "~="greater = ">="less = "<="extensible = attr [":dn"] [":" matchingrule] ":=" value/ [":dn"] ":" matchingrule ":=" valuepresent = attr "=*"substring = attr "=" [initial] any [final]initial = valueany = "*" *(value "*")final = valueattr = AttributeDescription from Section 4.1.5 of [1] matchingrule = MatchingRuleId from Section 4.1.9 of [1]value = AttributeValue from Section 4.1.6 of [1]The attr, matchingrule, and value constructs are as described in thecorresponding section of [1] given above.Howes Standards Track [Page 4]RFC 2254 String Representation of LDAP December 1997If a value should contain any of the following charactersCharacter ASCII value---------------------------* 0x2a( 0x28) 0x29\ 0x5cNUL 0x00the character must be encoded as the backslash '\' character (ASCII 0x5c) followed by the two hexadecimal digits representing the ASCII value of the encoded character. The case of the two hexadecimaldigits is not significant.This simple escaping mechanism eliminates filter-parsing ambiguities and allows any filter that can be represented in LDAP to berepresented as a NUL-terminated string. Other characters besides the ones listed above may be escaped using this mechanism, for example, non-printing characters.For example, the filter checking whether the "cn" attribute contained a value with the character "*" anywhere in it would be represented as "(cn=*\2a*)".Note that although both the substring and present productions in the grammar above can produce the "attr=*" construct, this construct is used only to denote a presence filter.5. ExamplesThis section gives a few examples of search filters written using this notation.(cn=Babs Jensen)(!(cn=Tim Howes))(&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))(o=univ*of*mich*)The following examples illustrate the use of extensible matching.(cn:1.2.3.4.5:=Fred Flintstone)(sn:dn:2.4.6.8.10:=Barney Rubble)(o:dn:=Ace Industry)(:dn:2.4.6.8.10:=Dino)Howes Standards Track [Page 5]RFC 2254 String Representation of LDAP December 1997The second example illustrates the use of the ":dn" notation toindicate that matching rule "2.4.6.8.10" should be used when making comparisons, and that the attributes of an entry's distinguished name should be considered part of the entry when evaluating the match.The third example denotes an equality match, except that DNcomponents should be considered part of the entry when doing the match.The fourth example is a filter that should be applied to anyattribute supporting the matching rule given (since the attr has beenleft off). Attributes supporting the matching rule contained in the DN should also be considered.The following examples illustrate the use of the escaping mechanism.(o=Parens R Us \28for all your parenthetical needs\29)(cn=*\2A*)(filename=C:\5cMyFile)(bin=\00\00\00\04)(sn=Lu\c4\8di\c4\87)The first example shows the use of the escaping mechanism torepresent parenthesis characters. The second shows how to represent a"*" in a value, preventing it from being interpreted as a substring indicator. The third illustrates the escaping of the backslashcharacter.The fourth example shows a filter searching for the four-byte value 0x00000004, illustrating the use of the escaping mechanism torepresent arbitrary data, including NUL characters.The final example illustrates the use of the escaping mechanism to represent various non-ASCII UTF-8 characters.6. Security ConsiderationsThis memo describes a string representation of LDAP search filters. While the representation itself has no known security implications, LDAP search filters do. They are interpreted by LDAP servers toselect entries from which data is retrieved. LDAP servers should take care to protect the data they maintain from unauthorized access.Howes Standards Track [Page 6]RFC 2254 String Representation of LDAP December 19977. References[1] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.[2] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.[3] Specification of ASN.1 encoding rules: Basic, Canonical, and Distinguished Encoding Rules, ITU-T Recommendation X.690, 1994.[4] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996.[5] Crocker, D., "Standard for the Format of ARPA Internet TextMessages", STD 11, RFC 822, August 1982.8. Author's AddressTim HowesNetscape Communications Corp.501 E. Middlefield RoadMountain View, CA 94043USAPhone: +1 415 937-3419EMail: howes@Howes Standards Track [Page 7]RFC 2254 String Representation of LDAP December 19979. Full Copyright StatementCopyright (C) The Internet Society (1997). All Rights Reserved.This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose ofdeveloping Internet standards in which case the procedures forcopyrights defined in the Internet Standards process must befollowed, 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 assigns.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 INFORMATIONHEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OFMERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Howes Standards Track [Page 8]。

rfc相关设置及使用

rfc相关设置及使用RFC（Request for Comments）是一种用于定义互联网协议、标准和相关问题的文档。

RFC的格式由互联网工程任务组（IETF）统一规定，它们记录了网络技术的发展和演进过程。

在本文中，我们将介绍RFC相关的设置和使用。

1. 了解RFC的作用和历史：RFC是由IETF组织制定的一种标准化文档，它记录了互联网协议的设计、开发和演化过程。

RFC起源于20世纪60年代的ARPANET，是一种社区驱动的文档，通过共享和讨论来推动互联网技术的发展。

RFC文档旨在提供指南、建议和最佳实践，帮助网络技术人员解决问题。

2. 寻找和阅读RFC文档：RFC文档可以在互联网上免费获取，IETF的官方网站和其他资源库都有存档。

这些文档按照顺序编号，并且以RFC开头，比如RFC 791定义了IPv4协议。

通过搜索引擎或在IETF网站上使用关键词搜索，可以找到特定主题的RFC文档。

阅读RFC文档时，应该注意文档的状态，有一些可能已经被更新或废弃。

3. 使用RFC文档：RFC文档在网络技术的发展过程中起着重要的指导作用。

它们提供了协议规范、算法实现、安全性和隐私等方面的建议。

网络管理员、网络工程师和开发人员可以使用RFC文档来了解和理解特定协议或标准的设计原理和要求。

此外，RFC文档还常用于进行互联网协议的实现、编程和配置。

4. 参与RFC的制定过程：RFC并不是静止的文件，而是一个持续演进的过程。

任何人都可以参与到RFC的制定过程中。

要参与RFC的制定，可以加入IETF并参与相关的工作组或邮件列表。

通过这种方式，个人可以提出改进建议，参与讨论和标准化的制定。

5. 遵循RFC的指导原则：在网络技术领域，遵循RFC的指导原则是至关重要的。

这些指导原则包括设计原则、协议分层、安全性和互操作性等要求。

遵循RFC的指导原则可以确保网络协议的正确性、稳定性和可靠性，同时也可以促进网络技术的发展和创新。

总结起来，RFC在互联网技术领域起着重要的作用，它们记录了互联网协议的发展历程和指导原则。

LDAP简介

科技部科技基础性工作专项资金重大项目研究成果项目名称：我国数字图书馆标准规范建设子项目名称：数字资源检索与应用标准规范研究项目编号：2002DEA20018研究成果类型：研究报告成果名称：LDAP协议应用指南成果编号：CDLS-S07-002成果版本：总项目组推荐稿成果提交日期：2003年2月撰写人：张智雄（中国科学院文献情报中心）项目版权声明本报告研究工作属于科技部科技基础性工作专项资金重大项目《我国数字图书馆标准规范建设》的一部分，得到科技部科技基础性工作专项资金资助，项目编号为2002DEA20018。

按照有关规定，国家和《我国数字图书馆标准规范建设》课题组拥有本报告的版权，依照《中华人民共和国著作权法》享有著作权。

本报告可以复制、转载、或在电子信息系统上做镜像，但在复制、转载或镜像时须注明真实作者和完整出处，并在明显地方标明“科技部科技基础性工作专项资金重大项目《我国数字图书馆标准规范建设》资助”的字样。

报告版权人不承担用户在使用本作品内容时可能造成的任何实际或预计的损失。

作者声明本报告作者谨保证本作品中出现的文字、图片、声音、剪辑和文后参考文献等内容的真实性和可靠性，愿按照《中华人民共和国著作权法》，承担本作品发布过程中的责任和义务。

科技部有关管理机构对于本作品内容所引发的版权、署名权的异议、纠纷不承担任何责任。

《我国数字图书馆标准规范建设》课题组网站（）作为本报告的第一发表单位，并可向其他媒体推荐此作品。

在不发生重复授权的前提下，报告撰写人保留将经过修改的项目成果向正式学术媒体直接投稿的权利。

LDAP协议应用指南目录1. 协议概述 (1)2. LDAP的特点和应用领域 (1)3. LDAP目录的优势 (2)1.协议概述LDAP（Lightweight Directory Access Protocol，轻量级目录存取协议）是目前广泛应用的目录协议。

在计算机中，目录被认为是一种特殊的数据库，也有人将其称为数据仓库(Data Repository)，它被用于存储一定类型的经过整序的信息。

rfc2217协议内容

竭诚为您提供优质文档/双击可除rfc2217协议内容篇一：串口服务器410软件设计手册usR-tcp232-410软件设计手册文件版本：V1.0.1目录usR-tcp232-410软件设计手册................................................. ................................................... . (1)1.产品概述................................................. ................................................... ................................................... .. (3)1.1.产品简介.................................................................................................... . (3)1.2.功能特点................................................. ................................................... . (3)1.3.与旧的e45系列的兼容性声明................................................. ................................................... . (4)2.产品功能................................................. ................................................... ................................................... .. (5)2.1.tcpclient模式特性................................................. ................................................... (5)2.2.tcpserver模式特性................................................. ................................................... (7)2.3.udpclient模式特性................................................. ................................................... .. (8)2.4.udpserver模式特性................................................. ................................................... (10)2.5.httpdclient.................................... ................................................... . (11)2.6.Vcom应用模式................................................. ................................................... . (13)2.7.增值功能................................................. ................................................... .. (14)2.7.1.网页转串口功能................................................. ................................................... (14)2.7.2.自定义网页功能................................................. ................................................... (17)2.7.3.modbusRtu转modbustcp.......................................... ................................................... .182.7.4.串口打包机制................................................. ................................................... . (18)2.7.5.流量计算................................................. ................................................... (19)2.7.6.类RFc2217功能................................................. ................................................... (19)3.设置协议................................................. ................................................... ................................................... (21)3.1.网络设置协议................................................. ................................................... (21)3.1.1.设置参数的流程................................................. ................................................... (21)3.1.2.设置指令内容................................................. ................................................... . (21)3.1.3.返回指令内容................................................. ................................................... . (24)3.2.串口设置协议................................................. ................................................... (26)4.免责声明................................................. ................................................... ................................................... (26)5.更新历史................................................. ................................................... ................................................... (26)1.产品概述1.1.产品简介usR-tcp232-410是有人物联网技术有限公司推出的m4系列的串口服务器，是用来将tcp/udp数据包与Rs232/Rs485接口实现数据透明传输的设备。

rfc中常用的测试协议

rfc中常用的测试协议引言在计算机网络领域中，为了确保网络协议的正确性和稳定性，测试协议起到了至关重要的作用。

RFC（Request for Comments）是一系列文件，用于描述互联网相关协议、过程和技术。

在RFC中，也包含了一些常用的测试协议，用于验证和评估网络协议的功能和性能。

本文将介绍RFC中常用的测试协议，并深入探讨其原理和应用。

二级标题1：PING协议三级标题1.1：概述PING协议是一种常用的网络测试协议，用于测试主机之间的连通性。

它基于ICMP （Internet Control Message Protocol）协议，通过发送ICMP Echo Request报文并等待目标主机的ICMP Echo Reply报文来判断目标主机是否可达。

三级标题1.2：工作原理PING协议的工作原理如下： 1. 发送方主机生成一个ICMP Echo Request报文，并将目标主机的IP地址作为目的地。

2. 发送方主机将报文发送到网络中。

3.中间路由器收到报文后，将报文转发到下一跳路由器。

4. 目标主机收到ICMP Echo Request报文后，生成一个ICMP Echo Reply报文，并将其发送回发送方主机。

5. 发送方主机收到ICMP Echo Reply报文后，通过比较报文中的标识符和序列号等字段，判断目标主机是否可达。

三级标题1.3：应用场景PING协议在网络中的应用非常广泛，常用于以下场景： - 测试主机之间的连通性，判断网络是否正常工作。

- 测试网络延迟，通过计算ICMP Echo Request报文的往返时间来评估网络质量。

- 排查网络故障，通过检查ICMP Echo Reply报文中的错误码来定位故障原因。

二级标题2：Traceroute协议三级标题2.1：概述Traceroute协议用于跟踪数据包从源主机到目标主机经过的路径。

它通过发送一系列的UDP报文，并在每个报文中设置不同的TTL（Time to Live）值来实现。

1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

Network Working Group M. Wahl Request for Comments: 2252 Critical Angle Inc. Category: Standards Track A. Coulbeck Isode Inc. T. Howes Netscape Communications Corp. S. Kille Isode Limited December 1997 Lightweight Directory Access Protocol (v3):Attribute Syntax Definitions1. Status of this MemoThis document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited. Copyright NoticeCopyright (C) The Internet Society (1997). All Rights Reserved.IESG NoteThis document describes a directory access protocol that providesboth read and update access. Update access requires secureauthentication, but this document does not mandate implementation of any satisfactory authentication mechanisms.In accordance with RFC 2026, section 4.4.1, this specification isbeing approved by IESG as a Proposed Standard despite thislimitation, for the following reasons:a. to encourage implementation and interoperability testing ofthese protocols (with or without update access) before theyare deployed, andb. to encourage deployment and use of these protocols in read-onlyapplications. (e.g. applications where LDAPv3 is used asa query language for directories which are updated by somesecure mechanism other than LDAP), andWahl, et. al. Standards Track [Page 1]c. to avoid delaying the advancement and deployment of other Internet standards-track protocols which require the ability to query, but not update, LDAPv3 directory servers.Readers are hereby warned that until mandatory authenticationmechanisms are standardized, clients and servers written according to this specification which make use of update functionality areUNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.Implementors are hereby discouraged from deploying LDAPv3 clients or servers which implement the update functionality, until a ProposedStandard for mandatory authentication in LDAPv3 has been approved and published as an RFC.2. AbstractThe Lightweight Directory Access Protocol (LDAP) [1] requires thatthe contents of AttributeValue fields in protocol elements be octetstrings. This document defines a set of syntaxes for LDAPv3, and the rules by which attribute values of these syntaxes are represented as octet strings for transmission in the LDAP protocol. The syntaxesdefined in this document are referenced by this and other documentsthat define attribute types. This document also defines the set ofattribute types which LDAP servers should support.3. OverviewThis document defines the framework for developing schemas fordirectories accessible via the Lightweight Directory Access Protocol. Schema is the collection of attribute type definitions, object class definitions and other information which a server uses to determinehow to match a filter or attribute value assertion (in a compareoperation) against the attributes of an entry, and whether to permit add and modify operations.Section 4 states the general requirements and notations for attribute types, object classes, syntax and matching rule definitions.Section 5 lists attributes, section 6 syntaxes and section 7 objectclasses.Additional documents define schemas for representing real-worldobjects as directory entries.Wahl, et. al. Standards Track [Page 2]4. General IssuesThis document describes encodings used in an Internet protocol.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 [4].Attribute Type and Object Class definitions are written in a stringrepresentation of the AttributeTypeDescription andObjectClassDescription data types defined in X.501(93) [3].Implementors are strongly advised to first read the description ofhow schema is represented in X.500 before reading the rest of thisdocument.4.1. Common Encoding AspectsFor the purposes of defining the encoding rules for attributesyntaxes, the following BNF definitions will be used. They are based on the BNF styles of RFC 822 [13].a = "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" /"j" / "k" / "l" / "m" / "n" / "o" / "p" / "q" / "r" /"s" / "t" / "u" / "v" / "w" / "x" / "y" / "z" / "A" /"B" / "C" / "D" / "E" / "F" / "G" / "H" / "I" / "J" /"K" / "L" / "M" / "N" / "O" / "P" / "Q" / "R" / "S" /"T" / "U" / "V" / "W" / "X" / "Y" / "Z"d = "0" / "1" / "2" / "3" / "4" /"5" / "6" / "7" / "8" / "9"hex-digit = d / "a" / "b" / "c" / "d" / "e" / "f" /"A" / "B" / "C" / "D" / "E" / "F"k = a / d / "-" / ";"p = a / d / """ / "(" / ")" / "+" / "," /"-" / "." / "/" / ":" / "?" / " "letterstring = 1*anumericstring = 1*danhstring = 1*kkeystring = a [ anhstring ]printablestring = 1*pWahl, et. al. Standards Track [Page 3]space = 1*" "whsp = [ space ]utf8 = <any sequence of octets formed from the UTF-8 [9] transformation of a character from ISO10646 [10]> dstring = 1*utf8qdstring = whsp "’" dstring "’" whspqdstringlist = [ qdstring *( qdstring ) ]qdstrings = qdstring / ( whsp "(" qdstringlist ")" whsp )In the following BNF for the string representation of OBJECTIDENTIFIERs, descr is the syntactic representation of an objectdescriptor, which consists of letters and digits, starting with aletter. An OBJECT IDENTIFIER in the numericoid format should nothave leading zeroes (e.g. "0.9.3" is permitted but "0.09.3" shouldnot be generated).When encoding ’oid’ elements in a value, the descr encoding optionSHOULD be used in preference to the numericoid. An object descriptor is a more readable alias for a number OBJECT IDENTIFIER, and these(where assigned and known by the implementation) SHOULD be used inpreference to numeric oids to the greatest extent possible. Examples of object descriptors in LDAP are attribute type, object class andmatching rule names.oid = descr / numericoiddescr = keystringnumericoid = numericstring *( "." numericstring )woid = whsp oid whsp; set of oids of either formoids = woid / ( "(" oidlist ")" )oidlist = woid *( "$" woid ); object descriptors used as schema element namesqdescrs = qdescr / ( whsp "(" qdescrlist ")" whsp )qdescrlist = [ qdescr *( qdescr ) ]Wahl, et. al. Standards Track [Page 4]qdescr = whsp "’" descr "’" whsp4.2. Attribute TypesThe attribute types are described by sample values for the subschema"attributeTypes" attribute, which is written in theAttributeTypeDescription syntax. While lines have been folded forreadability, the values transferred in protocol would not containnewlines.The AttributeTypeDescription is encoded according to the followingBNF, and the productions for oid, qdescrs and qdstring are given insection 4.1. Implementors should note that future versions of thisdocument may have expanded this BNF to include additional terms.Terms which begin with the characters "X-" are reserved for privateexperiments, and MUST be followed by a <qdstrings>.AttributeTypeDescription = "(" whspnumericoid whsp ; AttributeType identifier[ "NAME" qdescrs ] ; name used in AttributeType[ "DESC" qdstring ] ; description[ "OBSOLETE" whsp ][ "SUP" woid ] ; derived from this other; AttributeType[ "EQUALITY" woid ; Matching Rule name[ "ORDERING" woid ; Matching Rule name[ "SUBSTR" woid ] ; Matching Rule name[ "SYNTAX" whsp noidlen whsp ] ; see section 4.3[ "SINGLE-VALUE" whsp ] ; default multi-valued[ "COLLECTIVE" whsp ] ; default not collective[ "NO-USER-MODIFICATION" whsp ]; default user modifiable[ "USAGE" whsp AttributeUsage ]; default userApplicationswhsp ")"AttributeUsage ="userApplications" /"directoryOperation" /"distributedOperation" / ; DSA-shared"dSAOperation" ; DSA-specific, value depends on server Servers are not required to provide the same or any text in thedescription part of the subschema values they maintain. ServersSHOULD provide at least one of the "SUP" and "SYNTAX" fields for each AttributeTypeDescription.Servers MUST implement all the attribute types referenced in sections 5.1, 5.2 and 5.3.Wahl, et. al. Standards Track [Page 5]Servers MAY recognize additional names and attributes not listed inthis document, and if they do so, MUST publish the definitions of the types in the attributeTypes attribute of their subschema entries.Schema developers MUST NOT create attribute definitions whose namesconflict with attributes defined for use with LDAP in existingstandards-track RFCs.An AttributeDescription can be used as the value in a NAME part of an AttributeTypeDescription. Note that these are case insensitive.Note that the AttributeTypeDescription does not list the matchingrules which can can be used with that attribute type in anextensibleMatch search filter. This is done using thematchingRuleUse attribute described in section 4.5.This document refines the schema description of X.501 by requiringthat the syntax field in an AttributeTypeDescription be a stringrepresentation of an OBJECT IDENTIFIER for the LDAP string syntaxdefinition, and an optional indication of the maximum length of avalue of this attribute (defined in section 4.3.2).4.3. SyntaxesThis section defines general requirements for LDAP attribute valuesyntax encodings. All documents defining attribute syntax encodingsfor use with LDAP are expected to conform to these requirements.The encoding rules defined for a given attribute syntax must produce octet strings. To the greatest extent possible, encoded octetstrings should be usable in their native encoded form for displaypurposes. In particular, encoding rules for attribute syntaxesdefining non-binary values should produce strings that can bedisplayed with little or no translation by clients implementing LDAP. There are a few cases (e.g. audio) however, when it is not sensibleto produce a printable representation, and clients MUST NOT assumethat an unrecognized syntax is a string representation.In encodings where an arbitrary string, not a Distinguished Name, is used as part of a larger production, and other than as part of aDistinguished Name, a backslash quoting mechanism is used to escapethe following separator symbol character (such as "’", "$" or "#") if it should occur in that string. The backslash is followed by a pair of hexadecimal digits representing the next character. A backslashitself in the string which forms part of a larger syntax is alwaystransmitted as ’\5C’ or ’\5c’. An example is given in section 6.27. Wahl, et. al. Standards Track [Page 6]Syntaxes are also defined for matching rules whose assertion valuesyntax is different from the attribute value syntax.4.3.1 Binary Transfer of ValuesThis encoding format is used if the binary encoding is requested bythe client for an attribute, or if the attribute syntax name is"1.3.6.1.4.1.1466.115.121.1.5". The contents of the LDAPAttributeValue or AssertionValue field is a BER-encoded instance ofthe attribute value or a matching rule assertion value ASN.1 datatype as defined for use with X.500. (The first byte inside the OCTET STRING wrapper is a tag octet. However, the OCTET STRING is stillencoded in primitive form.)All servers MUST implement this form for both generating attributevalues in search responses, and parsing attribute values in add,compare and modify requests, if the attribute type is recognized and the attribute syntax name is that of Binary. Clients which requestthat all attributes be returned from entries MUST be prepared toreceive values in binary (e.g. userCertificate;binary), and SHOULDNOT simply display binary or unrecognized values to users.4.3.2. Syntax Object IdentifiersSyntaxes for use with LDAP are named by OBJECT IDENTIFIERs, which are dotted-decimal strings. These are not intended to be displayed tousers.noidlen = numericoid [ "{" len "}" ]len = numericstringThe following table lists some of the syntaxes that have been defined for LDAP thus far. The H-R column suggests whether a value in thatsyntax would likely be a human readable string. Clients and servers need not implement all the syntaxes listed here, and MAY implementother syntaxes.Other documents may define additional syntaxes. However, thedefinition of additional arbitrary syntaxes is strongly deprecatedsince it will hinder interoperability: today’s client and serverimplementations generally do not have the ability to dynamicallyrecognize new syntaxes. In most cases attributes will be definedwith the syntax for directory strings.Wahl, et. al. Standards Track [Page 7]Value being represented H-R OBJECT IDENTIFIER=================================================================ACI Item N 1.3.6.1.4.1.1466.115.121.1.1Access Point Y 1.3.6.1.4.1.1466.115.121.1.2Attribute Type Description Y 1.3.6.1.4.1.1466.115.121.1.3Audio N 1.3.6.1.4.1.1466.115.121.1.4Binary N 1.3.6.1.4.1.1466.115.121.1.5Bit String Y 1.3.6.1.4.1.1466.115.121.1.6Boolean Y 1.3.6.1.4.1.1466.115.121.1.7Certificate N 1.3.6.1.4.1.1466.115.121.1.8Certificate List N 1.3.6.1.4.1.1466.115.121.1.9Certificate Pair N 1.3.6.1.4.1.1466.115.121.1.10Country String Y 1.3.6.1.4.1.1466.115.121.1.11DN Y 1.3.6.1.4.1.1466.115.121.1.12Data Quality Syntax Y 1.3.6.1.4.1.1466.115.121.1.13Delivery Method Y 1.3.6.1.4.1.1466.115.121.1.14Directory String Y 1.3.6.1.4.1.1466.115.121.1.15DIT Content Rule Description Y 1.3.6.1.4.1.1466.115.121.1.16DIT Structure Rule Description Y 1.3.6.1.4.1.1466.115.121.1.17DL Submit Permission Y 1.3.6.1.4.1.1466.115.121.1.18DSA Quality Syntax Y 1.3.6.1.4.1.1466.115.121.1.19DSE Type Y 1.3.6.1.4.1.1466.115.121.1.20Enhanced Guide Y 1.3.6.1.4.1.1466.115.121.1.21Facsimile Telephone Number Y 1.3.6.1.4.1.1466.115.121.1.22Fax N 1.3.6.1.4.1.1466.115.121.1.23Generalized Time Y 1.3.6.1.4.1.1466.115.121.1.24Guide Y 1.3.6.1.4.1.1466.115.121.1.25IA5 String Y 1.3.6.1.4.1.1466.115.121.1.26INTEGER Y 1.3.6.1.4.1.1466.115.121.1.27JPEG N 1.3.6.1.4.1.1466.115.121.1.28LDAP Syntax Description Y 1.3.6.1.4.1.1466.115.121.1.54LDAP Schema Definition Y 1.3.6.1.4.1.1466.115.121.1.56LDAP Schema Description Y 1.3.6.1.4.1.1466.115.121.1.57Master And Shadow Access Points Y 1.3.6.1.4.1.1466.115.121.1.29Matching Rule Description Y 1.3.6.1.4.1.1466.115.121.1.30Matching Rule Use Description Y 1.3.6.1.4.1.1466.115.121.1.31Mail Preference Y 1.3.6.1.4.1.1466.115.121.1.32MHS OR Address Y 1.3.6.1.4.1.1466.115.121.1.33Modify Rights Y 1.3.6.1.4.1.1466.115.121.1.55Name And Optional UID Y 1.3.6.1.4.1.1466.115.121.1.34Name Form Description Y 1.3.6.1.4.1.1466.115.121.1.35Numeric String Y 1.3.6.1.4.1.1466.115.121.1.36Object Class Description Y 1.3.6.1.4.1.1466.115.121.1.37Octet String Y 1.3.6.1.4.1.1466.115.121.1.40OID Y 1.3.6.1.4.1.1466.115.121.1.38Other Mailbox Y 1.3.6.1.4.1.1466.115.121.1.39Postal Address Y 1.3.6.1.4.1.1466.115.121.1.41Protocol Information Y 1.3.6.1.4.1.1466.115.121.1.42 Wahl, et. al. Standards Track [Page 8]Presentation Address Y 1.3.6.1.4.1.1466.115.121.1.43Printable String Y 1.3.6.1.4.1.1466.115.121.1.44Substring Assertion Y 1.3.6.1.4.1.1466.115.121.1.58Subtree Specification Y 1.3.6.1.4.1.1466.115.121.1.45Supplier Information Y 1.3.6.1.4.1.1466.115.121.1.46Supplier Or Consumer Y 1.3.6.1.4.1.1466.115.121.1.47Supplier And Consumer Y 1.3.6.1.4.1.1466.115.121.1.48Supported Algorithm N 1.3.6.1.4.1.1466.115.121.1.49Telephone Number Y 1.3.6.1.4.1.1466.115.121.1.50Teletex Terminal Identifier Y 1.3.6.1.4.1.1466.115.121.1.51Telex Number Y 1.3.6.1.4.1.1466.115.121.1.52UTC Time Y 1.3.6.1.4.1.1466.115.121.1.53A suggested minimum upper bound on the number of characters in value with a string-based syntax, or the number of bytes in a value for all other syntaxes, may be indicated by appending this bound count inside of curly braces following the syntax name’s OBJECT IDENTIFIER in anAttribute Type Description. This bound is not part of the syntaxname itself. For instance, "1.3.6.4.1.1466.0{64}" suggests thatserver implementations should allow a string to be 64 characterslong, although they may allow longer strings. Note that a singlecharacter of the Directory String syntax may be encoded in more than one byte since UTF-8 is a variable-length encoding.4.3.3. Syntax DescriptionThe following BNF may be used to associate a short description with a syntax OBJECT IDENTIFIER. Implementors should note that futureversions of this document may expand this definition to includeadditional terms. Terms whose identifier begins with "X-" arereserved for private experiments, and MUST be followed by a<qdstrings>.SyntaxDescription = "(" whspnumericoid whsp[ "DESC" qdstring ]whsp ")"4.4. Object ClassesThe format for representation of object classes is defined in X.501[3]. In general every entry will contain an abstract class ("top" or "alias"), at least one structural object class, and zero or moreauxiliary object classes. Whether an object class is abstract,structural or auxiliary is defined when the object class identifieris assigned. An object class definition should not be changedwithout having a new identifier assigned to it.Wahl, et. al. Standards Track [Page 9]Object class descriptions are written according to the following BNF. Implementors should note that future versions of this document mayexpand this definition to include additional terms. Terms whoseidentifier begins with "X-" are reserved for private experiments, and MUST be followed by a <qdstrings> encoding.ObjectClassDescription = "(" whspnumericoid whsp ; ObjectClass identifier[ "NAME" qdescrs ][ "DESC" qdstring ][ "OBSOLETE" whsp ][ "SUP" oids ] ; Superior ObjectClasses[ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ]; default structural[ "MUST" oids ] ; AttributeTypes[ "MAY" oids ] ; AttributeTypeswhsp ")"These are described as sample values for the subschema"objectClasses" attribute for a server which implements the LDAPschema. While lines have been folded for readability, the valuestransferred in protocol would not contain newlines.Servers SHOULD implement all the object classes referenced in section 7, except for extensibleObject, which is optional. Servers MAYimplement additional object classes not listed in this document, and if they do so, MUST publish the definitions of the classes in theobjectClasses attribute of their subschema entries.Schema developers MUST NOT create object class definitions whosenames conflict with attributes defined for use with LDAP in existing standards-track RFCs.4.5. Matching RulesMatching rules are used by servers to compare attribute valuesagainst assertion values when performing Search and Compareoperations. They are also used to identify the value to be added or deleted when modifying entries, and are used when comparing apurported distinguished name with the name of an entry.Most of the attributes given in this document will have an equalitymatching rule defined.Matching rule descriptions are written according to the followingBNF. Implementors should note that future versions of this document may have expanded this BNF to include additional terms. Terms whose identifier begins with "X-" are reserved for private experiments, and Wahl, et. al. Standards Track [Page 10]MUST be followed by a <qdstrings> encoding.MatchingRuleDescription = "(" whspnumericoid whsp ; MatchingRule identifier[ "NAME" qdescrs ][ "DESC" qdstring ][ "OBSOLETE" whsp ]"SYNTAX" numericoidwhsp ")"Values of the matchingRuleUse list the attributes which are suitable for use with an extensible matching rule.MatchingRuleUseDescription = "(" whspnumericoid whsp ; MatchingRule identifier[ "NAME" qdescrs ][ "DESC" qdstring ][ "OBSOLETE" ]"APPLIES" oids ; AttributeType identifierswhsp ")"Servers which support matching rules and the extensibleMatch SHOULDimplement all the matching rules in section 8.Servers MAY implement additional matching rules not listed in thisdocument, and if they do so, MUST publish the definitions of thematching rules in the matchingRules attribute of their subschemaentries. If the server supports the extensibleMatch, then the server MUST publish the relationship between the matching rules andattributes in the matchingRuleUse attribute.For example, a server which implements a privately-defined matchingrule for performing sound-alike matches on Directory String-valuedattributes would include the following in the subschema entry(1.2.3.4.5 is an example, the OID of an actual matching rule would be different):matchingRule: ( 1.2.3.4.5 NAME ’soundAlikeMatch’SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )If this matching rule could be used with the attributes 2.5.4.41 and 2.5.4.15, the following would also be present:matchingRuleUse: ( 1.2.3.4.5 APPLIES (2.5.4.41 $ 2.5.4.15) )Wahl, et. al. Standards Track [Page 11]A client could then make use of this matching rule by sending asearch operation in which the filter is of the extensibleMatchchoice, the matchingRule field is "soundAlikeMatch", and the typefield is "2.5.4.41" or "2.5.4.15".5. Attribute TypesAll LDAP server implementations MUST recognize the attribute typesdefined in this section.Servers SHOULD also recognize all the attributes from section 5 of[12].5.1. Standard Operational AttributesServers MUST maintain values of these attributes in accordance withthe definitions in X.501(93).5.1.1. createTimestampThis attribute SHOULD appear in entries which were created using the Add operation.( 2.5.18.1 NAME ’createTimestamp’ EQUALITY generalizedTimeMatchORDERING generalizedTimeOrderingMatchSYNTAX 1.3.6.1.4.1.1466.115.121.1.24SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )5.1.2. modifyTimestampThis attribute SHOULD appear in entries which have been modifiedusing the Modify operation.( 2.5.18.2 NAME ’modifyTimestamp’ EQUALITY generalizedTimeMatchORDERING generalizedTimeOrderingMatchSYNTAX 1.3.6.1.4.1.1466.115.121.1.24SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )5.1.3. creatorsNameThis attribute SHOULD appear in entries which were created using the Add operation.( 2.5.18.3 NAME ’creatorsName’ EQUALITY distinguishedNameMatchSYNTAX 1.3.6.1.4.1.1466.115.121.1.12SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) Wahl, et. al. Standards Track [Page 12]This attribute SHOULD appear in entries which have been modifiedusing the Modify operation.( 2.5.18.4 NAME ’modifiersName’ EQUALITY distinguishedNameMatchSYNTAX 1.3.6.1.4.1.1466.115.121.1.12SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )5.1.5. subschemaSubentryThe value of this attribute is the name of a subschema entry (orsubentry if the server is based on X.500(93)) in which the servermakes available attributes specifying the schema.( 2.5.18.10 NAME ’subschemaSubentry’EQUALITY distinguishedNameMatchSYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATIONSINGLE-VALUE USAGE directoryOperation )5.1.6. attributeTypesThis attribute is typically located in the subschema entry.( 2.5.21.5 NAME ’attributeTypes’EQUALITY objectIdentifierFirstComponentMatchSYNTAX 1.3.6.1.4.1.1466.115.121.1.3 USAGE directoryOperation )5.1.7. objectClassesThis attribute is typically located in the subschema entry.( 2.5.21.6 NAME ’objectClasses’EQUALITY objectIdentifierFirstComponentMatchSYNTAX 1.3.6.1.4.1.1466.115.121.1.37 USAGE directoryOperation )5.1.8. matchingRulesThis attribute is typically located in the subschema entry.( 2.5.21.4 NAME ’matchingRules’EQUALITY objectIdentifierFirstComponentMatchSYNTAX 1.3.6.1.4.1.1466.115.121.1.30 USAGE directoryOperation ) Wahl, et. al. Standards Track [Page 13]This attribute is typically located in the subschema entry.( 2.5.21.8 NAME ’matchingRuleUse’EQUALITY objectIdentifierFirstComponentMatchSYNTAX 1.3.6.1.4.1.1466.115.121.1.31 USAGE directoryOperation )5.2. LDAP Operational AttributesThese attributes are only present in the root DSE (see [1] and [3]).Servers MUST recognize these attribute names, but it is not required that a server provide values for these attributes, when the attribute corresponds to a feature which the server does not implement.5.2.1. namingContextsThe values of this attribute correspond to naming contexts which this server masters or shadows. If the server does not master anyinformation (e.g. it is an LDAP gateway to a public X.500 directory) this attribute will be absent. If the server believes it containsthe entire directory, the attribute will have a single value, andthat value will be the empty string (indicating the null DN of theroot). This attribute will allow a client to choose suitable baseobjects for searching when it has contacted a server.( 1.3.6.1.4.1.1466.101.120.5 NAME ’namingContexts’SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 USAGE dSAOperation )5.2.2. altServerThe values of this attribute are URLs of other servers which may becontacted when this server becomes unavailable. If the server doesnot know of any other servers which could be used this attribute will be absent. Clients may cache this information in case their preferred LDAP server later becomes unavailable.( 1.3.6.1.4.1.1466.101.120.6 NAME ’altServer’SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 USAGE dSAOperation )5.2.3. supportedExtensionThe values of this attribute are OBJECT IDENTIFIERs identifying thesupported extended operations which the server supports.If the server does not support any extensions this attribute will be absent.Wahl, et. al. Standards Track [Page 14]。