7 Network Working Group R. Hedberg
8 Request for Comment: 2657 Catalogix
9 Category: Experimental August 1999
12 LDAPv2 Client vs. the Index Mesh
16 This memo defines an Experimental Protocol for the Internet
17 community. It does not specify an Internet standard of any kind.
18 Discussion and suggestions for improvement are requested.
19 Distribution of this memo is unlimited.
23 Copyright (C) The Internet Society (1999). All Rights Reserved.
27 LDAPv2 clients as implemented according to RFC 1777 [1] have no
28 notion on referral. The integration between such a client and an
29 Index Mesh, as defined by the Common Indexing Protocol [2], heavily
30 depends on referrals and therefore needs to be handled in a special
31 way. This document defines one possible way of doing this.
35 During the development of the Common Indexing Protocol (CIP), one of
36 the underlying assumptions was that the interaction between clients
37 and the Index Mesh Servers [1] would heavily depend on the passing of
38 referrals. Protocols like LDAPv2 [2] that lack this functionality
39 need to compensate for it by some means. The way chosen in this memo
40 is to add more intelligence into the client. There are two reasons
41 behind this decision. First, this is not a major enhancement that is
42 needed and secondly, that the intelligence when dealing with the
43 Index Mesh, with or the knowledge about referrals, eventually has to
46 2. The clients view of the Index Mesh
48 If a LDAPv2 client is going to be able to interact with the Index
49 Mesh, the Mesh has to appear as something that is understandable to
50 the client. Basically, this consists of representing the index
51 servers and their contained indexes in a defined directory
52 information tree (DIT) [3,4] structure and a set of object classes
53 and attribute types that have been proven to be useful in this
58 Hedberg Experimental [Page 1]
60 RFC 2657 LDAPv2 vs. Index Mesh August 1999
63 2.1 The CIP Object Classes
65 Object class descriptions are written according to the BNF defined in
70 The cIPIndex objectClass, if present in a entry, allows it to hold
71 one indexvalue and information connected to this value.
77 MUST ( extendedDSI $ idx )
83 The cIPDataSet objectClass, if present in a entry, allows it to hold
84 information concerning one DataSet.
90 MUST ( dSI $ searchBase )
91 MAY ( indexOCAT $ description $ indexType $
92 accessPoint $ protocolVersion $ polledBy $
93 updateIntervall $ securityOption $
94 supplierURI $ consumerURI $ baseURI $
95 attributeNamespace $ consistencyBase
99 2.2 The CIP attributeTypes
101 The attributes idx, indexOCAT, extendedDSI, description,
102 cIPIndexType, baseURI, dSI are used by a client accessing the index
103 server. The other attributes (accesspoint, protocolVersion,
104 polledBy, updateIntervall, consumerURI, supplierURI and
105 securityOption, attributeNamespace, consistencyBase) are all for
106 usage in server to server interactions.
114 Hedberg Experimental [Page 2]
116 RFC 2657 LDAPv2 vs. Index Mesh August 1999
121 The index value, normally used as part of the RDN.
125 EQUALITY caseIgnoreIA5Match
132 DataSet Identifier, a unique identifier for one particular set of
133 information. This should be an OID, but stored in a stringformat.
137 EQUALITY caseIgnoreIA5Match
143 Describes the type of data that is stored in this entry, by using
144 objectcClasses and attributeTypes. The information is stored as a
145 objectClass name followed by a space and then an attributeType name.
146 A typical example when dealing with whitepages information would be
151 EQUALITY caseIgnoreIA5Match
157 A URI describing which protocols, hostnames and ports should be used
158 by an indexserver to interact with servers carrying indexinformation
159 representing this dataSet.
163 EQUALITY caseIgnoreIA5Match
170 Hedberg Experimental [Page 3]
172 RFC 2657 LDAPv2 vs. Index Mesh August 1999
177 The attribute value for this attribute is a LDAP URI. One can
178 envisage other URI syntaxes, if the client knows about more access
179 protocols besides LDAP, and the interaction between the client and
180 the server can not use referrals for some reason.
184 EQUALITY caseExactIA5Match
188 2.2.7 protocolVersion
190 At present, the Common Indexing Protocol version should be 3.
193 NAME 'protocolVersion'
194 EQUALITY numericStringMatch
200 The type of index Object that is used to pass around index
205 EQUALITY caseIgnoreIA5Match
211 The Distinguished Name of Index servers that polls data from this
216 EQUALITY distinguishedNameMatch
226 Hedberg Experimental [Page 4]
228 RFC 2657 LDAPv2 vs. Index Mesh August 1999
231 2.2.11 updateIntervall
233 The maximum duration in seconds between the generation of two updates
234 by the supplier server.
237 Name 'updateIntervall'
238 EQUALITY numericStringMatch
243 2.2.12 securityOption
245 Whether and how the supplier server should sign and encrypt the
246 update before sending it to the consumer server.
249 NAME 'securityOption'
250 EQUALITY caseIgnoreIA5Match
257 DataSet Identifier possibly followed by a space and a taglist, the
258 later as specified by [6].
262 EQUALITY caseIgnoreIA5Match
268 A URI describing which means a server can accept indexinformation.
269 An example being a mailto URI for MIME email based index transport.
273 EQUALITY caseExactIA5Match
282 Hedberg Experimental [Page 5]
284 RFC 2657 LDAPv2 vs. Index Mesh August 1999
287 2.2.15 attributeNamespace
289 Any consumer supplier pair has to agree on what attribute that should
290 be used and also possibly the meaning of the attributenames. The
291 value of this attribute should, for example, be a URI pointing to a
292 document wherein the agreement is described.
294 ( 1.2.752.17.1.35 NAME 'attributeNamespace' EQUALITY
295 caseExactIA5Match SYNTAX IA5String
298 2.2.16 consistencyBase
300 This attribute is specifically used by consumer supplier pairs that
301 use the tagged index object [6].
304 NAME 'consistencyBase'
305 EQUALITY caseExactIA5Match
309 3. The interaction between a client and the Index Mesh
311 A client interaction with the Index Mesh consists of a couple of
312 rather well defined actions. The first being to find a suitable index
313 to start with, then to transverse the Index Mesh and finally to query
314 the servers holding the original data. Note when reading this text
315 that what is discussed here is the client's perception of the DIT,
316 how it is in fact implemented is not discussed.
318 3.1 Finding a Index Mesh
320 This approach depends on the fact that every index server partaking
321 in an Index Mesh is represented in the DIT by a entry of the type
322 cIPDataSet, and has a distinguished name (DN) which most significant
323 relative distinguished name (RDN) has the attributetype dSI.
324 Therefore, finding a suitable indexserver to start the search from is
325 a matter of searching the DIT at a suitable place for objects with
326 the objectClass cIPIndexObject. Every found entry can then be
327 evaluated by looking at the description value as well as the
328 indexOCAT value. The description string should be a human readable
329 and understandable text that describes what the index server is
330 indexing. An example of such a string could be, "This index covers
331 all employees at Swedish Universities and University Colleges that
332 has an email account". The indexOCAT attribute supplies information
333 about which kind of entries and which attributes within these entries
334 that the index information has emanated from. For example, if the
338 Hedberg Experimental [Page 6]
340 RFC 2657 LDAPv2 vs. Index Mesh August 1999
343 indexOCAT attribute value is "person cn", one can deduce that this is
344 an index over persons and not over roles, and that it is the
345 attribute commonName that is indexed.
347 3.2 Searching the mesh
349 Each index server has its information represented in the DIT as a
350 very flat tree. In fact, it is only one level deep.
353 0 Indexservers cIPDataSet
358 cIPDataSet entries cIPIndex entries
359 one for each DataSet one for each index value
360 that this server has that this indexserver
361 gathered indexes from. has.
363 A search then consists of a set of searches. The first being the
364 search for the index entries that contains an indexvalue that matches
365 what the user is looking for, and the second a search based on the
366 DSI information in the extendedDSI attribute values returned from the
367 first search. In the case of the the cIPIndexType being tagged-
368 index, the taglists should be compared to find which DSI it might be
369 useful to pose further queries to.
371 When doing these types of searches, the client should be aware of the
372 fact that the index values disregarding their origin (attributeTypes)
373 always are stored in the index server as values of the idx attribute.
375 The object of the second search is to get information on the
376 different DataSet involved, and should normally be performed as a
377 read. Since the DataSet information probably will remain quite stable
378 over time, this information lends itself very well to caching. If at
379 this stage there is more than one DataSet involved, the User
380 interface might use the description value to aid the user in choosing
381 which one to proceed with. The content of the searchBase value of
382 the DataSet tells the client whether it represents another index
383 server (the most significant part of the dn is a dSI attribute) or if
394 Hedberg Experimental [Page 7]
396 RFC 2657 LDAPv2 vs. Index Mesh August 1999
399 3.3 Querying the end server
401 When finally reaching the end server/servers that probably has the
402 sought for information, the information in the indexOCAT attribute
403 can be used to produce an appropriate filter. If a search for "Rol*"
404 in an index having an indexOCAT attribute value of "person cn"
405 returns an idx entry with the idx value of "Roland", then an
406 appropriate filter to use might be "&(|(cn=* roland *)(cn=roland
407 *)(cn=* roland))(objectclass=person)". A complete example of a
408 search process is given in Appendix A.
410 4. Security Considerations
412 Since this memo deals with client behavior, it does not add anything
413 that either enhances or diminishes the security features that exists
416 5. Internationalization
418 As with security, this memo neither enhances or diminishes the
419 handling of internationalization in LDAPv2.
423 [1] Yeong, W., Howes, T. and S. Kille, "Lightweight Directory Access
424 Protocol", RFC 1777, March 1995.
426 [2] Allen, J. and M. Mealling "The Architecture of the Common
427 Indexing Protocol (CIP)", RFC 2651, August 1999.
429 [3] The Directory: Overview of Concepts, Models and Service. CCITT
430 Recommendation X.500, 1988.
432 [4] Information Processing Systems -- Open Systems Interconnection --
433 The Directory: Overview of Concepts, Models and Service. ISO/IEC
434 JTC 1/SC21; International Standard 9594-1, 1988.
436 [5] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
437 Directory Access Protocol (v3): Attribute Syntax Definitions",
438 RFC 2252, December 1997.
440 [6] Hedberg, R., Greenblatt, B., Moats, R. and M. Wahl, "A Tagged
441 Index Object for use in the Common Indexing Protocol", RFC 2654,
450 Hedberg Experimental [Page 8]
452 RFC 2657 LDAPv2 vs. Index Mesh August 1999
462 Phone: +47 23 08 29 96
463 EMail: roland@catalogix.ac.se
506 Hedberg Experimental [Page 9]
508 RFC 2657 LDAPv2 vs. Index Mesh August 1999
511 Appendix A - Sample Session
513 Below is a sample of a session between a LDAPv2 client and an index
514 server mesh as specified in this memo.
516 The original question of the session is to find the email address of
517 a person by the name, "Roland Hedberg", who is working at "Umea
518 University" in Sweden.
522 A singlelevel search with the baseaddress "c=SE" and the filter
523 "(objectclass=cipDataset)" was issued.
525 The following results were received:
527 DN: dSI=1.2.752.17.5.0,c=SE
529 description= "index over employees with emailaddresses within Swedish
531 indexOCAT= "cn person"
532 cIPIndexType= "x-tagged-index-1" ;
533 searchBase= "dsi=1.2.752.17.5.0,c=SE"
536 DN: dSI=1.2.752.23.1.3,c=SE
538 description= "index over Swedish lawyers"
539 indexOCAT= "cn person"
540 cIPIndexType= "x-tagged-index-1" ;
541 searchBase= "dsi=1.2.752.23.1.3,c=SE"
546 Since the first index seemed to cover the interesting population, a
547 single level search with the baseaddress "dsi=1.2.752.17.5.0,c=SE"
548 and the filter "(|(idx=roland)(idx=hedberg))" was issued.
550 The following results were received:
552 DN: idx=Roland,dSI=1.2.752.17.5.0,c=SE
554 extendedDSI= 1.2.752.17.5.10 1,473,612,879,1024
555 extendedDSI= 1.2.752.17.5.14 35,78,150,200
556 extendedDSI= 1.2.752.17.5.16 187,2031,3167,5284,6034-6040
557 extendedDSI= 1.2.752.17.5.17 17
562 Hedberg Experimental [Page 10]
564 RFC 2657 LDAPv2 vs. Index Mesh August 1999
567 DN: idx=Hedberg,dSI=1.2.752.17.5.0,c=SE
569 extendedDSI= 1.2.752.17.5.8 24,548-552,1066
570 extendedDSI= 1.2.752.17.5.10 473,512,636,777,1350
571 extendedDSI= 1.2.752.17.5.14 84,112,143,200
572 extendedDSI= 1.2.752.17.5.15 1890-1912
573 extendedDSI= 1.2.752.17.5.17 44
575 A comparison between the two sets of extendedDSIs shows that two
576 datasets 1.2.752.17.5.10 and 1.2.752.17.5.14 contains persons named
577 "Roland" and "Hedberg". Therefore, the next step would be to see what
578 the datasets represent. A comparison like this should normally not
583 Two baselevel searches, one for
584 "dsi=1.2.752.17.5.10,dsi=1.2.752.17.5.0,c=SE" and the other for
585 "dsi=1.2.752.17.5.14,dsi=1.2.752.17.5.0,c=SE" with the filter
586 "(objectclass=cipdataset)" were issued.
588 The following results were received:
590 DN: dSI=1.2.752.17.5.10,dSI=1.2.752.17.5.0,c=SE
592 description= "Employees at Umea University,Sweden"
593 indexOCAT= "person cn"
594 searchBase= "o=Umea Universitet,c=SE"
598 DN: dSI=1.2.752.17.5.14,dSI=1.2.752.17.5.0,c=SE
600 description= "Employees at Lund University,Sweden"
601 indexOCAT= "person cn"
602 searchBase= "o=Lunds Universitet,c=SE"
606 Based on the descriptions for the two datasets, "1.2.752.17.5.10" was
607 chosen as the best to proceed with. From the searchbase attribute
608 value, it was clear that this was a base server. The query now has
609 to be somewhat modified. One possibility would be to issue a query
610 with the baseobject "o=Umea Universitet,c=SE" and the filter
611 "(&(cn=Roland Hedberg)(objectclass=person))"
618 Hedberg Experimental [Page 11]
620 RFC 2657 LDAPv2 vs. Index Mesh August 1999
623 Full Copyright Statement
625 Copyright (C) The Internet Society (1999). All Rights Reserved.
627 This document and translations of it may be copied and furnished to
628 others, and derivative works that comment on or otherwise explain it
629 or assist in its implementation may be prepared, copied, published
630 and distributed, in whole or in part, without restriction of any
631 kind, provided that the above copyright notice and this paragraph are
632 included on all such copies and derivative works. However, this
633 document itself may not be modified in any way, such as by removing
634 the copyright notice or references to the Internet Society or other
635 Internet organizations, except as needed for the purpose of
636 developing Internet standards in which case the procedures for
637 copyrights defined in the Internet Standards process must be
638 followed, or as required to translate it into languages other than
641 The limited permissions granted above are perpetual and will not be
642 revoked by the Internet Society or its successors or assigns.
644 This document and the information contained herein is provided on an
645 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
646 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
647 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
648 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
649 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
653 Funding for the RFC Editor function is currently provided by the
674 Hedberg Experimental [Page 12]