rfc2657.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


RFC 2657                 LDAPv2 vs. Index Mesh               August 1999


   indexOCAT attribute value is "person cn", one can deduce that this is
   an index over persons and not over roles, and that it is the
   attribute commonName that is indexed.

3.2 Searching the mesh

   Each index server has its 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 an 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, the taglists should be compared to find which DSI it might be
   useful to pose further queries to.

   When doing these types 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 is more than 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.









Hedberg                       Experimental                      [Page 7]

RFC 2657                 LDAPv2 vs. Index Mesh               August 1999


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 an appropriate filter.  If a search for "Rol*"
   in an index having an indexOCAT attribute value of "person cn"
   returns an idx entry with the idx value of "Roland", then an
   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 memo deals with client behavior, it does not add anything
   that either enhances or diminishes the security features that exists
   in LDAPv2.

5. Internationalization

   As with security, this memo neither enhances or diminishes the
   handling of internationalization in LDAPv2.

6. References

   [1] Yeong, W., Howes, T. and S. Kille, "Lightweight Directory Access
       Protocol", RFC 1777, March 1995.

   [2] Allen, J. and M. Mealling "The Architecture of the Common
       Indexing Protocol (CIP)", RFC 2651, August 1999.

   [3] The Directory: Overview of Concepts, Models and Service. CCITT
       Recommendation X.500, 1988.

   [4] Information Processing Systems -- Open Systems Interconnection --
       The Directory: Overview of Concepts, Models and Service. ISO/IEC
       JTC 1/SC21; International Standard 9594-1, 1988.

   [5] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
       Directory Access Protocol (v3): Attribute Syntax Definitions",
       RFC 2252, December 1997.

   [6] Hedberg, R., Greenblatt, B., Moats, R. and M. Wahl, "A Tagged
       Index Object for use in the Common Indexing Protocol", RFC 2654,
       August 1999.







Hedberg                       Experimental                      [Page 8]

RFC 2657                 LDAPv2 vs. Index Mesh               August 1999


7. Author's Address

   Roland Hedberg
   Catalogix
   Dalsveien 53
   0387 Oslo, Norway

   Phone: [phone]
   EMail: [e-mail]










































Hedberg                       Experimental                      [Page 9]

RFC 2657                 LDAPv2 vs. Index Mesh               August 1999


Appendix A - Sample Session

   Below is a sample of a session between a LDAPv2 client and an index
   server mesh as specified in this memo.

   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.752.17.5.0,c=SE
   dsi= 1.2.752.17.5.0
   description= "index over employees with emailaddresses within Swedish
   higher education"
   indexOCAT= "cn person"
   cIPIndexType= "x-tagged-index-1" ;
   searchBase= "dsi=1.2.752.17.5.0,c=SE"
   protocolVersion = 3

   DN: dSI=1.2.752.23.1.3,c=SE
   dsi= 1.2.752.23.1.3
   description= "index over Swedish lawyers"
   indexOCAT= "cn person"
   cIPIndexType= "x-tagged-index-1" ;
   searchBase= "dsi=1.2.752.23.1.3,c=SE"
   protocolVersion = 3

   Step 2.

   Since the first index seemed to cover the interesting population, a
   single level search with the baseaddress "dsi=1.2.752.17.5.0,c=SE"
   and the filter "(|(idx=roland)(idx=hedberg))" was issued.

   The following results were received:

   DN: idx=Roland,dSI=1.2.752.17.5.0,c=SE
   idx= Roland
   extendedDSI= 1.2.752.17.5.10 1,473,612,879,1024
   extendedDSI= 1.2.752.17.5.14 35,78,150,200
   extendedDSI= 1.2.752.17.5.16 187,2031,3167,5284,6034-6040
   extendedDSI= 1.2.752.17.5.17 17




Hedberg                       Experimental                     [Page 10]

RFC 2657                 LDAPv2 vs. Index Mesh               August 1999


   DN: idx=Hedberg,dSI=1.2.752.17.5.0,c=SE
   idx= Hedberg
   extendedDSI= 1.2.752.17.5.8  24,548-552,1066
   extendedDSI= 1.2.752.17.5.10 473,512,636,777,1350
   extendedDSI= 1.2.752.17.5.14 84,112,143,200
   extendedDSI= 1.2.752.17.5.15 1890-1912
   extendedDSI= 1.2.752.17.5.17 44

   A comparison between the two sets of extendedDSIs shows that two
   datasets 1.2.752.17.5.10 and 1.2.752.17.5.14 contains persons named
   "Roland" and "Hedberg". Therefore, the next step would be to see what
   the datasets represent.  A comparison like this should normally not
   be left to the user.

   Step. 3

   Two baselevel searches, one for
   "dsi=1.2.752.17.5.10,dsi=1.2.752.17.5.0,c=SE" and the other for
   "dsi=1.2.752.17.5.14,dsi=1.2.752.17.5.0,c=SE" with the filter
   "(objectclass=cipdataset)" were issued.

   The following results were received:

   DN: dSI=1.2.752.17.5.10,dSI=1.2.752.17.5.0,c=SE
   dsi= 1.2.752.17.5.10
   description= "Employees at Umea University,Sweden"
   indexOCAT= "person cn"
   searchBase= "o=Umea Universitet,c=SE"

   respectively

   DN: dSI=1.2.752.17.5.14,dSI=1.2.752.17.5.0,c=SE
   dsi= 1.2.752.17.5.14
   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, "1.2.752.17.5.10" was
   chosen as the best to proceed with.  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))"






Hedberg                       Experimental                     [Page 11]

RFC 2657                 LDAPv2 vs. Index Mesh               August 1999


Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Hedberg                       Experimental                     [Page 12]