home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / find / find-minutes-95dec.txt < prev    next >
Text File  |  1996-06-03  |  6KB  |  184 lines
  1. CURRENT MEETING REPORT
  2.  
  3.  
  4. Minutes of the Common Indexing Protocol Working Group (FIND)
  5.  
  6. Reported by Patrik Faltstrom, Bunyip
  7.  
  8.  
  9. The FIND Working Group met for the first time at the 34th IETF.  
  10. Patrik Faltstrom chaired the meeting.  He first reviewed the charter.
  11.  
  12. It was pointed out that the e-mail address of the Working Group is 
  13. "find@bunyip.com", and nothing else.
  14.  
  15. The Charter gives the Working Group goal as defining one, and only 
  16. one, common indexing protocol which all directory services can use 
  17. when passing indexing information.  Patrik admitted that so far this 
  18. work has been aimed toward WHOIS++, but that he is depending on 
  19. the group for help in making it work across directory protocols.  
  20. Currently there are 2 drafts which came out of the WNILS Working 
  21. Group: one on the Common Indexing Protocol by Chris Weider and the 
  22. other on the WHOIS++ mesh by Patrik.  Patrik intends the second 
  23. version to include LDAP and PH.
  24.  
  25. The way directory information is indexed in the CIP is for each leaf 
  26. node to supply the information to the indexing server (centroid).  When 
  27. the indexing server gets a query it will be able to prune the branches 
  28. where there will be no information.  (Note that the examples are in 
  29. WHOIS++)  The leaf server sends the Data-Changed command:
  30.  
  31. # DATA-CHANGED
  32. o  Version-number:
  33. o  Time-of-latest-centroid-change:
  34. o  Time of message-generation:
  35. o  Server-handle:
  36. o  Host-Name:
  37. o  Host-Port:
  38. o  Best-time-to-poll:
  39. o  Authentication-type:
  40. o  Authentication-data:
  41. # END
  42.  
  43. The centroid uses the Best-time-to-poll value to send a poll command:
  44.  
  45. # POLL
  46. o  Version-number:
  47. o  Type-of-poll:
  48. o  Poll-scope:
  49. o  Start-time:
  50. o  End-time:
  51. o  Template:
  52. o  Field:
  53. o  Server-handle:
  54. o  Host-Name:
  55. o  Host-Port:
  56. o  Hierarchy:
  57. o  Description:
  58. o  Authentication-type:
  59. o  Authentication-data:
  60. # END
  61.  
  62. The polled machine sends back the Centroid-changed response:
  63.  
  64. # CENTROID-CHANGES
  65. o  Version-number:
  66. o  Start-time:
  67. o  End-time:
  68. o  Server-handle:
  69. o  Case-sensitive:
  70. o  Authentication-type:
  71. o  Authentication-data:
  72. o  Compression-type:
  73. o  Size-of-compressed-data:
  74. o  Operation:
  75.  
  76. # BEGIN TEMPLATE
  77. o  Template:
  78. o  Any-field:
  79.  
  80. # BEGIN FIELD
  81. o  Field:
  82. o  Data:
  83.  
  84. # END FIELD
  85. # END TEMPLATE
  86. # END CENTROID-CHANGES
  87.  
  88. Both the template and field are repeatable.
  89.  
  90. Today the only transfer is on the whole centroid, it is case insensitive, 
  91. is the 8879-1 character set, and the tokenization algorithm is white 
  92. space and @.
  93.  
  94.  
  95. More information about the CIP is available at: 
  96.  
  97. http://www.bunyip.com/products/digger
  98.  
  99.  
  100. The question was asked why use this when X500 has replication?  The 
  101. answer is that it is a base for the future.  X500 doesn't offer indexing, nor 
  102. does it provide a common indexing for all protocols.  This model is also 
  103. used for URN to URC resolution at Georgia Tech, and the model may 
  104. allow for Web indexing.  Chris Weider pointed out that it will allow 
  105. for the 1,000 flowers blooming, a term which refers to the multiplicity 
  106. of directory protocols becoming available.
  107.  
  108. Patrik was asked about things not WHOIS++ and he replied that he 
  109. does not believe there will be any problem handling the indexing 
  110. information.
  111.  
  112. Patrik was also asked is the Working Group should do a survey of 
  113. indexing schemes and Patrik replied he was looking for volunteers to do 
  114. so.
  115.  
  116. There was a small semantic discussion on whether it was an indexing 
  117. protocol or whether it was exchanging data to create an index.  Patrik 
  118. would like to have a common format for the index if possible.  Each 
  119. directory service would pass its index to the centroid, which would 
  120. index that index.  And in fact, the index would be indexed at each level 
  121. of the tree.  Some of the issues to study will be the trade-offs of the 
  122. number of levels and the size of the indexes.  A lot of factors are 
  123. involved: data, reduction of indexes, geography.
  124.  
  125. Tim Howes of U Michigan gave a presentation on an program he's 
  126. written called centipede.  The centipede connects to a directory over 
  127. LDAP which tells it what information to produce for the centroid 
  128. index.  It is produced, and centipede then connects to the target with the 
  129. references and uses LDAP to install the index in the entry.  It generates 
  130. distinct values (whole names rather than tokens) which it passes up 
  131. the tree.  The large index allows more precise searches and pruning. Tim 
  132. gave the following URL for more information:
  133.  
  134. http://www.umich.edu/~rsug/ldap
  135.  
  136. CIP has the advantage of you knowing who is indexing you, while
  137. centipede does not.
  138.  
  139. Chris W. reminded the group that all of this was experimental and 
  140. wanted the group to think about what sorts of indexing information 
  141. would be useful.
  142.  
  143.  
  144. The group identified the following issues:
  145.  
  146. o  Character sets
  147. o  Tokenization algorithm
  148. o  Legal issues
  149. o  How to specify for partial centroids
  150. o  New server-to-ask records
  151. o  Schema translations
  152. o  Query result
  153. o  Protocol issues
  154. o  Security
  155. o  Replication
  156. o  Dealing with replicated data
  157. o  Polling cycle detection
  158.  
  159. The group focused on what might be simple.  These issues might be:
  160.  
  161. o  Common format and schema translation
  162. o  Overall model
  163. o  Given a name of a company, return a domain name
  164. o  Index data stored in WHOIS RWHOIS WHOIS++ and X500.
  165.  
  166. The group agreed that the plan of attack should be:
  167.  
  168. 1) Overall model
  169. 2) Schema translation
  170.  
  171. Both Joann Ordille and Roland Hedburg have some experience with 
  172. schema translations that will be useful to the group.
  173.  
  174. It was suggested that we would need a registry of schema with 
  175. descriptions and capabilities.
  176.  
  177. The group also asked what happens when the search result lives on 
  178. WHOIS++ but the client only speaks LDAP.  Proxies were suggested as 
  179. one solution.  Another solution would be to return URLS which 
  180. contained queries which could be handed to a server.
  181.  
  182. The group then elected to defer engineering discussions to the list, and 
  183. Patrik adjourned the meeting.
  184.