home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / asid / asid-minutes-95apr.txt < prev    next >
Text File  |  1995-05-26  |  9KB  |  244 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Tim Howes/University of Michigan
  5.  
  6. Minutes of the Access, Searching and Indexing of Directories
  7. Working Group (ASID)
  8.  
  9. ASID met once at the 32nd IETF on Wednesday, 5 April.
  10.  
  11.  
  12. Agenda Review/Changes
  13.  
  14. The agenda was reviewed and accepted with the change that the group
  15. would discuss revising the charter at the end of the session.
  16.  
  17.  
  18. WHOIS++
  19.  
  20. The two WHOIS++ drafts, draft-ietf-wnils-whois-arch-03.txt and
  21. draft-ietf-wnils-whois-04.txt, have had minor changes made, been
  22. reviewed, and submitted for Proposed Standard to the area directors.  A
  23. third draft, draft-ietf-wnils-whois-mesh-01.txt, is also ready and will
  24. be submitted as a Proposed Standard as soon as it passes last call on
  25. the ASID list.  The WHOIS++ indexing draft was discussed under the next
  26. agenda item.
  27.  
  28. Patrick Falstrom reported on a full WHOIS++ implementation by Bunyip,
  29. currently in a limited alpha test.  Interested parties should contact
  30. Patrick.  Jeff Allen (in absentia) reported on a client API and library
  31. he has implemented.
  32.  
  33.  
  34. Common Indexing Protocol
  35.  
  36. Chris Weider gave an update on the common indexing protocol document
  37. (draft-weider-comindex-00.txt -- formerly the WHOIS++ indexing
  38. document).  The document has been updated to reflect the discussions at
  39. the Paris indexing meeting last October, adding the ability to do
  40. weighting of terms, different methods of index generation, and removal
  41. of WHOIS++ dependencies.  There was some discussion that the document
  42. was still not independent of the WHOIS++ protocol (e.g., the QUERY poll
  43. type, server handles, etc.).  Chris agreed to incorporate changes to
  44. make it more independent which will be discussed on the list.
  45.  
  46.  
  47. SOLO
  48.  
  49. Christian Huitema reported that progress on the SOLO draft has been
  50. stalled due to lack of time by the authors.  Christian expects to have
  51. some time to work on it in the next couple of months, though.  He will
  52. split the draft as discussed at the last IETF into two documents, one
  53. that describes the query protocol and one that describes the use of the
  54. common indexing protocol for navigation and distributed operation.
  55.  
  56. There was also a report from Erik Huizer of a new implementation of SOLO
  57. by the University of Minnesota in their Minuet mail user agent.
  58.  
  59.  
  60. CLDAP
  61.  
  62. At the last IETF, CLDAP was approved by the group to go to the IESG as a
  63. Proposed Standard.  The IESG approved CLDAP as a Proposed Standard, but
  64. the draft never came out as an RFC. The area director speculated that it
  65. had gotten lost somewhere between the IESG and the RFC Editor and
  66. promised to track down the problem.
  67.  
  68.  
  69. LDAP
  70.  
  71. LDAP and associated documents have been approved by the IESG as Draft
  72. Standards and published as RFCs 1777 (LDAP), 1778 (LDAP syntax) and 1779
  73. (string dn).
  74.  
  75. There were brief reports of new LDAP implementations by Zoomit and
  76. Marben and DEC. Tim Howes also reported on a new beta release of the
  77. University of Michigan LDAP implementation which includes a stand-alone
  78. LDAP daemon called slapd.  slapd runs by itself, without an X.500
  79. back-end.
  80.  
  81. There was some discussion of why one would want an LDAP daemon that
  82. maintains its own database and does not just provide a front-end to
  83. X.500.  Tim explained that the hope was in part to encourage more
  84. bottom-up growth of the X.500 directory.  Sites can bring up slapd and
  85. provide a local directory service with little effort, upgrading to full
  86. X.500 easily and transparently when and if they choose.
  87.  
  88.  
  89. LDAPv2
  90.  
  91. The subject of a 93 X.500-compatible and more secure version of LDAP
  92. came up at the last IETF. This time, it was agreed that the current LDAP
  93. DS be allowed to go forward while work begins in parallel on LDAPv2,
  94. which will incorporate some 93 features.
  95.  
  96. Discussion of the candidate 93 X.500 features included:
  97.  
  98.  
  99.    o pagedResults:  the ability to request search results a ``page'' at
  100.      a time, rather than all at once.  This feature is useful in various
  101.      LAN environments which often produce scrollable lists of entries
  102.      from which users select.
  103.  
  104.    o matchedValuesOnly:  the ability to retrieve only those attribute
  105.      values used to match a search filter.  This feature is useful in
  106.      situations where an entry contains a very large number of values
  107.      for an attribute and the DUA is only interested in some of them.
  108.  
  109.    o dnAttributes:  the ability to treat the attributes of an entry's DN
  110.      as part of the entry during a search.  This feature provides the
  111.      ability to flatten the DIT, treating entries strictly as
  112.      collections of attributes.
  113.  
  114.    o EntryInformationSelection:  the ability to select which kinds of
  115.      attributes to return (user, operational, etc.)  Useful for removing
  116.      crufty unwanted attributes from results.
  117.  
  118.    o EntryInformation:  incompleteEntry flag.  Useful for determining if
  119.      a result comes from the full entry, or an incomplete copy of the
  120.      entry.
  121.  
  122.    o serviceControls:  new service controls such as copyShallDo,
  123.      attributeSizeLimit, and subentries.
  124.  
  125.    o modifyRightsRequest:  the ability to request modification rights to
  126.      an entry via the Read operation.  Since LDAP emulates Read with
  127.      Search, this option is problematic.
  128.  
  129.  
  130. In addition, there have been several requests for better security in
  131. LDAPv2 in the form of strong authentication on the Bind operation, and
  132. signing and/or encryption of operations and results.  Christian pointed
  133. out that strong authentication is not too useful without signed
  134. operations, given the ease with which connections can be hijacked.
  135.  
  136. Encryption is not supported by X.500, but could be by LDAPv2.  There
  137. appear to be three options for signing requests.
  138.  
  139.  
  140.    o Make LDAPv2 PDU-compatible with DAP, so the signed requests can be
  141.      passed directly to the DSA. This option lacks many of the
  142.      advantages of LDAP, namely the string encoding of data types, and
  143.      was therefore frowned upon by the group.
  144.  
  145.    o Make the LDAPv2 client pass its key to the trusted LDAPv2 server
  146.      over a secure channel.  The server can then sign operations as the
  147.      client.  The passing of the client's secret key, even in a
  148.      protected way, is probably an increased risk.
  149.  
  150.    o Make the LDAPv2 server sign requests as itself.  It is not clear
  151.      whether this solves the problem or not.
  152.  
  153.  
  154. Volunteers were collected to begin work on an LDAPv2 proposal.
  155.  
  156.  
  157. LDAP URL Format Draft
  158.  
  159. The draft-ietf-asid-ldap-format-00.txt document defines a URL format for
  160. accessing LDAP information via the WWW. Mark Smith has implemented the
  161. format in the libWWW client library and a version of Mosaic.  The group
  162. agreed that the draft should be sent to the URI list for comment, and
  163. then submitted as a Proposed Standard (modulo URI-suggested changes) via
  164. the as-yet-undefined URI Working Group procedures for defining new URL
  165. formats.
  166.  
  167. The prototype implementation is available from:
  168.  
  169.  
  170.      ftp://terminator.rs.itd.umich.edu/ldap/url/
  171.  
  172.  
  173. X.500 Schema Management Draft
  174.  
  175. The draft-ietf-asid-schema-01.txt document was revised after the last
  176. IETF to clarify its relationship to the 1993 standard schema
  177. capabilities.  There was some discussion on the list and in the group
  178. about the need for this document given the capabilities in the 1993
  179. X.500 standard.  The group agreed that the document should be submitted
  180. to the RFC Editor as an Experimental RFC.
  181.  
  182.  
  183. X.500/LDAP labeledURL Draft
  184.  
  185. The draft-ietf-asid-x500-url-01.txt document was revised after the last
  186. IETF to incorporate URIs instead of just URLs.  The group agreed that
  187. the document should go forward as a Proposed Standard and be
  188. incorporated into the Internet X.500 schema, after an appropriate
  189. experimentation period.
  190.  
  191.  
  192. ASID Charter Discussion
  193.  
  194. The group has completed much of its assigned work, and this meeting set
  195. several new work items in the LDAPv2 and Common Indexing Protocol (CIP)
  196. work.  The CIP work was originally proposed for another as-yet-uncreated
  197. working group.  But given ASID has already begun doing some of the CIP
  198. work, and that it has finished some of its earlier work items, Erik
  199. asked, and the group agreed, to revise its charter and take on the new
  200. work.
  201.  
  202. Given the additional focus on indexing, and the lack of any work items
  203. relating to directory synchronization, Erik suggested that the name of
  204. the group be changed to the more accurate ``Access, Searching and
  205. Indexing of Directories.''  The group agreed.
  206.  
  207.  
  208. AOB
  209.  
  210. The group adjourned, with the next meeting scheduled for the summer IETF
  211. in Stockholm.
  212.  
  213.  
  214. Summary of Action Items
  215.  
  216.    o Area directors to progress the first two WHOIS++ documents to
  217.      Proposed Standard.
  218.  
  219.    o Patrick to send the WHOIS++ mesh paper to the ASID and WNILS lists
  220.      for last call.
  221.  
  222.    o Chris to update CIP document based on comments he receives.
  223.  
  224.    o Christian to split the SOLO draft.
  225.  
  226.    o Area director to track down CLDAP and submit it to the RFC Editor
  227.      for publication.
  228.  
  229.    o Tim, Peter Whittaker, Ken Rossen, Mark Smith, Steve Kille (in
  230.      absentia), and Eric Rosenquist to begin work on an LDAPv2 proposal.
  231.  
  232.    o Tim to send the draft-ietf-asid-ldap-format-00.txt document to the
  233.      URI Working Group list for comment.
  234.  
  235.    o Glenn Mansfield to submit the draft-ietf-asid-schema-01.txt
  236.      document to the RFC Editor as an Experimental RFC.
  237.  
  238.    o Tim to submit the draft-ietf-asid-x500-url-01.txt draft to the area
  239.      directors for Proposed Standard.
  240.  
  241.    o Tim to revise the ASID charter and submit it to the list for
  242.      review.
  243.  
  244.