Network Working Group R. Hedberg
Request for Comments: 2654 Catalogix
Category: Experimental B. Greenblatt
Directory Tools and Application Services, Inc.
R. Moats
AT&T
M. Wahl
Innosoft International, Inc.
August 1999
Network Working Group R. Hedberg
Request for Comments: 2654 Catalogix
Category: Experimental B. Greenblatt
Directory Tools and Application Services, Inc.
R. Moats
AT&T
M. Wahl
Innosoft International, Inc.
August 1999
A Tagged Index Object for use in the Common Indexing Protocol
在通用索引协议中使用的标记索引对象
Status of this Memo
本备忘录的状况
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
This document defines a mechanism by which information servers can exchange indices of information from their databases by making use of the Common Indexing Protocol (CIP). This document defines the structure of the index information being exchanged, as well as the appropriate meanings for the headers that are defined in the Common Indexing Protocol. It is assumed that the structures defined here can be used by X.500 DSAs, LDAP servers, Whois++ servers, CSO Ph servers and many others.
本文档定义了一种机制，通过该机制，信息服务器可以使用通用索引协议（CIP）从其数据库交换信息索引。本文档定义了正在交换的索引信息的结构，以及通用索引协议中定义的标题的适当含义。假设此处定义的结构可供X.500 DSA、LDAP服务器、Whois++服务器、CSO Ph服务器和许多其他服务器使用。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. The Tagged Index Object . . . . . . . . . . . . . . . . . . . . 5
4.1. The Agreement . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Content Type . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3 Tagged Index BNF . . . . . . . . . . . . . . . . . . . . . . . 9
4.3.1. Header Descriptions . . . . . . . . . . . . . . . . . . . .10
4.3.2. Tokenization types . . . . . . . . . . . . . . . . . . . .11
4.3.3. Tag Conventions . . . . . . . . . . . . . . . . . . . . . .11
4.4. Incremental Indexing . . . . . . . . . . . . . . . . . . . .12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. The Tagged Index Object . . . . . . . . . . . . . . . . . . . . 5
4.1. The Agreement . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Content Type . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3 Tagged Index BNF . . . . . . . . . . . . . . . . . . . . . . . 9
4.3.1. Header Descriptions . . . . . . . . . . . . . . . . . . . .10
4.3.2. Tokenization types . . . . . . . . . . . . . . . . . . . .11
4.3.3. Tag Conventions . . . . . . . . . . . . . . . . . . . . . .11
4.4. Incremental Indexing . . . . . . . . . . . . . . . . . . . .12
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .13
5.1 The original database . . . . . . . . . . . . . . . . . . . .13
5.1.1 "complete" consistency based full update . . . . . . . . . .14
5.1.2 "tag" consistency based full update . . . . . . . . . . . .14
5.1.3 "unique" consistency based full update . . . . . . . . . . .15
5.2 First update . . . . . . . . . . . . . . . . . . . . . . . . .16
5.2.1 "complete" consistency based incremental update . . . . . .16
5.2.2 "tag" consistency based incremental update . . . . . . . .17
5.2.3 "unique" consistency based incremental update . . . . . . .17
5.3 Second update . . . . . . . . . . . . . . . . . . . . . . . .18
5.3.1 "complete" consistency based incremental update . . . . . .18
5.3.2 "tag" consistency based incremental update . . . . . . . . .19
5.3.3 "unique" consistency based incremental update . . . . . . .20
6. Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . .21
6.1 Aggregation of Tagged Index Objects . . . . . . . . . . . . .21
7. Security Considerations . . . . . . . . . . . . . . . . . . . .21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . .22
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .23
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . .24
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .13
5.1 The original database . . . . . . . . . . . . . . . . . . . .13
5.1.1 "complete" consistency based full update . . . . . . . . . .14
5.1.2 "tag" consistency based full update . . . . . . . . . . . .14
5.1.3 "unique" consistency based full update . . . . . . . . . . .15
5.2 First update . . . . . . . . . . . . . . . . . . . . . . . . .16
5.2.1 "complete" consistency based incremental update . . . . . .16
5.2.2 "tag" consistency based incremental update . . . . . . . .17
5.2.3 "unique" consistency based incremental update . . . . . . .17
5.3 Second update . . . . . . . . . . . . . . . . . . . . . . . .18
5.3.1 "complete" consistency based incremental update . . . . . .18
5.3.2 "tag" consistency based incremental update . . . . . . . . .19
5.3.3 "unique" consistency based incremental update . . . . . . .20
6. Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . .21
6.1 Aggregation of Tagged Index Objects . . . . . . . . . . . . .21
7. Security Considerations . . . . . . . . . . . . . . . . . . . .21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . .22
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .23
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . .24
The Common Indexing Protocol (CIP) as defined in [1] proposes a mechanism for distributing searches across several instances of a single type of search engine to create a global directory. CIP provides a scalable, flexible scheme to tie individual databases into distributed data warehouses that can scale gracefully with the growth of the Internet. CIP provides a mechanism for meeting these goals that is independent of the access method that is used to access the data that underlies the indices. Separate from CIP is the definition of the Index Object that is used to contain the information that is exchanged among Index Servers. One such Index Object that has already been defined is the Centroid that is derived from the Whois++ protocol [2].
[1]中定义的公共索引协议（CIP）提出了一种机制，用于在单一类型搜索引擎的多个实例之间分配搜索，以创建全局目录。CIP提供了一种可扩展、灵活的方案，将单个数据库绑定到分布式数据仓库中，这些数据仓库可以随着Internet的增长而优雅地扩展。CIP提供了一种实现这些目标的机制，该机制独立于用于访问索引基础数据的访问方法。与CIP不同的是用于包含索引服务器之间交换的信息的索引对象的定义。其中一个已经定义的索引对象是源自Whois++协议[2]的形心。
The Centroid does not meet all the requirements for the exchange of index information amongst information servers. For example, it does not support the notion of incremental updates natively. For information servers that contain millions of records in their database, constant exchange of complete dredges of the database is bandwidth intensive. The Tagged Index Object is specifically designed to support the exchange of index update information. This design comes at the cost of an increase in the size of the index object being exchanged. The Centroid is also not tailored to always be able to give boolean answers to queries. In the Centroid Model, "an index server will take a query in standard Whois++ format, search its collections of centroids and other forward information, determine which servers hold records which may fill that query, and then
质心不能满足信息服务器之间交换索引信息的所有要求。例如，它不支持本机增量更新的概念。对于数据库中包含数百万条记录的信息服务器，不断交换数据库的完整数据是带宽密集型的。标记的索引对象专门用于支持索引更新信息的交换。这种设计是以交换的索引对象的大小增加为代价的。质心也不是为始终能够给出布尔查询答案而定制的。在质心模型中，“索引服务器将接受标准Whois++格式的查询，搜索其质心集合和其他转发信息，确定哪些服务器保存可能填充该查询的记录，然后
notifies the user's client of the next servers to contact to submit the query." [2] Thus, the exchange of Centroids amongst index servers allows hints to be given about which information server actually contains the information. The Tagged Index Object labels the various pieces of information with identifiers that tie the individual object attributes back to an object as a whole. This "tagging" of information allows an index server to be more capable of directing a specific query to the appropriate information server. Again, this feature is added to the Tagged Index Object at the expense of an increase in the size of the index object.
通知用户的客户端下一个要联系以提交查询的服务器。“[2]因此，索引服务器之间的质心交换允许给出关于哪个信息服务器实际包含信息的提示。带标签的索引对象使用标识符标记各种信息，这些标识符将单个对象属性绑定回一个对象作为一个整体“信息共享使索引服务器能够更有效地将特定查询定向到适当的信息服务器。同样，将此功能添加到标记的索引对象中，代价是索引对象的大小增加。
The Lightweight Directory Access Protocol (LDAP) is defined in [3], and it defines a mechanism for accessing a collection of information arranged hierarchically in such a way as to provide a globally distributed database which is normally called the Directory Information Tree (DIT). Some distinguishing characteristics of LDAP servers are that normally, several servers cooperate to manage a common subtree of the DIT. LDAP servers are expected to respond to requests that pertain to portions of the DIT for which they have data, as well as for those portions for which they have no information in their database. For example, the LDAP server for a portion of the DIT in the United States (c=US) must be able to provide a response to a Search operation that pertains to a portion of the DIT in Sweden (c=se). Normally, the response given will be a referral to another LDAP server that is expected to be more knowledgeable about the appropriate subtree. However, there is no mechanism that currently enables these LDAP servers to refer the LDAP client to the supposedly more knowledgeable server. Typically, an LDAP (v3) server is configured with the name of exactly one other LDAP server to which all LDAP clients are referred when their requests fall outside the subtree of the DIT for which that LDAP server has knowledge. This specification defines a mechanism whereby LDAP server can exchange index information that will allow referrals to point towards a clearly accurate destination.
轻量级目录访问协议（LDAP）在[3]中定义，它定义了一种访问分层排列的信息集合的机制，以提供一个通常称为目录信息树（DIT）的全局分布式数据库。LDAP服务器的一些显著特征是，通常情况下，多个服务器协作管理DIT的一个公共子树。LDAP服务器需要响应与DIT中有数据的部分相关的请求，以及与数据库中没有信息的部分相关的请求。例如，美国部分DIT（c=US）的LDAP服务器必须能够响应与瑞典部分DIT（c=se）相关的搜索操作。通常，给出的响应将是对另一个LDAP服务器的引用，该服务器应该更了解相应的子树。但是，目前还没有任何机制使这些LDAP服务器能够将LDAP客户机引用到假定知识更丰富的服务器。通常，LDAP（v3）服务器配置为正好是一个其他LDAP服务器的名称，当所有LDAP客户机的请求位于该LDAP服务器所知道的DIT子树之外时，所有LDAP客户机都会被引用到该LDAP服务器。该规范定义了一种机制，LDAP服务器可以通过该机制交换索引信息，从而允许引用指向明确准确的目标。
The X.500 series of recommendations defines the Directory Information Shadowing Protocol (DISP) [4] which allows X.500 DSAs to exchange information in the DIT. Shadowing allows various information from various portions of the DIT to be replicated amongst participating DSAs. The design point of DISP is improved at the exchange of entire portions of the DIT, whereas the design point of CIP and the Tagged Index Object is optimized at the exchange of structural index information about the DIT, and improving the performance of tree navigation amongst various information servers. The Tagged Index Object is more appropriate for the exchange of index information than is DISP. DISP is more targeted at DIT distribution and fault
X.500系列建议定义了目录信息隐藏协议（DISP）[4]，该协议允许X.500 DSA在DIT中交换信息。阴影允许来自DIT不同部分的各种信息在参与的DSA之间复制。DISP的设计点在交换DIT的整个部分时得到改进，而CIP和标记索引对象的设计点在交换DIT的结构索引信息时得到优化，并在各种信息服务器之间提高树导航的性能。标记的索引对象比DISP更适合交换索引信息。DISP更针对DIT分布和故障
tolerance. DISP is thus more appropriate for the exchange of the data in order to spread the load amongst several information servers. DISP is tailored specifically to X.500 (and other hierarchical directory systems), while the Tagged Index Object and CIP can be used in a wide variety of information server environments.
容忍因此，DISP更适合于数据交换，以便在多个信息服务器之间分散负载。DISP专门为X.500（和其他分层目录系统）定制，而标记的索引对象和CIP可用于各种信息服务器环境。
While DISP allows an individual directory server to collect information about large parts of the DIT, it would require a huge database to collect all the replicas for a significant portion of the DIT. Furthermore, as X.525 states: "Before shadowing can occur, an agreement, covering the conditions under which shadowing may occur is required. Although such agreements may be established in a variety of ways, such as policy statements covering all DSAs within a given DMD ...", where a DMD is a Directory Management Domain. This is owing to the case that the data in the DIT is being exchanged amongst DSA rather than only the information required to maintain an Index. In many environments such an agreement is not appropriate, and to collect information for a meaningful portion of the DIT, many agreements may need to be arranged.
虽然DISP允许单个目录服务器收集有关大部分DIT的信息，但它需要一个庞大的数据库来收集大部分DIT的所有副本。此外，正如X.525所述：“在进行跟踪之前，需要一份涵盖跟踪可能发生的条件的协议。尽管可以通过多种方式建立此类协议，例如覆盖给定DMD内所有DSA的策略声明……”，其中DMD是一个目录管理域。这是因为DIT中的数据在DSA之间交换，而不仅仅是维护索引所需的信息。在许多环境中，这样的协议并不合适，为了收集DIT有意义部分的信息，可能需要安排许多协议。
What is desired is to have an information server (or network of information servers) that can quickly respond to real world requests, like:
我们希望有一个能够快速响应现实世界请求的信息服务器（或信息服务器网络），如：
- What is Tim Howes's email address? This is much harder than; What email address does Tim Howes at Netscape have ?
- 蒂姆·豪斯的电子邮件地址是什么？这比,；网景公司的蒂姆·豪斯有什么电子邮件地址？
- What is the X.509 certificate for Fred Smith at compuserve.com? One certainly doesn't want to search CompuServe's entire directory tree to find out this one piece of information. I also don't want to have to shadow the entire CompuServe directory subtree onto my server. If this request is being made because Fred is trying to log into my server, I'd certainly want to be able to respond to the BIND in real time.
- 在compuserve.com上，弗雷德·史密斯的X.509证书是什么？人们当然不想搜索CompuServe的整个目录树来找出这一条信息。我也不想把整个CompuServe目录子树都隐藏到我的服务器上。如果这个请求是因为Fred试图登录我的服务器而发出的，我当然希望能够实时响应绑定。
- Who are all the people at Novell that have a title of programmer?
- Novell公司有程序员头衔的人都是谁？
all these requests can reasonably be translated into LDAP or Whois++, and other directory access protocol queries. They can also be serviced in a straightforward way by the users home information server if it has the appropriate reference information into the database that contains the source data. Here, the first server would be able to "chain" the request for the user. Alternatively, a precise referral could be returned. If the home information server wants to service (i.e chain) the request based on the index
所有这些请求都可以合理地转换为LDAP或Whois++以及其他目录访问协议查询。如果用户家庭信息服务器在包含源数据的数据库中具有适当的参考信息，则用户家庭信息服务器也可以直接为它们提供服务。在这里，第一个服务器将能够为用户“链接”请求。或者，可以返回精确的转诊。如果家庭信息服务器希望基于索引为请求提供服务（即链接）
information that it has on hand, this servicing could be done several different means:
根据手头的信息，可以通过几种不同的方式进行此项维修：
- issuing LDAP operations to the remote directory server
- 向远程目录服务器发出LDAP操作
- issuing DSP operations to the remote directory server
- 向远程目录服务器发出DSP操作
- issuing DAP operations to the remote directory server
- 向远程目录服务器发出DAP操作
- issuing Whois++ operations to the remote Whois++ server
- 向远程Whois++服务器发出Whois++操作
- ...
- ...
This section defines a Tagged Index Object that can be exchanged by Information Servers using CIP. While often it is acceptable for Information Servers to make use of the Centroid definition (from [2]) to exchange index information, the goals in defining a new construct are multi-pronged:
本节定义了可由信息服务器使用CIP交换的标记索引对象。虽然信息服务器通常可以使用质心定义（见[2]）来交换索引信息，但定义新构造的目标是多管齐下的：
- When the Information Server receives a search request that warrants that a referral be returned, allow the server to return a referral that will point client to a server that is most likely able to answer the request correctly. False positive referrals (the search turns up hits in the index object that generate referrals to servers that don't hold the desired information) can be reduced, depending on the choice of attribute tokenization types that are used.
- 当信息服务器接收到保证返回引用的搜索请求时，允许服务器返回将客户端指向最有可能正确响应请求的服务器的引用。根据所使用的属性标记化类型的选择，可以减少误报引用（搜索会在索引对象中找到指向不包含所需信息的服务器的引用的命中率）。
- Potentially allow incremental updates that will then consume substantially less bandwidth then if full updates always had to be used.
- 如果必须始终使用完整更新，则可能会允许增量更新，从而消耗更少的带宽。
Before a Tagged Index Object can be exchanged, the organization that administers the object supplier and the organization that administers the object consumer must reach an agreement on how the servers will communicate. This agreement contains the following:
在交换标记的索引对象之前，管理对象供应商的组织和管理对象使用者的组织必须就服务器的通信方式达成协议。本协议包含以下内容：
- "index-type": This specification describes the index type "x-tagged-index-1"
- “索引类型”：本规范描述了索引类型“x-tagged-index-1”
- "dsi": An OID that uniquely identifies the subtree and scope. This field is not explicitly necessary, as it may not provide information beyond what is contained in the "base-uri" below.
- “dsi”：唯一标识子树和作用域的OID。此字段不是显式必需的，因为它提供的信息可能不超过下面“基本uri”中包含的内容。
- "base-uri": One or more URI's that will form the base of any referrals created based on the index object that is governed by this agreement. For example, in the LDAP URL format [8] the base-uri would specify (among other items): the LDAP host, the base object to which this index object refers (e.g. c=SE), and the scope of the index object (e.g. single container).
- “基本uri”：一个或多个uri，将构成根据本协议管辖的索引对象创建的任何引用的基础。例如，在LDAP URL格式[8]中，基本uri将指定（除其他项外）：LDAP主机、此索引对象所引用的基本对象（例如c=SE）和索引对象的范围（例如单个容器）。
- "supplier": The hostname and listening portnumber of the supplier server, as well as any alternative servers holding that same naming contexts, if the supplier is unavailable.
- “供应商”：供应商服务器的主机名和侦听端口号，以及持有相同命名上下文的任何备用服务器（如果供应商不可用）。
- "consumeraddr": This is a URI of the "mailto:" form, with the RFC 822 email address of the consumer server. Further versions of this draft allow other forms of URI, so that the consumer may retrieve the update via the WWW, FTP or CIP.
- “consumeraddr”：这是“mailto:”表单的URI，具有消费者服务器的RFC 822电子邮件地址。本草案的进一步版本允许其他形式的URI，以便消费者可以通过WWW、FTP或CIP检索更新。
- "updateinterval": The maximum duration in seconds between occurances of the supplier server generating an update. If the consumer server has not received an update from the supplier server after waiting this long since the previous update, it is likely that the index information is now out of date. A typical value for a server with frequent updates would be 604800 seconds, or every week. Servers whose DITs are only modified annually could have a much longer update interval.
- “updateinterval”：供应商服务器生成更新之间的最长持续时间（秒）。如果消费者服务器在上次更新后等待了这么长时间后仍未收到供应商服务器的更新，则索引信息现在可能已过期。频繁更新的服务器的典型值为604800秒或每周。仅每年修改DIT的服务器的更新间隔可能要长得多。
- "attributeNamespace": Every set of index servers that together wants to support a specific usage of indeces, has to agree on which attributenames to use in the index objects. The participating directory servers also has to agree on the mapping from local attributenames to the attributenames used in the index. Since one specific index server might be involved in several such sets, it has to have some way to connect a update to the proper set of indexes. One possible solution to this would be to use different DSIs.
- “attributeNamespace”：想要共同支持索引的特定用法的每一组索引服务器，必须就在索引对象中使用哪些attributenames达成一致。参与的目录服务器还必须就从本地AttributeName到索引中使用的AttributeName的映射达成一致。由于一个特定的索引服务器可能涉及多个这样的集合，因此它必须有某种方式将更新连接到适当的索引集合。一种可能的解决方案是使用不同的DSI。
- "consistencybase": How consistency of the index is maintained over incremental updates:
- “一致性数据库”：如何在增量更新期间保持索引的一致性：
"complete" - every change or delete concerning one object has to contain all tokens connected to that object. This method must be supported by any server who wants to comply with this standard.
“完成”-关于一个对象的每个更改或删除都必须包含连接到该对象的所有标记。任何希望遵守此标准的服务器都必须支持此方法。
"tag" - starting at a full update every incremental update refering back to this full updated has to maintain state-information regarding tags, such that a object within the original database is assigned the same tagnumber every time. This method is optional.
“标记”-从完全更新开始，每次引用此完全更新的增量更新都必须维护有关标记的状态信息，以便每次为原始数据库中的对象分配相同的标记号。此方法是可选的。
"unique" - every object in the Dataset has to have a unique value for a specific attribute in the index. A example of such a attribute could be the distinguishedName attribute. This method is also optional.
“唯一”-数据集中的每个对象都必须具有索引中特定属性的唯一值。这种属性的一个示例可以是DiscriminatedName属性。此方法也是可选的。
- "securityoption": Whether and how the supplier server should sign and encrypt the update before sending it to the consumer server. Options for this version of the specification are:
- “securityoption”：供应商服务器是否以及如何在将更新发送到消费者服务器之前对其进行签名和加密。此版本规范的选项包括：
"none" - the update is sent in plaintext
“无”-更新以明文形式发送
"PGP/MIME": the update is digitally signed and encrypted using PGP [9]
“PGP/MIME”：使用PGP[9]对更新进行数字签名和加密
"S/MIME": the update is digitally signed and encrypted using S/MIME [10]
“S/MIME”：使用S/MIME对更新进行数字签名和加密[10]
"SSLv3": the update is digitally signed and encrypted using an SSLv3 connection [11]
“SSLv3”：使用SSLv3连接对更新进行数字签名和加密[11]
"Fortezza": the update is digitally signed and encrypted using Fortezza [5]
“Fortezza”：使用Fortezza[5]对更新进行数字签名和加密
It is recommended that the "PGP/MIME" option be used when exchanging sensitive information across public networks, and both the supplier and consumer have PGP keys. The "Fortezza" option is intended for use in environments where security protocols are based on Fortezza-compatible devices. The "S/MIME" option can be used with both the supplier and consumer have RSA keys and can make use of the PKCS protocols defined in the S/MIME specification. The "SSLv3" option can be used when both the supplier and consumer have access to SSL services, have server certificates, and can mutually authenticate each other.
建议在通过公共网络交换敏感信息时使用“PGP/MIME”选项，并且供应商和消费者都有PGP密钥。“Fortezza”选项适用于安全协议基于Fortezza兼容设备的环境。“S/MIME”选项可用于供应商和消费者都拥有RSA密钥的情况，并可使用S/MIME规范中定义的PKCS协议。当供应商和消费者都可以访问SSL服务、拥有服务器证书并且可以相互认证时，可以使用“SSLv3”选项。
- Security Credentials: The long-term cryptographic credentials used for key exchange and authentication of the consumer and supplier servers, if a security option was selected. For "PGP/MIME," this will be the trusted public keys of both servers. For "Fortezza," this will be the certificate paths of both servers to a common point of trust. For "S/MIME" and "SSLv3" these will be the certificates of the supplier and consumer.
- 安全凭据：如果选择了安全选项，则用于用户和供应商服务器的密钥交换和身份验证的长期加密凭据。对于“PGP/MIME”，这将是两个服务器的受信任公钥。对于“Fortezza”，这将是两台服务器到公共信任点的证书路径。对于“S/MIME”和“SSLv3”，这些将是供应商和消费者的证书。
Note that if the index server maintains the information that would appear in the agreement in a directory according to the definitions in [7], then no real formal agreement between the two parties needs to be put in place, and the information that is required for communication between the two index servers is derived automatically from the directory.
请注意，如果索引服务器根据[7]中的定义将出现在协议中的信息保存在目录中，则双方之间不需要真正的正式协议，两个索引服务器之间通信所需的信息自动从目录中导出。
The update consists of a MIME object of type application/cip-index-object. The parameters are:
更新由类型为application/cip index object的MIME对象组成。参数包括：
"type": this has value "application/index.obj.tagged".
“类型”：其值为“application/index.obj.taged”。
"dsi": the DSI (if any) from the agreement.
“dsi”：协议中的dsi（如有）。
"base-uri". A set of URIs, separated by spaces. In each URI, the hostname/portno must be distinct, and based on the "supplier" part of the agreement.
“基本uri”。由空格分隔的一组URI。在每个URI中，主机名/端口号必须是不同的，并且基于协议的“供应商”部分。
The payload is mostly textual data but may include bytes with the high bit set. The originating information server should set the content-transfer-encoding as appropriate for the information included in the payload.
有效负载主要是文本数据，但可能包括设置了高位的字节。原始信息服务器应针对有效负载中包含的信息适当设置内容传输编码。
This object may be encapsulated in a wrapper content (such as multipart/signed) or be encrypted as part of the security procedures. The resulting content can the distributed, for example via electronic mail. For example,
该对象可以封装在包装内容中（例如多部分/签名），或者作为安全过程的一部分进行加密。生成的内容可以分发，例如通过电子邮件。例如
From: supplier@sup.com Date: Thu, 16 Jan 1997 13:50:37 -0500
Message-Id: <199701161850.NAA29295@sup.com>;
To: consumer@consumer.com <<-- from consumer server address
From: supplier@sup.com Date: Thu, 16 Jan 1997 13:50:37 -0500
Message-Id: <199701161850.NAA29295@sup.com>;
To: consumer@consumer.com <<-- from consumer server address
Reply-to: supplier-admin@sup.com
MIME-Version: 1.0
Content-Type: application/index.obj.tagged;
dsi=1.3.6.1.4.1.1466.85.85.1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16;
base-uri="ldap://sup.com/dc=sup,dc=com ldap://alt.com/dc=sup,dc=com"
Reply-to: supplier-admin@sup.com
MIME-Version: 1.0
Content-Type: application/index.obj.tagged;
dsi=1.3.6.1.4.1.1466.85.85.1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16;
base-uri="ldap://sup.com/dc=sup,dc=com ldap://alt.com/dc=sup,dc=com"
The payload is series of CRLF-terminated lines. The payload is UTF-8. Some supplier servers may only be able to generate the printable US-ASCII subset of UTF-8, but all consumer servers must be able to handle the full range of Unicode characters when decoding the attribute values (in the "attr-value" field in the BNF below).
有效载荷是一系列CRLF端接线路。有效载荷为UTF-8。某些供应商服务器可能只能生成UTF-8的可打印US-ASCII子集，但所有消费者服务器在解码属性值时必须能够处理全部Unicode字符（在下面BNF的“attr值”字段中）。
The Tagged Index object has the following grammar, expressed in modified BNF format:
标记的索引对象具有以下语法，以修改后的BNF格式表示：
index-object = 0*(io-part SEP) io-part
io-part = header SEP schema-spec SEP index-info
header = version-spec SEP update-type SEP this-update SEP
last-update context-size name-space SEP
version-spec = "version:" *SPACE "x-tagged-index-1"
update-type = "updatetype:" *SPACE ( "total" |
( "incremental" [*SPACE "tagbased"|"uniqueIDbased" ] )
this-update = "thisupdate:" *SPACE TIMESTAMP
last-update = [ "lastupdate:" *SPACE TIMESTAMP SEP]
context-size = [ "contextsize:" *SPACE 1*DIGIT SEP]
schema-spec = "BEGIN IO-Schema" SEP 1*(schema-line SEP)
"END IO-Schema"
schema-line = attribute-name ":" token-type
token-type = "FULL" | "TOKEN" | "RFC822" | "UUCP" | "DNS"
index-info = full-index | incremental-index
full-index = "BEGIN Index-Info" SEP 1*(index-block SEP)
"END Index-Info"
incremental-index = 1*(add-block | delete-block | update-block)
add-block = "BEGIN Add Block" SEP 1*(index-block SEP)
"END Add Block"
delete-block = "BEGIN Delete Block" SEP 1*(index-block SEP)
"END Delete Block"
update-block = "BEGIN Update Block" SEP
0*(old-index-block SEP)
1*(new-index-block SEP)
"END Update Block"
old-index-block = "BEGIN Old" SEP 1*(index-block SEP)
"END Old"
new-index-block = "BEGIN New" SEP 1*(index-block SEP)
"END New"
index-block = first-line 0*(SEP cont-line)
first-line = attr-name ":" *SPACE taglist "/" attr-value
cont-line = "-" taglist "/" attr-value
taglist = tag 0*("," tag) | "*"
tag = 1*DIGIT ["-" 1*DIGIT]
attr-value = 1*(UTF8)
attr-name = 1*(NAMECHAR)
TIMESTAMP = 1*DIGIT
NAMECHAR = DIGIT | UPPER | LOWER | "-" | ";" | "."
SPACE = <ASCII space, %x20>;
SEP = (CR LF) | LF
CR = <ASCII CR, carriage return, %x0D>;
LF = <ASCII LF, line feed, %x0A>;
index-object = 0*(io-part SEP) io-part
io-part = header SEP schema-spec SEP index-info
header = version-spec SEP update-type SEP this-update SEP
last-update context-size name-space SEP
version-spec = "version:" *SPACE "x-tagged-index-1"
update-type = "updatetype:" *SPACE ( "total" |
( "incremental" [*SPACE "tagbased"|"uniqueIDbased" ] )
this-update = "thisupdate:" *SPACE TIMESTAMP
last-update = [ "lastupdate:" *SPACE TIMESTAMP SEP]
context-size = [ "contextsize:" *SPACE 1*DIGIT SEP]
schema-spec = "BEGIN IO-Schema" SEP 1*(schema-line SEP)
"END IO-Schema"
schema-line = attribute-name ":" token-type
token-type = "FULL" | "TOKEN" | "RFC822" | "UUCP" | "DNS"
index-info = full-index | incremental-index
full-index = "BEGIN Index-Info" SEP 1*(index-block SEP)
"END Index-Info"
incremental-index = 1*(add-block | delete-block | update-block)
add-block = "BEGIN Add Block" SEP 1*(index-block SEP)
"END Add Block"
delete-block = "BEGIN Delete Block" SEP 1*(index-block SEP)
"END Delete Block"
update-block = "BEGIN Update Block" SEP
0*(old-index-block SEP)
1*(new-index-block SEP)
"END Update Block"
old-index-block = "BEGIN Old" SEP 1*(index-block SEP)
"END Old"
new-index-block = "BEGIN New" SEP 1*(index-block SEP)
"END New"
index-block = first-line 0*(SEP cont-line)
first-line = attr-name ":" *SPACE taglist "/" attr-value
cont-line = "-" taglist "/" attr-value
taglist = tag 0*("," tag) | "*"
tag = 1*DIGIT ["-" 1*DIGIT]
attr-value = 1*(UTF8)
attr-name = 1*(NAMECHAR)
TIMESTAMP = 1*DIGIT
NAMECHAR = DIGIT | UPPER | LOWER | "-" | ";" | "."
SPACE = <ASCII space, %x20>;
SEP = (CR LF) | LF
CR = <ASCII CR, carriage return, %x0D>;
LF = <ASCII LF, line feed, %x0A>;
DIGIT = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
"8" | "9"
DIGIT = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
"8" | "9"
UPPER = "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"
LOWER = "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"
UPPER = "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"
LOWER = "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"
US-ASCII-SAFE = %x01-09 / %x0B-0C / %x0E-7F
;; US-ASCII except CR, LF, NUL
UTF8 = US-ASCII-SAFE / UTF8-1 / UTF8-2 / UTF8-3
/ UTF8-4 / UTF8-5
UTF8-CONT = %x80-BF
UTF8-1 = %xC0-DF UTF8-CONT
UTF8-2 = %xE0-EF 2UTF8-CONT
UTF8-3 = %xF0-F7 3UTF8-CONT
UTF8-4 = %xF8-FB 4UTF8-CONT
UTF8-5 = %xFC-FD 5UTF8-CONT
US-ASCII-SAFE = %x01-09 / %x0B-0C / %x0E-7F
;; US-ASCII except CR, LF, NUL
UTF8 = US-ASCII-SAFE / UTF8-1 / UTF8-2 / UTF8-3
/ UTF8-4 / UTF8-5
UTF8-CONT = %x80-BF
UTF8-1 = %xC0-DF UTF8-CONT
UTF8-2 = %xE0-EF 2UTF8-CONT
UTF8-3 = %xF0-F7 3UTF8-CONT
UTF8-4 = %xF8-FB 4UTF8-CONT
UTF8-5 = %xFC-FD 5UTF8-CONT
The set of characters allowed to appear in the attr-name field is limited to the set of characters used in LDAP and WHOIS++ attribute names. For other services that have attribute name character sets that are larger than these, those services should create a profile that maps the names onto object identifiers, and the sequence of digits and periods is used by those services in creating the attr-name fields for their Tagged Index Objects.
允许出现在attr name字段中的字符集仅限于LDAP和WHOIS++属性名称中使用的字符集。对于属性名称字符集大于这些字符集的其他服务，这些服务应创建一个配置文件，将名称映射到对象标识符上，这些服务在为其标记的索引对象创建attr name字段时使用数字和句点序列。
It is worth mentioning that updates to a index based in tagged index objects MUST be performed in the order specified by the tagged index object itself.
值得一提的是，对基于标记索引对象的索引的更新必须按照标记索引对象本身指定的顺序执行。
The header section consists of one or more "header lines". The following header lines are defined:
标题部分由一个或多个“标题行”组成。定义了以下标题行：
"version": This line must always be present, and have the value "x-tagged-index-1" for this version of the specification.
“版本”：该行必须始终存在，并且该版本规范的值为“x-tagged-index-1”。
"updatetype": This line must always be present. It takes as the value either "total" or "incremental". The first update sent by a supplier server to a consumer server for a DSI must be a "total" update.
“updatetype”：此行必须始终存在。它采用“总计”或“增量”作为值。供应商服务器向DSI的消费者服务器发送的第一个更新必须是“全部”更新。
"thisupdate": This line must always be present. The value is the number of seconds from 00:00:00 UTC January 1, 1970 at which the supplier constructed this update.
“thisupdate”：此行必须始终存在。该值是从UTC 1970年1月1日00:00:00开始供应商构建此更新的秒数。
"lastupdate": This line must be present if the "updatetype" list has the value "incremental". The value is the number of seconds from 00:00:00 UTC January 1, 1970 at which the supplier constructed the previous update sent to the consumer. This field allows the consumer to determine if a previous update was missed
“lastupdate”：如果“updatetype”列表的值为“incremental”，则该行必须存在。该值是从UTC 1970年1月1日00:00:00开始的秒数，供应商在该时间构建发送给消费者的上一次更新。此字段允许使用者确定是否错过了以前的更新
"contextsize": This line may be present at the supplier's option. The value is a number, which is the approximate total number of entries in the subtree. This information is provided for statistical purposes only.
“contextsize”：该行可由供应商选择。该值是一个数字，是子树中条目的大致总数。此信息仅供统计之用。
The Tagged Index Object inherits the "TOKEN" scheme for tokenization as specified in [2]. In addition, there are several other tokenization schemes defined for the Tagged Index Object. The following table presents these schemes and what character(s) are used to delimit tokens.
标记的索引对象继承了[2]中指定的标记化“标记”方案。此外，还为标记索引对象定义了几个其他标记化方案。下表显示了这些方案以及用于分隔令牌的字符。
Token Type Tokenization Characters FULL none TOKEN white space, "@" RFC822 white space, ".", "@" UUCP white space, "!" DNS any character note a number, letter, or "-"
令牌类型令牌化字符完全无令牌空白，“@”RFC822空白，“.”，“@”UUCP空白，“！”DNS任意字符注释数字、字母或“-”
In the tag list, multiple consecutive tags may be shortened by using "#-#". For example, the list "3,4,5,6,7,8,9,10" may be shortened to "3-10". Tags are to be applied to the data on a per entry level. Thus, if two index lines in the same index object contain the same tag, then those two lines always refer to the same "record" in the directory. In LDAP terminology, the two lines would refer to the same directory object. Additionally if two index lines in the same index object contain different tags, then it is always the case that those two lines refer back to different records in the directory. The meaning of '*' in the tag position is that that specific token apears in every record in the directory.
在标记列表中，可以使用“#-#”缩短多个连续标记。例如，列表“3,4,5,6,7,8,9,10”可以缩短为“3-10”。标记将按条目级别应用于数据。因此，如果同一索引对象中的两个索引行包含相同的标记，那么这两行总是引用目录中相同的“记录”。在LDAP术语中，这两行表示相同的目录对象。另外，如果同一索引对象中的两个索引行包含不同的标记，那么这两行总是引用目录中的不同记录。标记位置中“*”的含义是，该特定标记将出现在目录中的每个记录中。
The tag applied to the same underlying record in two separate transmissions of a full-index may be different. Thus, receiving index servers should make no assumptions about the values of the tags across index object boundaries.
在完整索引的两次单独传输中应用于相同基础记录的标记可能不同。因此，接收索引服务器不应该对跨索引对象边界的标记值进行任何假设。
The tagged index object format supports the ability of information servers to distribute only delta index data, rather than distributing total index information each time. This scenario, known as incremental indexing supports three basic types of operations: add, delete and replace. If the incremental updatetype is specified in the tagged index object, then the index object contains a snapshot of only the changes that have been made since the index object specified in the lastupdate header was distributed. If the receiving index server did not receive that index object, it should request a total index object. If the CIP protocol supports it, the index server may request the specific index object that it missed.
标记索引对象格式支持信息服务器仅分发增量索引数据，而不是每次分发全部索引信息。这种称为增量索引的场景支持三种基本类型的操作：添加、删除和替换。如果在标记的索引对象中指定了incremental updatetype，则索引对象仅包含自lastupdate标头中指定的索引对象分发以来所做更改的快照。如果接收索引服务器未接收到该索引对象，则应请求一个总索引对象。如果CIP协议支持，索引服务器可能会请求它丢失的特定索引对象。
If the tagged index object contains an Add Block, then the lines in the Add Block refer to new records that were added to the information base of the transmitting index server. It can be guaranteed that those records did not exist in any previously received tagged index object, and the receiving index server can insert this index information in the index that it already maintains for the transmitting index server.
如果标记的索引对象包含添加块，则添加块中的行表示添加到传输索引服务器信息库中的新记录。可以保证这些记录不存在于以前接收到的任何带标记的索引对象中，并且接收索引服务器可以将该索引信息插入它已经为发送索引服务器维护的索引中。
If the tagged index object contains a Delete Block, then the structure of the Delete Block depends on how the consistency is maintained;
如果标记的索引对象包含删除块，则删除块的结构取决于如何保持一致性；
- "completeRecord": all the tokens connected to the record to be deleted has to be included, the tag used to connect tokens in this message has no relation to tags used in previously sent tagged index objects.
- “completeRecord”：必须包括连接到要删除的记录的所有标记，用于连接此消息中标记的标记与以前发送的标记索引对象中使用的标记无关。
- "uniqueIDBased": only the unique identifier has to be defined.
- “uniqueIDBased”：只需定义唯一标识符。
- "tagBased": all the tokens connected to the record has to be included but then preceded by the tag used for this specific record in the preceding set of the last full update and the there on following incremental updates.
- “tagBased”：必须包括连接到记录的所有标记，但在上一次完整更新的前一组中，该标记之前必须有用于该特定记录的标记，并在随后的增量更新中使用该标记。
If the tagged index object contains an Update Block, then the lines in the Update Block refer to records that were changed in the information base of the transmitting index server. Again the specific content of the block depends on how the consistency is maintained.
如果标记的索引对象包含更新块，则更新块中的行引用传输索引服务器信息库中更改的记录。同样，块的具体内容取决于如何保持一致性。
- "completeRecord": All the tokens representing the old version of the record as well as the new ones has to be included.
- “completeRecord”：必须包括代表旧版本记录和新版本记录的所有标记。
- "uniqueIDBased": The unique ID has to be included together with the tokens that have changed.
- “uniqueIDBased”：唯一ID必须与已更改的令牌一起包含。
- "tagBased": Only the changed tokens are included, but then both the old version, if there was one, as well as the new one, if there is one.
- “tagBased”：只包括更改的令牌，但旧版本（如果有）和新版本（如果有）都包括在内。
The Update Block also supports the idea of indexing new attributes that were not previously included in the tagged index object. For example, if the transmitting index server began including index information on postal addresses, then it could include an Update Block in the index object that included all the index information on postal addresses for all records in its information base, and indicate that nothing else has changed.
更新块还支持为以前未包含在标记索引对象中的新属性编制索引的想法。例如，如果发送索引服务器开始包含邮政地址的索引信息，那么它可以在索引对象中包含一个更新块，该更新块包含其信息库中所有记录的邮政地址的所有索引信息，并指示没有其他更改。
In the following sections, for each different consistencybase type, the tagged index object is represented for the following scenario; The examples starts with one full update and following that a set of updates. The underlying information is presented in the LDIF [6] format.
在以下各节中，对于每个不同的consistencybase类型，将针对以下场景表示标记的索引对象；示例从一个完整更新开始，然后是一组更新。基本信息以LDIF[6]格式呈现。
dn: cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Barbara Jensen
cn: Barbara J Jensen
cn: Babs Jensen
sn: Jensen
uid: bjensen
dn: cn=Bjorn Jensen, ou=Accounting, o=Ace Industry, c=US
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Bjorn Jensen
sn: Jensen
title: Accounting manager
dn: cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Gern Jensen
cn: Gern O Jensen
sn: Jensen
title: testpilot
dn: cn=Horatio Jensen, ou=Product Testing, o=Ace Industry, c=US
objectclass: top
dn: cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Barbara Jensen
cn: Barbara J Jensen
cn: Babs Jensen
sn: Jensen
uid: bjensen
dn: cn=Bjorn Jensen, ou=Accounting, o=Ace Industry, c=US
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Bjorn Jensen
sn: Jensen
title: Accounting manager
dn: cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Gern Jensen
cn: Gern O Jensen
sn: Jensen
title: testpilot
dn: cn=Horatio Jensen, ou=Product Testing, o=Ace Industry, c=US
objectclass: top
objectclass: person objectclass: organizationalPerson cn: Horatio Jensen cn: Horatio N Jensen sn: Jensen title: testpilot
objectclass:person objectclass:OrganizationPerson cn:Horatio Jensen cn:Horatio N Jensen序列号：Jensen标题：testpilot
version: x-tagged-index-1 updatetype: total thisupdate: 855938804 BEGIN IO-Schema cn: TOKEN sn: FULL title: TOKEN END IO-Schema BEGIN Index-Info cn: 1/Barbara -1/J -1/Babs -*/Jensen -2/Bjorn -3/Gern -3/O -4/Horatio -4/N sn: */Jensen title: 1/product -1-2/manager -1/accounting -3,4/testpilot END Index-Info
版本：x-tagged-index-1更新类型：total thisupdate:855938804 BEGIN IO Schema cn:TOKEN sn:FULL title:TOKEN END IO Schema BEGIN index Info cn:1/Barbara-1/J-1/Babs-*/Jensen-2/Bjorn-3/Gern-3/O-4/Horatio-4/N sn://Jensen title:1/product-1-2/manager-1/accounting-3,4/testpilot END index-index Info
version: x-tagged-index-1 updatetype: total thisupdate: 855938804 BEGIN IO-Schema cn: TOKEN sn: FULL title: TOKEN END IO-Schema BEGIN Index-Info cn: 1/Barbara -1/J -1/Babs
版本：x-tagged-index-1 updatetype:总计此更新：855938804 BEGIN IO架构cn:TOKEN sn:全称：TOKEN END IO架构BEGIN索引信息cn:1/Barbara-1/J-1/Babs
-*/Jensen
-2/Bjorn
-3/Gern
-3/O
-4/Horatio
-4/N
sn: */Jensen
-*/Jensen
-2/Bjorn
-3/Gern
-3/O
-4/Horatio
-4/N
sn: */Jensen
title: 1/product -1-2/manager -1/accounting -3,4/testpilot END Index-Info
标题：1/产品-1-2/经理-1/会计-3,4/测试试点末端索引信息
version: x-tagged-index-1
updatetype: total
thisupdate: 855938804
BEGIN IO-Schema
dn: FULL
cn: TOKEN
sn: FULL
title: TOKEN
END IO-Schema
BEGIN Index-Info
dn: 1/cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US
-2/cn=Bjorn Jensen, ou=Accounting, o=Ace Industry, c=US
-3/cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US
-4/cn=Horatio Jensen, ou=Product Testing, o=Ace Industry, c=US
cn: 1/Barbara
-1/J
-1/Babs
-*/Jensen
-2/Bjorn
-3/Gern
-3/O
-4/Horatio
-4/N
sn: */Jensen
title: 1/product
-1-2/manager
-1/accounting
-3,4/testpilot
END Index-Info
version: x-tagged-index-1
updatetype: total
thisupdate: 855938804
BEGIN IO-Schema
dn: FULL
cn: TOKEN
sn: FULL
title: TOKEN
END IO-Schema
BEGIN Index-Info
dn: 1/cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US
-2/cn=Bjorn Jensen, ou=Accounting, o=Ace Industry, c=US
-3/cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US
-4/cn=Horatio Jensen, ou=Product Testing, o=Ace Industry, c=US
cn: 1/Barbara
-1/J
-1/Babs
-*/Jensen
-2/Bjorn
-3/Gern
-3/O
-4/Horatio
-4/N
sn: */Jensen
title: 1/product
-1-2/manager
-1/accounting
-3,4/testpilot
END Index-Info
Gern Jensen's entry above changes to:
Gern Jensen的上述条目更改为：
dn: cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Gern Jensen
cn: Gern O Jensen
sn: Jensen
title: chiefpilot
dn: cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Gern Jensen
cn: Gern O Jensen
sn: Jensen
title: chiefpilot
version: x-tagged-index-1
updatetype: incremental
lastupdate: 855940000
thisupdate: 855938804
BEGIN IO-schema
cn: TOKEN
sn: FULL
title: FULL
END IO-Schema
BEGIN Update Block
BEGIN Old
cn: 1/Gern
cn: 1/O
cn: 1/Jensen
sn: 1/Jensen
title: 1/testpilot
END Old
BEGIN New
cn: 1/Gern
cn: 1/O
cn: 1/Jensen
sn: 1/Jensen
title: 1/chiefpilot
END New
END Update Block
version: x-tagged-index-1
updatetype: incremental
lastupdate: 855940000
thisupdate: 855938804
BEGIN IO-schema
cn: TOKEN
sn: FULL
title: FULL
END IO-Schema
BEGIN Update Block
BEGIN Old
cn: 1/Gern
cn: 1/O
cn: 1/Jensen
sn: 1/Jensen
title: 1/testpilot
END Old
BEGIN New
cn: 1/Gern
cn: 1/O
cn: 1/Jensen
sn: 1/Jensen
title: 1/chiefpilot
END New
END Update Block
version: x-tagged-index-1 updatetype: incremental lastupdate: 855940000 thisupdate: 855938804 BEGIN IO-schema cn: TOKEN sn: FULL title: FULL END IO-Schema BEGIN Update Block BEGIN Old title: 3/testpilot END Old BEGIN New title: 3/chiefpilot END New END Update Block
版本：x-tagged-index-1 updatetype:增量上次更新：855940000此更新：855938804开始IO架构cn:令牌序列号：完整标题：完整结束IO架构开始更新块开始旧标题：3/testpilot结束旧开始新标题：3/chiefpilot结束新结束更新块
version: x-tagged-index-1
updatetype: incremental
lastupdate: 855940000
thisupdate: 855938804
BEGIN IO-schema
cn: TOKEN
sn: FULL
title: FULL
END IO-Schema
BEGIN Update Block
BEGIN Old
dn: 1/cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US
title: 1/testpilot
END Old
BEGIN New
dn: 1/cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US
title: 1/chiefpilot
END New
END Update Block
version: x-tagged-index-1
updatetype: incremental
lastupdate: 855940000
thisupdate: 855938804
BEGIN IO-schema
cn: TOKEN
sn: FULL
title: FULL
END IO-Schema
BEGIN Update Block
BEGIN Old
dn: 1/cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US
title: 1/testpilot
END Old
BEGIN New
dn: 1/cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US
title: 1/chiefpilot
END New
END Update Block
# Add a new entry
dn: cn=Bo Didley, ou=Marketing, o=Ace Industry, c=US
changetype: add
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Bo Didley
sn: Didley
title: Policy Maker
# Delete an existing entry
dn: cn=Bjorn Jensen, ou=Accounting, o=Ace Industry, c=US
changetype: delete
# Modify all other entries: adding an additional locality value
dn: cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US
changetype: modify
add: locality
locality: New Jersey
dn: cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US
changetype: modify
add: locality
locality: New Orleans
dn: cn=Horatio Jensen, ou=Product Testing, o=Ace Industry, c=US
changetype: modify
add: locality
locality: New Caledonia
# Add a new entry
dn: cn=Bo Didley, ou=Marketing, o=Ace Industry, c=US
changetype: add
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Bo Didley
sn: Didley
title: Policy Maker
# Delete an existing entry
dn: cn=Bjorn Jensen, ou=Accounting, o=Ace Industry, c=US
changetype: delete
# Modify all other entries: adding an additional locality value
dn: cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US
changetype: modify
add: locality
locality: New Jersey
dn: cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US
changetype: modify
add: locality
locality: New Orleans
dn: cn=Horatio Jensen, ou=Product Testing, o=Ace Industry, c=US
changetype: modify
add: locality
locality: New Caledonia
version: x-tagged-index-1 updatetype: incremental lastupdate: 855938804 thisupdate: 855939525 BEGIN IO-schema cn: TOKEN sn: FULL title: FULL locality: TOKEN END IO-Schema BEGIN Add Block cn: 1/Bo -1/Didley sn: 1/Didley title: 1/Policy -1/maker locality: 1/New -1/York
版本：x-tagged-index-1 updatetype:incremental lastupdate:855938804此更新：855939525开始IO模式cn:TOKEN序列号：完整标题：完整位置：TOKEN结束IO模式开始添加块cn:1/Bo-1/Didley序列号：1/Policy-1/maker位置：1/New-1/York
END Add Block BEGIN Delete Block cn: 1/Bjorn -1/Jensen sn: 1/Jensen title: 1/Accounting -1/Manager END Delete Block BEGIN Update Block BEGIN Old cn: 1/Barbara -1/J -1-3/Jensen -2/Gern -2/O -3/Horatio sn: 1-3/Jensen title: 1/Production -1/Manager -2/Testpilot -3/Chiefpilot END Old BEGIN New cn: 1/Barbara -1/J -1-3/Jensen -2/Gern -2/O -3/Horatio
结束添加块开始删除块cn:1/Bjorn-1/Jensen序号：1/Jensen title:1/Accounting-1/Manager结束删除块开始更新块开始旧cn:1/Barbara-1/J-1-3/Jensen-2/Gern-2/O-3/Horatio序号：1-3/Jensen title:1/Production-1/Manager-2/Testpilot-3/Chiefpilot结束旧的开始新cn:1/Barbara-1/J-1-3/Jensen-2/Gern-2/O-3/Horatio
sn: 1-3/Jensen
title: 1/Production
-1/Manager
-2/Testpilot
-3/Chiefpilot
locality: 1/Jersey
-2/Orleans
-3/Caledonia
-1-3/New
END New END Update Block
sn: 1-3/Jensen
title: 1/Production
-1/Manager
-2/Testpilot
-3/Chiefpilot
locality: 1/Jersey
-2/Orleans
-3/Caledonia
-1-3/New
END New END Update Block
version: x-tagged-index-1 updatetype: incremental lastupdate: 855938804 thisupdate: 855939525 BEGIN IO-schema
版本：x-tagged-index-1 updatetype:增量上次更新：855938804此更新：855939525开始IO模式
cn: TOKEN sn: FULL title: FULL locality: TOKEN END IO-Schema BEGIN Add Block cn: 5/Bo -5/Didley sn: 5/Didley title: 5/Policy -5/maker locality: 5/New -5/York END Add Block BEGIN Delete Block cn: 2/Bjorn -2/Jensen sn: 2/Jensen title: 2/Accounting -2/Manager END Delete Block BEGIN Update Block BEGIN New locality: 1/Jersey -2/Orleans -4/Caledonia -1,2,4/New END New END Update Block
cn:TOKEN序列号：全称：全称：全称：TOKEN-END IO模式开始添加块cn:5/Bo-5/Didley序列号：5/Policy-5/maker-Location:5/New-5/York-END添加块开始删除块cn:2/Bjorn-2/Jensen序列号：2/Jensen标题：2/Accounting-2/Manager-END删除块开始更新块开始新位置：1/Jersey-2/Orleans-4/Caledonia-1,2,4/新端新端更新块
version: x-tagged-index-1
updatetype: incremental
lastupdate: 855938804
thisupdate: 855939525
BEGIN IO-schema
cn: TOKEN
sn: FULL
title: FULL
locality: TOKEN
END IO-Schema
BEGIN Add Block
dn: 1/cn=Bo Didley, ou=Marketing, o=Ace Industry, c=US
cn: 1/Bo
-1/Didley
sn: 1/Didley
title: 1/Policy
version: x-tagged-index-1
updatetype: incremental
lastupdate: 855938804
thisupdate: 855939525
BEGIN IO-schema
cn: TOKEN
sn: FULL
title: FULL
locality: TOKEN
END IO-Schema
BEGIN Add Block
dn: 1/cn=Bo Didley, ou=Marketing, o=Ace Industry, c=US
cn: 1/Bo
-1/Didley
sn: 1/Didley
title: 1/Policy
-1/maker
locality: 1/New
-1/York
END Add Block
BEGIN Delete Block
dn: 1/cn=Bjorn Jensen, ou=Accounting, o=Ace Industry, c=US
END Delete Block
BEGIN Update Block
BEGIN New
dn: 1/cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US
-2/cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US
-3/cn=Horatio Jensen, ou=Product Testing, o=Ace Industry, c=US
locality: 1/Jersey
-2/Orleans
-3/Caledonia
-1-3/New
END New
END Update Block
-1/maker
locality: 1/New
-1/York
END Add Block
BEGIN Delete Block
dn: 1/cn=Bjorn Jensen, ou=Accounting, o=Ace Industry, c=US
END Delete Block
BEGIN Update Block
BEGIN New
dn: 1/cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US
-2/cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US
-3/cn=Horatio Jensen, ou=Product Testing, o=Ace Industry, c=US
locality: 1/Jersey
-2/Orleans
-3/Caledonia
-1-3/New
END New
END Update Block
Aggregation of two tagged index objects is done by merging the two lists of values and rewriting each tag list. The tag list rewriting process is done so that the resulting index object appears as if it came from a single source. An index server that aggregates tagged index objects for export MUST ensure that the export URL (i.e. the base-uri of the CIP object) for the aggregate index object will route all queries that have "hits" on the index object to that server (otherwise, query routing will not succeed).
通过合并两个值列表并重写每个标记列表，可以聚合两个标记索引对象。标记列表重写过程完成后，生成的索引对象看起来就像来自单个源一样。聚合标记索引对象以进行导出的索引服务器必须确保聚合索引对象的导出URL（即CIP对象的基本uri）将所有对索引对象有“点击”的查询路由到该服务器（否则，查询路由将不会成功）。
This specification provides a protocol for transferring information between two servers. The information transferred may be protected by laws in many countries, so care must be taken in the methods used to tokenize the data to ensure that protected data may not be reconstructed in full by the receiving server. This protocol does not have any inherent protection against spoofing or eavesdropping. However, since this protocol is transported in MIME messages (as are all CIP index objects), it inherits all the security capabilities and liabilities of other MIME messages. Specifically, those wanting to prevent eavesdropping or spoofing may use some of the various techniques for signing and encrypting MIME messages.
本规范提供了在两台服务器之间传输信息的协议。传输的信息可能受到许多国家的法律保护，因此必须注意用于标记数据的方法，以确保接收服务器不会完全重建受保护的数据。此协议没有任何针对欺骗或窃听的固有保护。但是，由于该协议是在MIME消息中传输的（与所有CIP索引对象一样），因此它继承了其他MIME消息的所有安全功能和责任。具体来说，那些想要防止窃听或欺骗的人可能会使用一些不同的技术对MIME消息进行签名和加密。
Information Server administrators must decide what portions of their databases are appropriate for inclusion in the Tagged Index Object.
信息服务器管理员必须决定其数据库的哪些部分适合包含在标记的索引对象中。
For distribution of information outside the enterprise, information server developers are encouraged to allow for facilities that hide the organizational structure when generating the Tagged Index Object from the underlying information database. To allow for the secure transmission of Tagged Index Objects across the Internet, Index Servers should make use of SSL when completing the connection. In order to strongly verify the identity of the peer index server on the other side of the connection, SSL version 3 certificate exchange should be implemented, and the identity in the peer's certificate verify with the Public Key Infrastructure. If electronic mail is used to exchange the Tagged Index Objects, then a secure messaging facility, such as PGP/MIME or S/MIME should be used to sign or encrypt (or both) the information.
对于企业外部的信息分发，鼓励信息服务器开发人员在从基础信息数据库生成标记的索引对象时，允许使用隐藏组织结构的工具。为了允许在Internet上安全传输标记的索引对象，索引服务器在完成连接时应使用SSL。为了强烈验证连接另一端的对等索引服务器的身份，应该实现SSL版本3证书交换，并且对等证书中的身份通过公钥基础结构进行验证。如果使用电子邮件交换标记的索引对象，则应使用安全消息传递工具（如PGP/MIME或S/MIME）对信息进行签名或加密（或两者兼而有之）。
[1] Allen, J. and M. Mealling, "The Architecture of the Common Indexing Protocol (CIP)," RFC 2651, August 1999.
[1] Allen，J.和M.Melling，“公共索引协议（CIP）的架构”，RFC 26511999年8月。
[2] Weider, C., Fullton, J. and S. Spero, "Architecture of the Whois++ Index Service", RFC 1913, February 1996.
[2] Weider，C.，Fullton，J.和S.Spero，“Whois++索引服务的体系结构”，RFC1913，1996年2月。
[3] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[3] Wahl，M.，Howes，T.和S.Kille，“轻量级目录访问协议（v3）”，RFC 2251，1997年12月。
[4] ITU, "X.525 Information Technology - Open Systems Interconnection - The Directory: Replication", November 1993.
[4] 国际电联，“X.525信息技术——开放系统互连——目录：复制”，1993年11月。
[5] "FORTEZZA Application Implementors Guide for the FORTEZZA Crypto Card (Production Version)", Document #PD4002102-1.01, SPYRUS, 1995.
[5] “FORTEZZA加密卡的FORTEZZA应用程序实现者指南（生产版）”，文件#PD4002102-1.01，SPYRUS，1995年。
[6] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical Specification", Work in Progress.
[6] 好，G.，“LDAP数据交换格式（LDIF）-技术规范”，正在进行中。
[7] Hedberg, R., "LDAPv2 Client vs. the Index Mesh", RFC 2657, August 1999.
[7] Hedberg，R.，“LDAPv2客户端与索引网格”，RFC 2657，1999年8月。
[8] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, December 1997.
[8] Howes，T.和M.Smith，“LDAP URL格式”，RFC 2255，1997年12月。
[9] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996.
[9] Elkins，M.，“具有良好隐私的MIME安全性（PGP）”，RFC 2015，1996年10月。
[10] Ramsdell, B., Editor, "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[10] Ramsdell，B.，编辑，“S/MIME版本3消息规范”，RFC 2633，1999年6月。
[11] Allen, C. and T. Dierks, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[11] Allen，C.和T.Dierks，“TLS协议1.0版”，RFC 2246，1999年1月。
Roland Hedberg Catalogix Dalsveien 53 0387 Oslo Norway
挪威奥斯陆罗兰·赫德伯格目录Dalsveien 53 0387
EMail: roland@catalogix.ac.se
EMail: roland@catalogix.ac.se
Bruce Greenblatt Directory Tools and Application Services, Inc. 6841 Heaton Moor Drive San Jose, CA 95119 USA
Bruce Greenblatt目录工具和应用程序服务公司，美国加利福尼亚州圣何塞市希顿摩尔大道6841号，邮编95119
Phone: +1-408-224-5349
EMail: bgreenblatt@directory-applications.com
Phone: +1-408-224-5349
EMail: bgreenblatt@directory-applications.com
Ryan Moats AT&T 15621 Drexel Circle Omaha, NE 68135-2358 USA
瑞安护城河AT&T 15621美国东北部奥马哈德雷克塞尔环路68135-2358
Phone: +1 402 894-9456
EMail: jayhawk@att.com
Phone: +1 402 894-9456
EMail: jayhawk@att.com
Mark Wahl Innosoft International, Inc. 8911 Capital of Texas Hwy, Suite 4140 Austin, TX 78759 USA
Mark Wahl Innosoft International，Inc.位于美国德克萨斯州奥斯汀市德克萨斯州高速公路首府8911号4140室，邮编：78759
Phone +1 626 919 3600 EMail Mark.Wahl@innosoft.com
电话+1 626 919 3600电子邮件标记。Wahl@innosoft.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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 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 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编辑功能的资金目前由互联网协会提供。