FIND Working Group Roland Hedberg Internet-Draft Umea University Expires in six month January 15, 1997 LDAPv2 client Vs the Index Mesh <draft-ietf-find-cip-ldapv2-01.txt> Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), ftp.isi.edu (US West Coast), ds.internic.net (US East Coast), or munnari.oz.au (Pacific Rim). Distribution of this memo is unlimited. Editorial comments should be sent to the author (Roland.Hedberg@umdac.umu.se). Technical discussion will take place on the IETF FIND mailing list (firstname.lastname@example.org). Abstract Since LDAP v2 clients implemented according to RFC 1777  has no notion on referral. The integration between such a client and a Index mesh, as defined by the current Common Indexing Protocol draft , who heavily depends on referrals has to be handled in a somewhat special way. This document defines one possible way of doing this. 1. Background During the development work with the Common Indexing protocol (CIP)one of the underlying assumptions has been that the interaction between clients and the Index Mesh Servers  would heavily depend on passing of referrals. Protocols like LDAPv2  who lack this functionality has to compensate for it by some means. The way chosen in this draft is to put some more intelligence into the client. The reasoning behind this being first that it is not a major enhancement that is needed and secondly that the intelligence when dealing with the Index Mesh, with or the knowledge about referrals, eventually has to go into the client. 2. The clients view of the Index Mesh If a LDAP v2 client is going to be able to interact with the Index Mesh, the Mesh has to appear as something that is understandable to the client. Basicly this consists of representing the index servers and their contained indexes in a defined directory informations tree (DIT) [3,4] structure and a set of object classes and attribute types that has been proven to be useful in this contex. 2.1 The CIP Object Classes Object class descriptions are written according to the BNF defined in . 2.1.1 cIPIndex The cIPIndex objectClass, if present in a entry, allowes it to holds one indexvalue and information connected to this value. ( 1.2.7188.8.131.52 NAME 'cIPIndex' SUP 'top' STRUCTURAL MUST ( extendedDSI $ idx ) MAY ( indexOCAT ) ) 2.1.2 cIPDataSet The cIPDataSet objectClass, if present in a entry, allowes it to hold information concerning one DataSet. ( 1.2.7184.108.40.206 NAME 'cIPDataSet' SUP 'top' STRUCTURAL MUST ( dSI $ searchBase ) MAY ( indexOCAT $ description $ cIPIndexType $ accessPoint $ protocolVersion $ polledBy $ updateIntervall $ securityOption $ searchBase $ supplierURI $ consumerURI ) ) 2.2 The CIP attributeTypes The attributes idx, indexOCAT, extendedDSI, description, cIPIndexType, searchBase, dSI are used by a client acessing the index server. The other attributes ( accesspoint, protocolVersion, polledBy, updateIntervall, consumerURI, supplierURI and securityOption) are all for usage in server to server interactions. 2.2.1 idx The index value, normally used as or part of the RDN. ( 1.2.7220.127.116.11 NAME 'idx' EQUALITY caseIgnoreIA5Match SYNTAX IA5String SINGLE-VALUE ) 2.2.2 dSI DataSet Identifier, a unique identifier for one particular set of information. This should be a OID but stored in a stringformat. ( 1.2.718.104.22.168 NAME 'dSI' EQUALITY caseIgnoreIA5Match SYNTAX IA5String ) 2.2.3 indexOCAT Describes the type of data that is stored in this entry, by using objectcClasses and attributeTypes. The information is stored as a objectClass name followed by a space and then a attributeType name. A typical example when dealing with whitepages information would be "person cn" . ( 1.2.722.214.171.124 NAME 'indexOCAT' EQUALITY caseIgnoreIA5Match SYNTAX IA5String ) 2.2.5 supplierURI A URI describing which protocols ,hostnames and ports should be used by a indexserver to interact with servers carrying indexinformation representing this dataSet. ( 1.2.7126.96.36.199 NAME 'supplierURI' EQUALITY caseIgnoreIA5Match SYNTAX IA5String ) 2.2.6 searchBase The attribute value for this attribute can be expressed in one of two formats, either a distinguished name or a ldap URI. One can envisage other URI syntaxes, if the client knows about more access protocols besides Ldap, and the interaction between the client and the server can not use referrals for some reason. ( 1.2.7188.8.131.52 NAME 'searchBase' EQUALITY caseExactIA5Match SYNTAX IA5String ) 2.2.7 protocolVersion Common Indexing Protocol version should be 3 presently. ( 1.2.7184.108.40.206 NAME 'protocolVersion' EQUALITY numericStringMatch SYNTAX numericString ) 2.2.8 cIPIndexType What type of index Object that is used to pass around index information. ( 1.2.7220.127.116.11 NAME 'cIPIndexType' EQUALITY caseIgnoreIA5Match SYNTAX IA5String ) 2.2.10 polledBy Distinguished Name of Index servers that polls data from this indexserver. ( 1.2.718.104.22.168 NAME 'polledBy' EQUALITY distinguishedNameMatch SYNTAX DN ) 2.2.11 updateIntervall The maximum duration in seconds between the generation of two updates by the supplier server. ( 1.2.722.214.171.124 Name 'updateIntervall' EQUALITY numericStringMatch SYNTAX numericString SINGLE-VALUE ) 2.2.12 securityOption Wether and how the supplier server should sign and encrypt the update before sending it to the consumer server. ( 1.2.7126.96.36.199 NAME 'securityOption' EQUALITY caseIgnoreIA5Match SYNTAX IA5String SINGLE-VALUE ) 2.2.13 extendedDSI DataSet Identifier possibly followed by a space and a taglist, the later as specified by . ( 1.2.7188.8.131.52 NAME 'extendedDSI' EQUALITY caseIgnoreIA5Match SYNTAX IA5String ) 2.2.14 consumerURI A URI describing be which means a server can accept indexinformation, an example being a mailto URI for MIME email based index transport. ( 1.2.7184.108.40.206 NAME 'consumerURI' EQUALITY caseExactIA5Match SYNTAX IA5String ) 3. The interaction between a client and the Index Mesh A client interaction with the index mesh consists of a couple of rather well defined actions. The first being to find a suitable index to start with, then to transverse the indexmesh and finally to query the servers holding the original data. Note when reading this text that what is discussed here is the clients perception of the DIT, how it is in fact implemented is not discussed. 3.1 Finding a Index Mesh This approach depends on the fact that every index server partaking in a Index mesh is represented in the DIT by a entry of the type cIPDataSet and has a distinguished name (DN) which most significant relative distinguished name (RDN) has the attributetype dSI. Therefore finding a suitable indexserver to start the search from is a matter of searching the DIT at a suitable place for objects with the objectClass cIPIndexObject. Every found entry can then be evaluated by looking at the description value as well as the indexOCAT value. The description string should be a human readable and understandable text that describes what the index server is indexing. An example of such a string could be "This index covers all employees at Swedish Universities and University Colleges that has an email account". The indexOCAT attribute supplies information about which kind of entries and which attributes within these entries that the index information has emanated from. If for instance the indexOCAT attribute value is "person cn" one can deduce that this is a index over persons and not over for instance roles, and that it is the attribute commonName that is indexed. 3.2 Searching the mesh Each index server has it's information represented in the DIT as a very flat tree. In fact it is only one level deep. 0 Indexservers cIPDataSet /|\ / | \ / | \ 0 0 cIPDataSet entries cIPIndex entries one for each DataSet one for each index value that this server has that this indexserver gathered indexes from. has. A search then consists of a set of searches the first being the search for the index entries that contains a indexvalue that matches what the user is looking for and the second a search based on the DSI information in the extendedDSI attribute values returned from the first search. In the case of the the cIPIndexType being tagged-index then the taglists should be compared to find which DSI it might be useful to pose further queries to. When doing this type of searches the client should be aware of the fact that the index values disregarding their origin (attributeTypes) always are stored in the index server as values of the idx attribute. The object of the second search is to get information on the different DataSet involved, and should normally be performed as a read. Since the DataSet information probably will remain quite stable over time this information lends itself very well to caching. If at this stage there are more then one DataSet involved the User interface might use the description value to aid the user in choosing which one to proceed with. The content of the searchBase value of the DataSet tells the client whether it represents another index server ( the most significant part of the dn is a dSI attribute ) or if it is a end server. 3.3 Querying the end server When finally reaching the end server/servers that probably has the sought for information, the information in the indexOCAT attribute can be used to produce a appropriate filter. If a search for "Rol*" in a index having a indexOCAT attribute value of "person cn" return a idx entry with the idx value of "Roland", then a appropriate filter to use might be "&(|(cn=* roland *)(cn=roland *)(cn=* roland))(objectclass=person)". A complete example of a search process is given in Appendix A. 4 Security considerations Since this draft deals with client behavior, it does not add anything that either enhances or diminishes the security features that exists in LDAP v2. 5. Internationalization As with security this draft neither enhances or diminishes the handling of internationalization in LDAP v2. 6. References  W.Yeong, T.Howes and S.Kille, "Lightweight Directory Access Protocol", RFC 1777  J.Allen and M.Mealling "The Architecture of the Common Indexing Protocol (CIP)", INTERNET-DRAFT <draft-find-cip-arch-00.txt>, 9 June 1997  The Directory: Overview of Concepts, Models and Service. CCITT Recommendation X.500, 1988.  Information Processing Systems -- Open Systems Interconnection -- The Directory: Overview of Concepts, Models and Service. ISO/IEC JTC 1/SC21; International Standard 9594-1, 1988.  M.Wahl, A.Coulbeck, T.Howes and S.Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", INTERNET-DRAFT <draft-ietf-asid-ldapv3-attributes-06.txt> 11 July 1997  R.Hedberg, B. Greenblatt, R.Moats and M. Wahl, "A Tagged Index Object for use in the Common Indexing Protocol", INTERNET-DRAFT <draft-find-tagged-03.txt>, 1997 7. Author Roland Hedberg Umdac Umea University S-901 87 Umea, Sweden Phone: +46 90 7865165 Fax: +46 90 7866766 EMail: Roland.Hedberg@umdac.umu.se appendix A - Sample session Below is a sample of a session between a LDAPv2 client and a index server mesh as specified in this draft. The original question of the session is to find the email address of a person by the name "Roland Hedberg" who is working at "Umea University" in Sweden. Step 1. A singlelevel search with the baseaddress "c=SE" and the filter "(objectclass=cipDataset)" was issued. The following results were received: DN: dSI=1.2.7220.127.116.11,c=SE dsi= 1.2.718.104.22.168 description= "index over employees with emailaddresses within Swedish higher education" indexOCAT= "cn person" cIPIndexType= "x-tagged-index-1" ; searchBase= "dsi=1.2.722.214.171.124,c=SE" protocolVersion = 3 DN: dSI=1.2.7126.96.36.199,c=SE dsi= 1.2.7188.8.131.52 description= "index over Swedish lawyers" indexOCAT= "cn person" cIPIndexType= "x-tagged-index-1" ; searchBase= "dsi=1.2.7184.108.40.206,c=SE" protocolVersion = 3 Step 2. Since the first index seemed to cover the interesting population a singel level search with the baseaddress "dsi=1.2.7220.127.116.11,c=SE" and the filter "(|(idx=roland)(idx=hedberg))" was issued. The following results were received: DN: idx=Roland,dSI=1.2.718.104.22.168,c=SE idx= Roland extendedDSI= 1.2.722.214.171.124 1,473,612,879,1024 extendedDSI= 1.2.7126.96.36.199 35,78,150,200 extendedDSI= 1.2.7188.8.131.52 187,2031,3167,5284,6034-6040 extendedDSI= 1.2.7184.108.40.206 17 DN: idx=Hedberg,dSI=1.2.7220.127.116.11,c=SE idx= Hedberg extendedDSI= 1.2.718.104.22.168 24,548-552,1066 extendedDSI= 1.2.722.214.171.124 473,512,636,777,1350 extendedDSI= 1.2.7126.96.36.199 84,112,143,200 extendedDSI= 1.2.7188.8.131.52 1890-1912 extendedDSI= 1.2.7184.108.40.206 44 A comparision between the two sets of extendedDSIs shows that two datasets 1.2.7220.127.116.11 and 1.2.718.104.22.168 contains persons named "Roland" and "Hedberg". Therefore the next step would be to see what the datasets represents. A comparision like this should normally not be left to the user. Step. 3 Two baselevel searches, one for "dsi=1.2.722.214.171.124,dsi=1.2.7126.96.36.199,c=SE" and the other for "dsi=1.2.7188.8.131.52,dsi=1.2.7184.108.40.206,c=SE" with the filter "(objectclass=cipdataset)" were issued. The following results were received: DN: dSI=1.2.7220.127.116.11,dSI=1.2.718.104.22.168,c=SE dsi= 1.2.722.214.171.124 description= "Employees at Umea University,Sweden" indexOCAT= "person cn" searchBase= "o=Umea Universitet,c=SE" respectively DN: dSI=1.2.7126.96.36.199,dSI=1.2.7188.8.131.52,c=SE dsi= 1.2.7184.108.40.206 description= "Employees at Lund University,Sweden" indexOCAT= "person cn" searchBase= "o=Lunds Universitet,c=SE" Step 4 Based on the descriptions for the two datasets, one "1.2.7220.127.116.11" was choosen as the best to proceed with. Since, from the searchbase attribute value it was clear that this was a base server the query now has to be somewhat modified. One possibility would be to issue a query with the baseobject "o=Umea Universitet,c=SE" and the filter "(&(cn=Roland Hedberg)(objectclass=person))"