idnits 2.17.1 draft-ietf-find-cip-ldapv2-01.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-04-26) 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 528 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 28 instances of too long lines in the document, the longest one being 18 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 $ c...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 291 has weird spacing: '...DataSet one ...' == Line 292 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 (January 15, 1997) is 9963 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' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 FIND Working Group Roland Hedberg 2 Internet-Draft Umea University 3 Expires in six month January 15, 1997 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), 24 ftp.nordu.net (Europe), ftp.isi.edu (US West Coast), 25 ds.internic.net (US East Coast), or 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 $ cIPIndexType $ 93 accessPoint $ protocolVersion $ polledBy $ 94 updateIntervall $ securityOption $ searchBase $ 95 supplierURI $ consumerURI 96 ) 97 ) 99 2.2 The CIP attributeTypes 101 The attributes idx, indexOCAT, extendedDSI, description, 102 cIPIndexType, searchBase, dSI are used by a client acessing the 103 index server. 104 The other attributes ( accesspoint, protocolVersion, polledBy, 105 updateIntervall, consumerURI, supplierURI and securityOption) are all 106 for usage in server to server interactions. 108 2.2.1 idx 110 The index value, normally used as or part of the RDN. 112 ( 1.2.752.17.1.20 113 NAME 'idx' 114 EQUALITY caseIgnoreIA5Match 115 SYNTAX IA5String 116 SINGLE-VALUE 117 ) 119 2.2.2 dSI 121 DataSet Identifier, a unique identifier for one particular set 122 of information. 123 This should be a OID but stored in a stringformat. 125 ( 1.2.752.17.1.21 126 NAME 'dSI' 127 EQUALITY caseIgnoreIA5Match 128 SYNTAX IA5String 129 ) 131 2.2.3 indexOCAT 133 Describes the type of data that is stored in this entry, by using 134 objectcClasses and attributeTypes. The information is stored as 135 a objectClass name followed by a space and then a attributeType 136 name. 137 A typical example when dealing with whitepages information would 138 be "person cn" . 140 ( 1.2.752.17.1.28 141 NAME 'indexOCAT' 142 EQUALITY caseIgnoreIA5Match 143 SYNTAX IA5String 144 ) 146 2.2.5 supplierURI 148 A URI describing which protocols ,hostnames and ports should be used 149 by a indexserver to interact with servers carrying indexinformation 150 representing this dataSet. 152 ( 1.2.752.17.1.22 153 NAME 'supplierURI' 154 EQUALITY caseIgnoreIA5Match 155 SYNTAX IA5String 156 ) 158 2.2.6 searchBase 160 The attribute value for this attribute can be expressed in one of 161 two formats, either a distinguished name or a ldap URI. One can 162 envisage other URI syntaxes, if the client knows about more access 163 protocols besides Ldap, and the interaction between the client and 164 the server can not use referrals for some reason. 166 ( 1.2.752.17.1.26 167 NAME 'searchBase' 168 EQUALITY caseExactIA5Match 169 SYNTAX IA5String 170 ) 172 2.2.7 protocolVersion 174 Common Indexing Protocol version should be 3 presently. 176 ( 1.2.752.17.1.27 177 NAME 'protocolVersion' 178 EQUALITY numericStringMatch 179 SYNTAX numericString 180 ) 182 2.2.8 cIPIndexType 184 What type of index Object that is used to pass around index information. 186 ( 1.2.752.17.1.29 187 NAME 'cIPIndexType' 188 EQUALITY caseIgnoreIA5Match 189 SYNTAX IA5String 190 ) 192 2.2.10 polledBy 194 Distinguished Name of Index servers that polls data from this indexserver. 196 ( 1.2.752.17.1.30 197 NAME 'polledBy' 198 EQUALITY distinguishedNameMatch 199 SYNTAX DN 200 ) 202 2.2.11 updateIntervall 204 The maximum duration in seconds between the generation of two updates 205 by the supplier server. 207 ( 1.2.752.17.1.31 208 Name 'updateIntervall' 209 EQUALITY numericStringMatch 210 SYNTAX numericString 211 SINGLE-VALUE 212 ) 214 2.2.12 securityOption 216 Wether and how the supplier server should sign and encrypt the update before 217 sending it to the consumer server. 219 ( 1.2.752.17.1.32 220 NAME 'securityOption' 221 EQUALITY caseIgnoreIA5Match 222 SYNTAX IA5String 223 SINGLE-VALUE 224 ) 226 2.2.13 extendedDSI 228 DataSet Identifier possibly followed by a space and a taglist, the later as 229 specified by [6]. 231 ( 1.2.752.17.1.33 232 NAME 'extendedDSI' 233 EQUALITY caseIgnoreIA5Match 234 SYNTAX IA5String 235 ) 237 2.2.14 consumerURI 239 A URI describing be which means a server can accept indexinformation, an 240 example being a mailto URI for MIME email based index transport. 242 ( 1.2.752.17.1.34 243 NAME 'consumerURI' 244 EQUALITY caseExactIA5Match 245 SYNTAX IA5String 246 ) 248 3. The interaction between a client and the Index Mesh 250 A client interaction with the index mesh consists of a couple 251 of rather well defined actions. The first being to find a 252 suitable index to start with, then to transverse the indexmesh and 253 finally to query the servers holding the original data. 254 Note when reading this text that what is discussed here is the clients 255 perception of the DIT, how it is in fact implemented is not discussed. 257 3.1 Finding a Index Mesh 259 This approach depends on the fact that every index server partaking 260 in a Index mesh is represented in the DIT by a entry of the type 261 cIPDataSet and has a distinguished name (DN) which most 262 significant relative distinguished name (RDN) has the attributetype 263 dSI. 264 Therefore finding a suitable indexserver to start the 265 search from is a matter of searching the DIT at a suitable 266 place for objects with the objectClass cIPIndexObject. 267 Every found entry can then be evaluated by looking at the 268 description value as well as the indexOCAT value. The description 269 string should be a human readable and understandable text 270 that describes what the index server is indexing. An example 271 of such a string could be "This index covers all employees at Swedish 272 Universities and University Colleges that has an email account". 273 The indexOCAT attribute supplies information about which kind 274 of entries and which attributes within these entries that the 275 index information has emanated from. If for instance the indexOCAT 276 attribute value is "person cn" one can deduce that this is 277 a index over persons and not over for instance roles, and 278 that it is the attribute commonName that is indexed. 280 3.2 Searching the mesh 282 Each index server has it's information represented in the DIT 283 as a very flat tree. In fact it is only one level deep. 285 0 Indexservers cIPDataSet 286 /|\ 287 / | \ 288 / | \ 289 0 0 290 cIPDataSet entries cIPIndex entries 291 one for each DataSet one for each index value 292 that this server has that this indexserver 293 gathered indexes from. has. 295 A search then consists of a set of searches the first being the 296 search for the index entries that contains a indexvalue that matches 297 what the user is looking for and the second a search based on the 298 DSI information in the extendedDSI attribute values returned from 299 the first search. 300 In the case of the the cIPIndexType being tagged-index then the 301 taglists should be compared to find which DSI it might be useful 302 to pose further queries to. 304 When doing this type of searches the client should be aware of the fact 305 that the index values disregarding their origin (attributeTypes) always 306 are stored in the index server as values of the idx attribute. 308 The object of the second search is to get information on the different 309 DataSet involved, and should normally be performed as a read. 310 Since the DataSet information probably will remain quite stable over time 311 this information lends itself very well to caching. 312 If at this stage there are more then one DataSet involved the 313 User interface might use the description value to aid the user in 314 choosing which one to proceed with. 315 The content of the searchBase value of the DataSet tells the client 316 whether it represents another index server ( the most significant 317 part of the dn is a dSI attribute ) or if it is a end server. 319 3.3 Querying the end server 321 When finally reaching the end server/servers that probably has the 322 sought for information, the information in the indexOCAT attribute 323 can be used to produce a appropriate filter. 324 If a search for "Rol*" in a index having a indexOCAT attribute value 325 of "person cn" return a idx entry with the idx value of "Roland", 326 then a appropriate filter to use might be 327 "&(|(cn=* roland *)(cn=roland *)(cn=* roland))(objectclass=person)". 328 A complete example of a search process is given in Appendix A. 330 4 Security considerations 332 Since this draft deals with client behavior, it does not add anything 333 that either enhances or diminishes the security features that exists 334 in LDAP v2. 336 5. Internationalization 338 As with security this draft neither enhances or diminishes the handling 339 of internationalization in LDAP v2. 341 6. References 343 [1] W.Yeong, T.Howes and S.Kille, "Lightweight Directory Access Protocol", 344 RFC 1777 346 [2] J.Allen and M.Mealling "The Architecture of the Common Indexing 347 Protocol (CIP)", INTERNET-DRAFT , 348 9 June 1997 350 [3] The Directory: Overview of Concepts, Models and Service. CCITT 351 Recommendation X.500, 1988. 353 [4] Information Processing Systems -- Open Systems Interconnection -- 354 The Directory: Overview of Concepts, Models and Service. 355 ISO/IEC JTC 1/SC21; International Standard 9594-1, 1988. 357 [5] M.Wahl, A.Coulbeck, T.Howes and S.Kille, 358 "Lightweight Directory Access Protocol (v3): Attribute Syntax 359 Definitions", INTERNET-DRAFT 360 11 July 1997 362 [6] R.Hedberg, B. Greenblatt, R.Moats and M. Wahl, 363 "A Tagged Index Object for use in the Common Indexing Protocol", 364 7. Author 366 Roland Hedberg 367 Umdac 368 Umea University 369 S-901 87 Umea, Sweden 371 Phone: +46 90 7865165 372 Fax: +46 90 7866766 373 EMail: Roland.Hedberg@umdac.umu.se 375 appendix A - Sample session 377 Below is a sample of a session between a LDAPv2 client and a index server 378 mesh as specified in this draft. 380 The original question of the session is to find the email address of a 381 person by the name "Roland Hedberg" who is working at "Umea University" 382 in Sweden. 384 Step 1. 386 A singlelevel search with the baseaddress "c=SE" and the filter 387 "(objectclass=cipDataset)" was issued. 389 The following results were received: 391 DN: dSI=1.2.752.17.5.0,c=SE 392 dsi= 1.2.752.17.5.0 393 description= "index over employees with emailaddresses within Swedish higher education" 394 indexOCAT= "cn person" 395 cIPIndexType= "x-tagged-index-1" ; 396 searchBase= "dsi=1.2.752.17.5.0,c=SE" 397 protocolVersion = 3 399 DN: dSI=1.2.752.23.1.3,c=SE 400 dsi= 1.2.752.23.1.3 401 description= "index over Swedish lawyers" 402 indexOCAT= "cn person" 403 cIPIndexType= "x-tagged-index-1" ; 404 searchBase= "dsi=1.2.752.23.1.3,c=SE" 405 protocolVersion = 3 407 Step 2. 409 Since the first index seemed to cover the interesting population a singel level search 410 with the baseaddress "dsi=1.2.752.17.5.0,c=SE" and the filter 411 "(|(idx=roland)(idx=hedberg))" was issued. 413 The following results were received: 415 DN: idx=Roland,dSI=1.2.752.17.5.0,c=SE 416 idx= Roland 417 extendedDSI= 1.2.752.17.5.10 1,473,612,879,1024 418 extendedDSI= 1.2.752.17.5.14 35,78,150,200 419 extendedDSI= 1.2.752.17.5.16 187,2031,3167,5284,6034-6040 420 extendedDSI= 1.2.752.17.5.17 17 422 DN: idx=Hedberg,dSI=1.2.752.17.5.0,c=SE 423 idx= Hedberg 424 extendedDSI= 1.2.752.17.5.8 24,548-552,1066 425 extendedDSI= 1.2.752.17.5.10 473,512,636,777,1350 426 extendedDSI= 1.2.752.17.5.14 84,112,143,200 427 extendedDSI= 1.2.752.17.5.15 1890-1912 428 extendedDSI= 1.2.752.17.5.17 44 430 A comparision between the two sets of extendedDSIs shows that two datasets 431 1.2.752.17.5.10 and 1.2.752.17.5.14 contains persons named "Roland" and 432 "Hedberg". Therefore the next step would be to see what the datasets represents. 433 A comparision like this should normally not be left to the user. 435 Step. 3 437 Two baselevel searches, one for "dsi=1.2.752.17.5.10,dsi=1.2.752.17.5.0,c=SE" and 438 the other for "dsi=1.2.752.17.5.14,dsi=1.2.752.17.5.0,c=SE" with the filter 439 "(objectclass=cipdataset)" were issued. 441 The following results were received: 443 DN: dSI=1.2.752.17.5.10,dSI=1.2.752.17.5.0,c=SE 444 dsi= 1.2.752.17.5.10 445 description= "Employees at Umea University,Sweden" 446 indexOCAT= "person cn" 447 searchBase= "o=Umea Universitet,c=SE" 449 respectively 451 DN: dSI=1.2.752.17.5.14,dSI=1.2.752.17.5.0,c=SE 452 dsi= 1.2.752.17.5.14 453 description= "Employees at Lund University,Sweden" 454 indexOCAT= "person cn" 455 searchBase= "o=Lunds Universitet,c=SE" 457 Step 4 459 Based on the descriptions for the two datasets, one "1.2.752.17.5.10" was choosen 460 as the best to proceed with. Since, from the searchbase attribute value it was 461 clear that this was a base server the query now has to be somewhat modified. 462 One possibility would be to issue a query with the baseobject "o=Umea Universitet,c=SE" 463 and the filter "(&(cn=Roland Hedberg)(objectclass=person))"