idnits 2.17.1 draft-ietf-find-cip-ldapv2-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 559 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 27 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 78: '... MUST ( extendedDSI $ idx )...' RFC 2119 keyword, line 79: '... MAY ( indexOCAT )...' RFC 2119 keyword, line 91: '... MUST ( dSI $ searchBase )...' RFC 2119 keyword, line 92: '... MAY ( indexOCAT $ description $ i...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 321 has weird spacing: '...DataSet one ...' == Line 322 has weird spacing: '...ver has that...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 9, 1998) is 9271 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1777 (ref. '1') (Obsoleted by RFC 3494) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2252 (ref. '5') (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 14 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 FIND Working Group Roland Hedberg 2 Internet-Draft Catalogix 3 Expires in six month November 9, 1998 5 LDAPv2 client Vs the Index Mesh 6 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- 18 Drafts as reference material or to cite them other than as 19 ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check 22 the ``1id-abstracts.txt'' listing contained in the Internet- 23 Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 24 ftp.isi.edu (US West Coast), ftp.ietf.org (US East Coast), o 25 munnari.oz.au (Pacific Rim). 27 Distribution of this memo is unlimited. Editorial comments should 28 be sent to the author (Roland.Hedberg@umdac.umu.se). Technical 29 discussion will take place on the IETF FIND mailing list 30 (ietf-find@bunyip.com). 32 Abstract 34 Since LDAP v2 clients implemented according to RFC 1777 [1] has no 35 notion on referral. The integration between such a client and 36 a Index mesh, as defined by the current Common Indexing Protocol 37 draft [2], who heavily depends on referrals has to be handled 38 in a somewhat special way. This document defines one possible 39 way of doing this. 41 1. Background 43 During the development work with the Common Indexing protocol 44 (CIP)one of the underlying assumptions has been that the 45 interaction between clients and the Index Mesh Servers [1] would 46 heavily depend on passing of referrals. Protocols like LDAPv2 [2] 47 who lack this functionality has to compensate for it by some means. 48 The way chosen in this draft is to put some more intelligence 49 into the client. The reasoning behind this being first that it is 50 not a major enhancement that is needed and secondly that the 51 intelligence when dealing with the Index Mesh, with or the 52 knowledge about referrals, eventually has to go into the client. 54 2. The clients view of the Index Mesh 56 If a LDAP v2 client is going to be able to interact with 57 the Index Mesh, the Mesh has to appear as something that is 58 understandable to the client. 59 Basicly this consists of representing the index servers and their 60 contained indexes in a defined directory informations tree (DIT) 61 [3,4] structure and a set of object classes and attribute types that 62 has been proven to be useful in this contex. 64 2.1 The CIP Object Classes 66 Object class descriptions are written according to the BNF defined 67 in [5]. 69 2.1.1 cIPIndex 71 The cIPIndex objectClass, if present in a entry, allowes it to 72 holds one indexvalue and information connected to this value. 74 ( 1.2.752.17.3.9 75 NAME 'cIPIndex' 76 SUP 'top' 77 STRUCTURAL 78 MUST ( extendedDSI $ idx ) 79 MAY ( indexOCAT ) 80 ) 82 2.1.2 cIPDataSet 84 The cIPDataSet objectClass, if present in a entry, allowes it to 85 hold information concerning one DataSet. 87 ( 1.2.752.17.3.10 88 NAME 'cIPDataSet' 89 SUP 'top' 90 STRUCTURAL 91 MUST ( dSI $ searchBase ) 92 MAY ( indexOCAT $ description $ indexType $ 93 accessPoint $ protocolVersion $ polledBy $ 94 updateIntervall $ securityOption $ 95 supplierURI $ consumerURI $ baseURI $ 96 attributeNamespace $ consistencyBase 97 ) 98 ) 100 2.2 The CIP attributeTypes 102 The attributes idx, indexOCAT, extendedDSI, description, 103 cIPIndexType, baseURI, dSI are used by a client acessing the 104 index server. 105 The other attributes ( accesspoint, protocolVersion, polledBy, 106 updateIntervall, consumerURI, supplierURI and securityOption, 107 attributeNamespace, consistencyBase) are all for usage in server 108 to server interactions. 110 2.2.1 idx 112 The index value, normally used as or part of the RDN. 114 ( 1.2.752.17.1.20 115 NAME 'idx' 116 EQUALITY caseIgnoreIA5Match 117 SYNTAX IA5String 118 SINGLE-VALUE 119 ) 121 2.2.2 dSI 123 DataSet Identifier, a unique identifier for one particular set 124 of information. 125 This should be a OID but stored in a stringformat. 127 ( 1.2.752.17.1.21 128 NAME 'dSI' 129 EQUALITY caseIgnoreIA5Match 130 SYNTAX IA5String 131 ) 133 2.2.3 indexOCAT 135 Describes the type of data that is stored in this entry, by using 136 objectcClasses and attributeTypes. The information is stored as 137 a objectClass name followed by a space and then a attributeType 138 name. 139 A typical example when dealing with whitepages information would 140 be "person cn" . 142 ( 1.2.752.17.1.28 143 NAME 'indexOCAT' 144 EQUALITY caseIgnoreIA5Match 145 SYNTAX IA5String 146 ) 148 2.2.5 supplierURI 150 A URI describing which protocols ,hostnames and ports should be used 151 by a indexserver to interact with servers carrying indexinformation 152 representing this dataSet. 154 ( 1.2.752.17.1.22 155 NAME 'supplierURI' 156 EQUALITY caseIgnoreIA5Match 157 SYNTAX IA5String 158 ) 160 2.2.6 baseURI 162 The attribute value for this attribute is a ldap URI. One can 163 envisage other URI syntaxes, if the client knows about more access 164 protocols besides ldap, and the interaction between the client and 165 the server can not use referrals for some reason. 167 ( 1.2.752.17.1.26 168 NAME 'baseURI' 169 EQUALITY caseExactIA5Match 170 SYNTAX IA5String 171 ) 173 2.2.7 protocolVersion 175 Common Indexing Protocol version should be 3 presently. 177 ( 1.2.752.17.1.27 178 NAME 'protocolVersion' 179 EQUALITY numericStringMatch 180 SYNTAX numericString 181 ) 183 2.2.8 cIPIndexType 185 What type of index Object that is used to pass around index information. 187 ( 1.2.752.17.1.29 188 NAME 'cIPIndexType' 189 EQUALITY caseIgnoreIA5Match 190 SYNTAX IA5String 191 ) 193 2.2.10 polledBy 195 Distinguished Name of Index servers that polls data from this indexserver. 197 ( 1.2.752.17.1.30 198 NAME 'polledBy' 199 EQUALITY distinguishedNameMatch 200 SYNTAX DN 201 ) 203 2.2.11 updateIntervall 205 The maximum duration in seconds between the generation of two updates 206 by the supplier server. 208 ( 1.2.752.17.1.31 209 Name 'updateIntervall' 210 EQUALITY numericStringMatch 211 SYNTAX numericString 212 SINGLE-VALUE 213 ) 215 2.2.12 securityOption 217 Wether and how the supplier server should sign and encrypt the update 218 before 220 sending it to the consumer server. 222 ( 1.2.752.17.1.32 223 NAME 'securityOption' 224 EQUALITY caseIgnoreIA5Match 225 SYNTAX IA5String 226 SINGLE-VALUE 227 ) 229 2.2.13 extendedDSI 231 DataSet Identifier possibly followed by a space and a taglist, the later 232 as 233 specified by [6]. 235 ( 1.2.752.17.1.33 236 NAME 'extendedDSI' 237 EQUALITY caseIgnoreIA5Match 238 SYNTAX IA5String 239 ) 241 2.2.14 consumerURI 243 A URI describing be which means a server can accept indexinformation, an 244 example being a mailto URI for MIME email based index transport. 246 ( 1.2.752.17.1.34 247 NAME 'consumerURI' 248 EQUALITY caseExactIA5Match 249 SYNTAX IA5String 250 ) 252 2.2.15 attributeNamespace 254 Any consumer supplier pair has to agree on what attribute that should be 255 used 256 and possibly also the meaning of the attributenames. The value of this 257 attribute 258 should for example be a URI pointing to a document wherein the agreement is 259 described. 261 ( 1.2.752.17.1.35 262 NAME 'attributeNamespace' 263 EQUALITY caseExactIA5Match 264 SYNTAX IA5String 265 ) 267 2.2.16 consistencyBase 269 This attribute is specificly used by consumer supplier pairs that use the 270 tagged index object [6]. 272 ( 1.2.752.17.1.36 273 NAME 'consistencyBase' 274 EQUALITY caseExactIA5Match 275 SYNTAX IA5String 276 ) 278 3. The interaction between a client and the Index Mesh 280 A client interaction with the index mesh consists of a couple 281 of rather well defined actions. The first being to find a 282 suitable index to start with, then to transverse the indexmesh and 283 finally to query the servers holding the original data. 284 Note when reading this text that what is discussed here is the clients 285 perception of the DIT, how it is in fact implemented is not discussed. 287 3.1 Finding a Index Mesh 289 This approach depends on the fact that every index server partaking 290 in a Index mesh is represented in the DIT by a entry of the type 291 cIPDataSet and has a distinguished name (DN) which most 292 significant relative distinguished name (RDN) has the attributetype 293 dSI. 294 Therefore finding a suitable indexserver to start the 295 search from is a matter of searching the DIT at a suitable 296 place for objects with the objectClass cIPIndexObject. 297 Every found entry can then be evaluated by looking at the 298 description value as well as the indexOCAT value. The description 299 string should be a human readable and understandable text 300 that describes what the index server is indexing. An example 301 of such a string could be "This index covers all employees at Swedish 302 Universities and University Colleges that has an email account". 303 The indexOCAT attribute supplies information about which kind 304 of entries and which attributes within these entries that the 305 index information has emanated from. If for instance the indexOCAT 306 attribute value is "person cn" one can deduce that this is 307 a index over persons and not over for instance roles, and 308 that it is the attribute commonName that is indexed. 310 3.2 Searching the mesh 312 Each index server has its information represented in the DIT 313 as a very flat tree. In fact it is only one level deep. 315 0 Indexservers cIPDataSet 316 /|\ 317 / | \ 318 / | \ 319 0 0 320 cIPDataSet entries cIPIndex entries 321 one for each DataSet one for each index value 322 that this server has that this indexserver 323 gathered indexes from. has. 325 A search then consists of a set of searches the first being the 326 search for the index entries that contains a indexvalue that matches 327 what the user is looking for and the second a search based on the 328 DSI information in the extendedDSI attribute values returned from 329 the first search. 330 In the case of the the cIPIndexType being tagged-index then the 331 taglists should be compared to find which DSI it might be useful 332 to pose further queries to. 334 When doing this type of searches the client should be aware of the fact 335 that the index values disregarding their origin (attributeTypes) always 336 are stored in the index server as values of the idx attribute. 338 The object of the second search is to get information on the different 339 DataSet involved, and should normally be performed as a read. 340 Since the DataSet information probably will remain quite stable over time 341 this information lends itself very well to caching. 342 If at this stage there are more then one DataSet involved the 343 User interface might use the description value to aid the user in 344 choosing which one to proceed with. 345 The content of the searchBase value of the DataSet tells the client 346 whether it represents another index server ( the most significant 347 part of the dn is a dSI attribute ) or if it is a end server. 349 3.3 Querying the end server 351 When finally reaching the end server/servers that probably has the 352 sought for information, the information in the indexOCAT attribute 353 can be used to produce a appropriate filter. 354 If a search for "Rol*" in a index having a indexOCAT attribute value 355 of "person cn" return a idx entry with the idx value of "Roland", 356 then a appropriate filter to use might be 357 "&(|(cn=* roland *)(cn=roland *)(cn=* roland))(objectclass=person)". 358 A complete example of a search process is given in Appendix A. 360 4 Security considerations 362 Since this draft deals with client behavior, it does not add anything 363 that either enhances or diminishes the security features that exists 364 in LDAP v2. 366 5. Internationalization 368 As with security this draft neither enhances or diminishes the handling 369 of internationalization in LDAP v2. 371 6. References 373 [1] W.Yeong, T.Howes and S.Kille, "Lightweight Directory Access Protocol", 374 RFC 1777 376 [2] J.Allen and M.Mealling "The Architecture of the Common Indexing 377 Protocol (CIP)", INTERNET-DRAFT , 378 9 June 1997 380 [3] The Directory: Overview of Concepts, Models and Service. CCITT 381 Recommendation X.500, 1988. 383 [4] Information Processing Systems -- Open Systems Interconnection -- 384 The Directory: Overview of Concepts, Models and Service. 385 ISO/IEC JTC 1/SC21; International Standard 9594-1, 1988. 387 [5] M.Wahl, A.Coulbeck, T.Howes and S.Kille, 388 "Lightweight Directory Access Protocol (v3): Attribute Syntax 389 Definitions",RFC 2252, december 1997 391 [6] R.Hedberg, B. Greenblatt, R.Moats and M. Wahl, 392 "A Tagged Index Object for use in the Common Indexing Protocol", 393 7. Author 395 Roland Hedberg 396 Catalogix 397 Dalsveien 53 398 0387 Oslo, Norway 400 Phone: +47 23 08 29 96 401 EMail: roland@catalogix.ac.se 403 appendix A - Sample session 405 Below is a sample of a session between a LDAPv2 client and a index server 406 mesh as specified in this draft. 408 The original question of the session is to find the email address of a 409 person by the name "Roland Hedberg" who is working at "Umea University" 410 in Sweden. 412 Step 1. 414 A singlelevel search with the baseaddress "c=SE" and the filter 415 "(objectclass=cipDataset)" was issued. 417 The following results were received: 419 DN: dSI=1.2.752.17.5.0,c=SE 420 dsi= 1.2.752.17.5.0 421 description= "index over employees with emailaddresses within Swedish 422 higher 423 education" 424 indexOCAT= "cn person" 425 cIPIndexType= "x-tagged-index-1" ; 426 searchBase= "dsi=1.2.752.17.5.0,c=SE" 427 protocolVersion = 3 429 DN: dSI=1.2.752.23.1.3,c=SE 430 dsi= 1.2.752.23.1.3 431 description= "index over Swedish lawyers" 432 indexOCAT= "cn person" 433 cIPIndexType= "x-tagged-index-1" ; 434 searchBase= "dsi=1.2.752.23.1.3,c=SE" 435 protocolVersion = 3 437 Step 2. 439 Since the first index seemed to cover the interesting population a singel 440 level search 441 with the baseaddress "dsi=1.2.752.17.5.0,c=SE" and the filter 442 "(|(idx=roland)(idx=hedberg))" was issued. 444 The following results were received: 446 DN: idx=Roland,dSI=1.2.752.17.5.0,c=SE 447 idx= Roland 448 extendedDSI= 1.2.752.17.5.10 1,473,612,879,1024 449 extendedDSI= 1.2.752.17.5.14 35,78,150,200 450 extendedDSI= 1.2.752.17.5.16 187,2031,3167,5284,6034-6040 451 extendedDSI= 1.2.752.17.5.17 17 453 DN: idx=Hedberg,dSI=1.2.752.17.5.0,c=SE 454 idx= Hedberg 455 extendedDSI= 1.2.752.17.5.8 24,548-552,1066 456 extendedDSI= 1.2.752.17.5.10 473,512,636,777,1350 457 extendedDSI= 1.2.752.17.5.14 84,112,143,200 458 extendedDSI= 1.2.752.17.5.15 1890-1912 459 extendedDSI= 1.2.752.17.5.17 44 461 A comparision between the two sets of extendedDSIs shows that two datasets 462 1.2.752.17.5.10 and 1.2.752.17.5.14 contains persons named "Roland" and 463 "Hedberg". Therefore the next step would be to see what the datasets 464 represents. 465 A comparision like this should normally not be left to the user. 467 Step. 3 469 Two baselevel searches, one for 470 "dsi=1.2.752.17.5.10,dsi=1.2.752.17.5.0,c=SE" and 471 the other for "dsi=1.2.752.17.5.14,dsi=1.2.752.17.5.0,c=SE" with the filter 472 "(objectclass=cipdataset)" were issued. 474 The following results were received: 476 DN: dSI=1.2.752.17.5.10,dSI=1.2.752.17.5.0,c=SE 477 dsi= 1.2.752.17.5.10 478 description= "Employees at Umea University,Sweden" 479 indexOCAT= "person cn" 480 searchBase= "o=Umea Universitet,c=SE" 482 respectively 484 DN: dSI=1.2.752.17.5.14,dSI=1.2.752.17.5.0,c=SE 485 dsi= 1.2.752.17.5.14 486 description= "Employees at Lund University,Sweden" 487 indexOCAT= "person cn" 488 searchBase= "o=Lunds Universitet,c=SE" 490 Step 4 492 Based on the descriptions for the two datasets, one "1.2.752.17.5.10" was 493 choosen as the best to proceed with. Since, from the searchbase attribute 494 value it was clear that this was a base server the query now has to be 495 somewhat modified. 496 One possibility would be to issue a query with the baseobject 497 "o=Umea Universitet,c=SE" and the filter 498 "(&(cn=Roland Hedberg)(objectclass=person))"