As per Relevance of the word exchange, we have this rfc below:
Network Working Group R.
Request for Comments: 2654
Category: Experimental B.
Directory Tools and Application Services, Inc
R.
AT&
M.
Innosoft International, Inc
August 1999
A Tagged Index Object for use in the Common Indexing
Status of this
This memo defines an Experimental Protocol for the
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
Copyright (C) The Internet Society (1999). All Rights Reserved
This document defines a mechanism by which information servers
exchange indices of information from their databases by making use
the Common Indexing Protocol (CIP). This document defines
structure of the index information being exchanged, as well as
appropriate meanings for the headers that are defined in the
Indexing Protocol. It is assumed that the structures defined
can be used by X.500 DSAs, LDAP servers, Whois++ servers, CSO
servers and many others
Table of
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
Hedberg, et al. Experimental [Page 1]
RFC 2654 Tagged Index Object for use in CIP August 1999
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
1.
The Common Indexing Protocol (CIP) as defined in [1] proposes
mechanism for distributing searches across several instances of
single type of search engine to create a global directory.
provides a scalable, flexible scheme to tie individual databases
distributed data warehouses that can scale gracefully with the
of the Internet. CIP provides a mechanism for meeting these
that is independent of the access method that is used to access
data that underlies the indices. Separate from CIP is the
of the Index Object that is used to contain the information that
exchanged among Index Servers. One such Index Object that
already been defined is the Centroid that is derived from the Whois++
protocol [2].
The Centroid does not meet all the requirements for the exchange
index information amongst information servers. For example, it
not support the notion of incremental updates natively.
information servers that contain millions of records in
database, constant exchange of complete dredges of the database
bandwidth intensive. The Tagged Index Object is
designed to support the exchange of index update information.
design comes at the cost of an increase in the size of the
object being exchanged. The Centroid is also not tailored to
be able to give boolean answers to queries. In the Centroid Model
"an index server will take a query in standard Whois++ format,
its collections of centroids and other forward information,
which servers hold records which may fill that query, and
Hedberg, et al. Experimental [Page 2]
RFC 2654 Tagged Index Object for use in CIP August 1999
notifies the user's client of the next servers to contact to
the query." [2] Thus, the exchange of Centroids amongst index
allows hints to be given about which information server
contains the information. The Tagged Index Object labels the
pieces of information with identifiers that tie the individual
attributes back to an object as a whole. This "tagging"
information allows an index server to be more capable of directing
specific query to the appropriate information server. Again,
feature is added to the Tagged Index Object at the expense of
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
arranged hierarchically in such a way as to provide a
distributed database which is normally called the
Information Tree (DIT). Some distinguishing characteristics of
servers are that normally, several servers cooperate to manage
common subtree of the DIT. LDAP servers are expected to respond
requests that pertain to portions of the DIT for which they
data, as well as for those portions for which they have
information in their database. For example, the LDAP server for
portion of the DIT in the United States (c=US) must be able
provide a response to a Search operation that pertains to a
of the DIT in Sweden (c=se). Normally, the response given will be
referral to another LDAP server that is expected to be
knowledgeable about the appropriate subtree. However, there is
mechanism that currently enables these LDAP servers to refer the
client to the supposedly more knowledgeable server. Typically,
LDAP (v3) server is configured with the name of exactly one
LDAP server to which all LDAP clients are referred when
requests fall outside the subtree of the DIT for which that
server has knowledge. This specification defines a mechanism
LDAP server can exchange index information that will allow
to point towards a clearly accurate destination
The X.500 series of recommendations defines the Directory
Shadowing Protocol (DISP) [4] which allows X.500 DSAs to
information in the DIT. Shadowing allows various information
various portions of the DIT to be replicated amongst
DSAs. The design point of DISP is improved at the exchange of
portions of the DIT, whereas the design point of CIP and the
Index Object is optimized at the exchange of structural
information about the DIT, and improving the performance of
navigation amongst various information servers. The Tagged
Object is more appropriate for the exchange of index information
is DISP. DISP is more targeted at DIT distribution and
Hedberg, et al. Experimental [Page 3]
RFC 2654 Tagged Index Object for use in CIP August 1999
tolerance. DISP is thus more appropriate for the exchange of
data in order to spread the load amongst several information servers
DISP is tailored specifically to X.500 (and other
directory systems), while the Tagged Index Object and CIP can be
in a wide variety of information server environments
While DISP allows an individual directory server to
information about large parts of the DIT, it would require a
database to collect all the replicas for a significant portion of
DIT. Furthermore, as X.525 states: "Before shadowing can occur,
agreement, covering the conditions under which shadowing may occur
required. Although such agreements may be established in a
of ways, such as policy statements covering all DSAs within a
DMD ...", where a DMD is a Directory Management Domain. This
owing to the case that the data in the DIT is being exchanged
DSA rather than only the information required to maintain an Index
In many environments such an agreement is not appropriate, and
collect information for a meaningful portion of the DIT,
agreements may need to be arranged
3.
What is desired is to have an information server (or network
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
directory tree to find out this one piece of information.
also don't want to have to shadow the entire
directory subtree onto my server. If this request is being
because Fred is trying to log into my server, I'd certainly
to be able to respond to the BIND in real time
- Who are all the people at Novell that have a title
programmer
all these requests can reasonably be translated into LDAP or Whois++,
and other directory access protocol queries. They can also
serviced in a straightforward way by the users home
server if it has the appropriate reference information into
database that contains the source data. Here, the first server
be able to "chain" the request for the user. Alternatively,
precise referral could be returned. If the home information
wants to service (i.e chain) the request based on the
Hedberg, et al. Experimental [Page 4]
RFC 2654 Tagged Index Object for use in CIP August 1999
information that it has on hand, this servicing could be done
different means
- issuing LDAP operations to the remote directory
- issuing DSP operations to the remote directory
- issuing DAP operations to the remote directory
- issuing Whois++ operations to the remote Whois++
- ...
4. The Tagged Index
This section defines a Tagged Index Object that can be exchanged
Information Servers using CIP. While often it is acceptable
Information Servers to make use of the Centroid definition (from [2])
to exchange index information, the goals in defining a new
are multi-pronged
- When the Information Server receives a search request
warrants that a referral be returned, allow the server to
a referral that will point client to a server that is
likely able to answer the request correctly. False
referrals (the search turns up hits in the index object
generate referrals to servers that don't hold the
information) can be reduced, depending on the choice
attribute tokenization types that are used
- Potentially allow incremental updates that will then
substantially less bandwidth then if full updates always had
be used
4.1. The
Before a Tagged Index Object can be exchanged, the organization
administers the object supplier and the organization that
the object consumer must reach an agreement on how the servers
communicate. This agreement contains the following
- "index-type": This specification describes the index type "x
tagged-index-1"
- "dsi": An OID that uniquely identifies the subtree and scope
This field is not explicitly necessary, as it may not
information beyond what is contained in the "base-uri" below
Hedberg, et al. Experimental [Page 5]
RFC 2654 Tagged Index Object for use in CIP August 1999
- "base-uri": One or more URI's that will form the base of
referrals created based on the index object that is governed
this agreement. For example, in the LDAP URL format [8]
base-uri would specify (among other items): the LDAP host,
base object to which this index object refers (e.g. c=SE),
the scope of the index object (e.g. single container).
- "supplier": The hostname and listening portnumber of
supplier server, as well as any alternative servers holding
same naming contexts, if the supplier is unavailable
- "consumeraddr": This is a URI of the "mailto:" form, with
RFC 822 email address of the consumer server. Further
of this draft allow other forms of URI, so that the consumer
retrieve the update via the WWW, FTP or CIP
- "updateinterval": The maximum duration in seconds
occurances of the supplier server generating an update. If
consumer server has not received an update from the
server after waiting this long since the previous update, it
likely that the index information is now out of date. A
value for a server with frequent updates would be 604800
seconds, or every week. Servers whose DITs are only
annually could have a much longer update interval
- "attributeNamespace": Every set of index servers that
wants to support a specific usage of indeces, has to agree
which attributenames to use in the index objects.
participating directory servers also has to agree on the
from local attributenames to the attributenames used in
index. Since one specific index server might be involved
several such sets, it has to have some way to connect a
to the proper set of indexes. One possible solution to
would be to use different DSIs
- "consistencybase": How consistency of the index is
over incremental updates
"complete" - every change or delete concerning one
has to contain all tokens connected to that object.
method must be supported by any server who wants to
with this standard
"tag" - starting at a full update every incremental
refering back to this full updated has to maintain state
information regarding tags, such that a object within
original database is assigned the same tagnumber every time
This method is optional
Hedberg, et al. Experimental [Page 6]
RFC 2654 Tagged Index Object for use in CIP August 1999
"unique" - every object in the Dataset has to have a
value for a specific attribute in the index. A example
such a attribute could be the distinguishedName attribute
This method is also optional
- "securityoption": Whether and how the supplier server
sign and encrypt the update before sending it to the
server. Options for this version of the specification are
"none" - the update is sent in
"PGP/MIME": the update is digitally signed and
using PGP [9]
"S/MIME": the update is digitally signed and encrypted
S/MIME [10]
"SSLv3": the update is digitally signed and encrypted
an SSLv3 connection [11]
"Fortezza": the update is digitally signed and
using Fortezza [5]
It is recommended that the "PGP/MIME" option be used when
sensitive information across public networks, and both the
and consumer have PGP keys. The "Fortezza" option is intended for
in environments where security protocols are based on Fortezza
compatible devices. The "S/MIME" option can be used with both
supplier and consumer have RSA keys and can make use of the
protocols defined in the S/MIME specification. The "SSLv3" option
be used when both the supplier and consumer have access to
services, have server certificates, and can mutually
each other
- Security Credentials: The long-term cryptographic
used for key exchange and authentication of the consumer
supplier servers, if a security option was selected.
"PGP/MIME," this will be the trusted public keys of
servers. For "Fortezza," this will be the certificate paths
both servers to a common point of trust. For "S/MIME"
"SSLv3" these will be the certificates of the supplier
consumer
Hedberg, et al. Experimental [Page 7]
RFC 2654 Tagged Index Object for use in CIP August 1999
Note that if the index server maintains the information
would appear in the agreement in a directory according to
definitions in [7], then no real formal agreement between
two parties needs to be put in place, and the information
is required for communication between the two index servers
derived automatically from the directory
4.2. Content
The update consists of a MIME object of type application/cip-index
object. The parameters are
"type": this has value "application/index.obj.tagged".
"dsi": the DSI (if any) from the agreement
"base-uri". A set of URIs, separated by spaces. In each URI,
hostname/portno must be distinct, and based on the "supplier"
of the agreement
The payload is mostly textual data but may include bytes with
high bit set. The originating information server should set
content-transfer-encoding as appropriate for the information
in the payload
This object may be encapsulated in a wrapper content (such
multipart/signed) or be encrypted as part of the security procedures
The resulting content can the distributed, for example via
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
Reply-to: supplier-admin@sup.
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
handle the full range of Unicode characters when decoding
attribute values (in the "attr-value" field in the BNF below).
Hedberg, et al. Experimental [Page 8]
RFC 2654 Tagged Index Object for use in CIP August 1999
4.3. Tagged Index
The Tagged Index object has the following grammar, expressed
modified BNF format
index-object = 0*(io-part SEP) io-
io-part = header SEP schema-spec SEP index-
header = version-spec SEP update-type SEP this-update
last-update context-size name-space
version-spec = "version:" *SPACE "x-tagged-index-1"
update-type = "updatetype:" *SPACE ( "total" |
( "incremental" [*SPACE "tagbased"|"uniqueIDbased" ] )
this-update = "thisupdate:" *SPACE
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-
token-type = "FULL" | "TOKEN" | "RFC822" | "UUCP" | "DNS
index-info = full-index | incremental-
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"
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-
cont-line = "-" taglist "/" attr-
taglist = tag 0*("," tag) | "*"
tag = 1*DIGIT ["-" 1*DIGIT
attr-value = 1*(UTF8)
attr-name = 1*(NAMECHAR
TIMESTAMP = 1*
NAMECHAR = DIGIT | UPPER | LOWER | "-" | ";" | "."
SPACE = ;
SEP = (CR LF) |
CR = ;
LF = ;
Hedberg, et al. Experimental [Page 9]
RFC 2654 Tagged Index Object for use in CIP August 1999
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
US-ASCII-SAFE = %x01-09 / %x0B-0C / %x0E-7
;; US-ASCII except CR, LF,
UTF8 = US-ASCII-SAFE / UTF8-1 / UTF8-2 / UTF8-3
/ UTF8-4 / UTF8-5
UTF8-CONT = %x80-
UTF8-1 = %xC0-DF UTF8-
UTF8-2 = %xE0-EF 2UTF8-
UTF8-3 = %xF0-F7 3UTF8-
UTF8-4 = %xF8-FB 4UTF8-
UTF8-5 = %xFC-FD 5UTF8-
The set of characters allowed to appear in the attr-name field
limited to the set of characters used in LDAP and WHOIS++
names. For other services that have attribute name character
that are larger than these, those services should create a
that maps the names onto object identifiers, and the sequence
digits and periods is used by those services in creating the attr
name fields for their Tagged Index Objects
It is worth mentioning that updates to a index based in tagged
objects MUST be performed in the order specified by the tagged
object itself
4.3.1. Header
The header section consists of one or more "header lines".
following header lines are defined
"version": This line must always be present, and have the
"x-tagged-index-1" for this version of the specification
"updatetype": This line must always be present. It takes as
value either "total" or "incremental". The first update sent by
supplier server to a consumer server for a DSI must be a "total
update
Hedberg, et al. Experimental [Page 10]
RFC 2654 Tagged Index Object for use in CIP August 1999
"thisupdate": This line must always be present. The value is
number of seconds from 00:00:00 UTC January 1, 1970 at which
supplier constructed this update
"lastupdate": This line must be present if the "updatetype"
has the value "incremental". The value is the number of
from 00:00:00 UTC January 1, 1970 at which the
constructed the previous update sent to the consumer. This
allows the consumer to determine if a previous update was
"contextsize": This line may be present at the supplier's option
The value is a number, which is the approximate total number
entries in the subtree. This information is provided
statistical purposes only
4.3.2. Tokenization
The Tagged Index Object inherits the "TOKEN" scheme for
as specified in [2]. In addition, there are several
tokenization schemes defined for the Tagged Index Object
The following table presents these schemes and what character(s)
used to delimit tokens
Token Type Tokenization
FULL
TOKEN white space, "@"
RFC822 white space, ".", "@"
UUCP white space, "!"
DNS any character note a number, letter, or "-"
4.3.3. Tag
In the tag list, multiple consecutive tags may be shortened by
"#-#". For example, the list "3,4,5,6,7,8,9,10" may be shortened
"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
tag, then those two lines always refer to the same "record" in
directory. In LDAP terminology, the two lines would refer to
same directory object. Additionally if two index lines in the
index object contain different tags, then it is always the case
those two lines refer back to different records in the directory.
meaning of '*' in the tag position is that that specific token
in every record in the directory
The tag applied to the same underlying record in two
transmissions of a full-index may be different. Thus,
index servers should make no assumptions about the values of the
across index object boundaries
Hedberg, et al. Experimental [Page 11]
RFC 2654 Tagged Index Object for use in CIP August 1999
4.4. Incremental
The tagged index object format supports the ability of
servers to distribute only delta index data, rather than
total index information each time. This scenario, known
incremental indexing supports three basic types of operations: add
delete and replace. If the incremental updatetype is specified
the tagged index object, then the index object contains a snapshot
only the changes that have been made since the index object
in the lastupdate header was distributed. If the receiving
server did not receive that index object, it should request a
index object. If the CIP protocol supports it, the index server
request the specific index object that it missed
If the tagged index object contains an Add Block, then the lines
the Add Block refer to new records that were added to the
base of the transmitting index server. It can be guaranteed
those records did not exist in any previously received tagged
object, and the receiving index server can insert this
information in the index that it already maintains for
transmitting index server
If the tagged index object contains a Delete Block, then
structure of the Delete Block depends on how the consistency
maintained
- "completeRecord": all the tokens connected to the record to
deleted has to be included, the tag used to connect tokens in
message has no relation to tags used in previously sent
index objects
- "uniqueIDBased": only the unique identifier has to be defined
- "tagBased": all the tokens connected to the record has to
included but then preceded by the tag used for this
record in the preceding set of the last full update and the
on following incremental updates
If the tagged index object contains an Update Block, then the
in the Update Block refer to records that were changed in
information base of the transmitting index server. Again the
content of the block depends on how the consistency is maintained
- "completeRecord": All the tokens representing the old version
the record as well as the new ones has to be included
- "uniqueIDBased": The unique ID has to be included together
the tokens that have changed
Hedberg, et al. Experimental [Page 12]
RFC 2654 Tagged Index Object for use in CIP August 1999
- "tagBased": Only the changed tokens are included, but then
the old version, if there was one, as well as the new one,
there is one
The Update Block also supports the idea of indexing new
that were not previously included in the tagged index object.
example, if the transmitting index server began including
information on postal addresses, then it could include an
Block in the index object that included all the index information
postal addresses for all records in its information base,
indicate that nothing else has changed
5.
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
updates. The underlying information is presented in the LDIF [6]
format
5.1 The original
dn: cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=
objectclass:
objectclass:
objectclass:
cn: Barbara
cn: Barbara J
cn: Babs
sn:
uid:
dn: cn=Bjorn Jensen, ou=Accounting, o=Ace Industry, c=
objectclass:
objectclass:
objectclass:
cn: Bjorn
sn:
title: Accounting
dn: cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=
objectclass:
objectclass:
objectclass:
cn: Gern
cn: Gern O
sn:
title:
dn: cn=Horatio Jensen, ou=Product Testing, o=Ace Industry, c=
objectclass:
Hedberg, et al. Experimental [Page 13]
RFC 2654 Tagged Index Object for use in CIP August 1999
objectclass:
objectclass:
cn: Horatio
cn: Horatio N
sn:
title:
5.1.1 "Complete" consistency based full
version: x-tagged-index-1
updatetype:
thisupdate: 855938804
BEGIN IO-
cn:
sn:
title:
END IO-
BEGIN Index-
cn: 1/
-1/
-1/
-*/
-2/
-3/
-3/
-4/
-4/
sn: */
title: 1/
-1-2/
-1/
-3,4/
END Index-
5.1.2 "tag" consistency based full
version: x-tagged-index-1
updatetype:
thisupdate: 855938804
BEGIN IO-
cn:
sn:
title:
END IO-
BEGIN Index-
cn: 1/
-1/
-1/
Hedberg, et al. Experimental [Page 14]
RFC 2654 Tagged Index Object for use in CIP August 1999
-*/
-2/
-3/
-3/
-4/
-4/
sn: */
title: 1/
-1-2/
-1/
-3,4/
END Index-
5.1.3 "unique" consistency based full
version: x-tagged-index-1
updatetype:
thisupdate: 855938804
BEGIN IO-
dn:
cn:
sn:
title:
END IO-
BEGIN Index-
dn: 1/cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=
-2/cn=Bjorn Jensen, ou=Accounting, o=Ace Industry, c=
-3/cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=
-4/cn=Horatio Jensen, ou=Product Testing, o=Ace Industry, c=
cn: 1/
-1/
-1/
-*/
-2/
-3/
-3/
-4/
-4/
sn: */
title: 1/
-1-2/
-1/
-3,4/
END Index-
Hedberg, et al. Experimental [Page 15]
RFC 2654 Tagged Index Object for use in CIP August 1999
5.2 First
Gern Jensen's entry above changes to
dn: cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=
objectclass:
objectclass:
objectclass:
cn: Gern
cn: Gern O
sn:
title:
5.2.1 First update using "complete
version: x-tagged-index-1
updatetype:
lastupdate: 855940000
thisupdate: 855938804
BEGIN IO-
cn:
sn:
title:
END IO-
BEGIN Update
BEGIN
cn: 1/
cn: 1/
cn: 1/
sn: 1/
title: 1/
END
BEGIN
cn: 1/
cn: 1/
cn: 1/
sn: 1/
title: 1/
END
END Update
Hedberg, et al. Experimental [Page 16]
RFC 2654 Tagged Index Object for use in CIP August 1999
5.2.2 First update using "tag"
version: x-tagged-index-1
updatetype:
lastupdate: 855940000
thisupdate: 855938804
BEGIN IO-
cn:
sn:
title:
END IO-
BEGIN Update
BEGIN
title: 3/
END
BEGIN
title: 3/
END
END Update
5.2.3 First update using "unique" ID'
version: x-tagged-index-1
updatetype:
lastupdate: 855940000
thisupdate: 855938804
BEGIN IO-
cn:
sn:
title:
END IO-
BEGIN Update
BEGIN
dn: 1/cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=
title: 1/
END
BEGIN
dn: 1/cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=
title: 1/
END
END Update
Hedberg, et al. Experimental [Page 17]
RFC 2654 Tagged Index Object for use in CIP August 1999
5.3 Second
# Add a new
dn: cn=Bo Didley, ou=Marketing, o=Ace Industry, c=
changetype:
objectclass:
objectclass:
objectclass:
cn: Bo
sn:
title: Policy
# Delete an existing
dn: cn=Bjorn Jensen, ou=Accounting, o=Ace Industry, c=
changetype:
# Modify all other entries: adding an additional locality
dn: cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=
changetype:
add:
locality: New
dn: cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=
changetype:
add:
locality: New
dn: cn=Horatio Jensen, ou=Product Testing, o=Ace Industry, c=
changetype:
add:
locality: New
5.3.1 "complete
version: x-tagged-index-1
updatetype:
lastupdate: 855938804
thisupdate: 855939525
BEGIN IO-
cn:
sn:
title:
locality:
END IO-
BEGIN Add
cn: 1/
-1/
sn: 1/
title: 1/
-1/
locality: 1/
-1/
Hedberg, et al. Experimental [Page 18]
RFC 2654 Tagged Index Object for use in CIP August 1999
END Add
BEGIN Delete
cn: 1/
-1/
sn: 1/
title: 1/
-1/
END Delete
BEGIN Update
BEGIN
cn: 1/
-1/
-1-3/
-2/
-2/
-3/
sn: 1-3/
title: 1/
-1/
-2/
-3/
END
BEGIN
cn: 1/
-1/
-1-3/
-2/
-2/
-3/
sn: 1-3/
title: 1/
-1/
-2/
-3/
locality: 1/
-2/
-3/
-1-3/
END New END Update
5.3.2 "tag
version: x-tagged-index-1
updatetype:
lastupdate: 855938804
thisupdate: 855939525
BEGIN IO-
Hedberg, et al. Experimental [Page 19]
RFC 2654 Tagged Index Object for use in CIP August 1999
cn:
sn:
title:
locality:
END IO-
BEGIN Add
cn: 5/
-5/
sn: 5/
title: 5/
-5/
locality: 5/
-5/
END Add
BEGIN Delete
cn: 2/
-2/
sn: 2/
title: 2/
-2/
END Delete
BEGIN Update
BEGIN
locality: 1/
-2/
-4/
-1,2,4/
END
END Update
5.3.3 "unique
version: x-tagged-index-1
updatetype:
lastupdate: 855938804
thisupdate: 855939525
BEGIN IO-
cn:
sn:
title:
locality:
END IO-
BEGIN Add
dn: 1/cn=Bo Didley, ou=Marketing, o=Ace Industry, c=
cn: 1/
-1/
sn: 1/
title: 1/
Hedberg, et al. Experimental [Page 20]
RFC 2654 Tagged Index Object for use in CIP August 1999
-1/
locality: 1/
-1/
END Add
BEGIN Delete
dn: 1/cn=Bjorn Jensen, ou=Accounting, o=Ace Industry, c=
END Delete
BEGIN Update
BEGIN
dn: 1/cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=
-2/cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=
-3/cn=Horatio Jensen, ou=Product Testing, o=Ace Industry, c=
locality: 1/
-2/
-3/
-1-3/
END
END Update
6.
6.1. Aggregation of Tagged Index
Aggregation of two tagged index objects is done by merging the
lists of values and rewriting each tag list. The tag list
process is done so that the resulting index object appears as if
came from a single source. An index server that aggregates
index objects for export MUST ensure that the export URL (i.e.
base-uri of the CIP object) for the aggregate index object will
all queries that have "hits" on the index object to that
(otherwise, query routing will not succeed).
7. Security
This specification provides a protocol for transferring
between two servers. The information transferred may be protected
laws in many countries, so care must be taken in the methods used
tokenize the data to ensure that protected data may not
reconstructed in full by the receiving server. This protocol
not have any inherent protection against spoofing or eavesdropping
However, since this protocol is transported in MIME messages (as
all CIP index objects), it inherits all the security capabilities
liabilities of other MIME messages. Specifically, those wanting
prevent eavesdropping or spoofing may use some of the
techniques for signing and encrypting MIME messages
Information Server administrators must decide what portions of
databases are appropriate for inclusion in the Tagged Index Object
Hedberg, et al. Experimental [Page 21]
RFC 2654 Tagged Index Object for use in CIP August 1999
For distribution of information outside the enterprise,
server developers are encouraged to allow for facilities that
the organizational structure when generating the Tagged Index
from the underlying information database. To allow for the
transmission of Tagged Index Objects across the Internet,
Servers should make use of SSL when completing the connection.
order to strongly verify the identity of the peer index server on
other side of the connection, SSL version 3 certificate
should be implemented, and the identity in the peer's
verify with the Public Key Infrastructure. If electronic mail
used to exchange the Tagged Index Objects, then a secure
facility, such as PGP/MIME or S/MIME should be used to sign
encrypt (or both) the information
8.
[1] Allen, J. and M. Mealling, "The Architecture of the
Indexing Protocol (CIP)," RFC 2651, August 1999.
[2] Weider, C., Fullton, J. and S. Spero, "Architecture of
Whois++ Index Service", RFC 1913, February 1996.
[3] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
Protocol (v3)", RFC 2251, December 1997.
[4] ITU, "X.525 Information Technology - Open
Interconnection - The Directory: Replication", November 1993.
[5] "FORTEZZA Application Implementors Guide for the
Crypto Card (Production Version)", Document #PD4002102-1.01,
SPYRUS, 1995.
[6] Good, G., "The LDAP Data Interchange Format (LDIF) -
Specification", Work in Progress
[7] Hedberg, R., "LDAPv2 Client vs. the Index Mesh", RFC 2657,
August 1999.
[8] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
December 1997.
[9] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)",
2015, October 1996.
[10] Ramsdell, B., Editor, "S/MIME Version 3 Message Specification",
RFC 2633, June 1999.
Hedberg, et al. Experimental [Page 22]
RFC 2654 Tagged Index Object for use in CIP August 1999
[11] Allen, C. and T. Dierks, "The TLS Protocol Version 1.0",
2246, January 1999.
9. Authors'
Roland
Dalsveien 53
0387
EMail: roland@catalogix.ac.
Bruce
Directory Tools and Application Services, Inc
6841 Heaton Moor
San Jose, CA 95119
Phone: +1-408-224-5349
EMail: bgreenblatt@directory-applications.
Ryan
AT&
15621 Drexel
Omaha, NE 68135-2358
Phone: +1 402 894-9456
EMail: jayhawk@att.
Mark
Innosoft International, Inc
8911 Capital of Texas Hwy, Suite 4140
Austin, TX 78759
Phone +1 626 919 3600
EMail Mark.Wahl@innosoft.
Hedberg, et al. Experimental [Page 23]
RFC 2654 Tagged Index Object for use in CIP August 1999
10. Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Hedberg, et al. Experimental [Page 24]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
