home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / asid / asid-minutes-95jul.txt < prev    next >
Text File  |  1995-10-18  |  7KB  |  183 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 33rd IETF on Tuesday, 18 July.
  10.  
  11.  
  12. Agenda Review/Changes
  13.  
  14. The agenda was reviewed and accepted without changes.
  15.  
  16.  
  17. Review/Discuss Revised Charter
  18.  
  19. The proposed charter previously sent to the list was reviewed and
  20. accepted without changes.  Tim will submit it to the Applications Area
  21. Directors for approval.
  22.  
  23. [Reporter's note:  Subsequent to this decision, the responsible Area
  24. Director expressed a desire to form a separate working group to do the
  25. common indexing protocol work, which is currently in the ASID charter.
  26. If this happens, the ASID charter will need revising again.]
  27.  
  28.  
  29. LDAPv2
  30.  
  31. Bob Cooney of the US Navy presented their design and implementation of
  32. MDAP, the Minimal Directory Access Protocol.  MDAP is full DAP run
  33. directly over TCP, without the OSI stack.  This allows digital signature
  34. information to be carried end-to-end from LDAP client to X.500 server to
  35. ensure operation integrity.  MDAP messages are packaged within newly
  36. defined LDAP messages to provide some compatibility with existing LDAP
  37. implementations.  SLDAP is the Navy's implementation of MDAP, and is
  38. based on the freely available U-M LDAP distribution.
  39.  
  40. John Myers presented his proposal for adding strong authentication to
  41. LDAPv2 based on the IMAP authentication work.  A new Bind2Request
  42. LDAPMessage is defined to hold an IMAP4 authentication mechanism as
  43. defined by RFC 1731.  Two new operations, a Bind2Response and a
  44. Bind2Continuation are also defined, allowing different authentication
  45. mechanisms to be negotiated as well as protection mechanisms (i.e.,
  46. integrity or privacy), to be used subsequently on the session.  There
  47. was some discussion of this approach and how it might or might not map
  48. onto X.500 strong authentication.
  49.  
  50. Tim Howes gave a brief report of the approach taken by the Zoomit
  51. company to implement a 93-like paged results feature in LDAP. There was
  52. general agreement that this feature should be supported in a more
  53. standard way in LDAPv2.
  54.  
  55. Tim also gave a brief report of the stand-alone LDAP work going on at
  56. U-M (LDAP without X.500).  The work currently avoids orphaning
  57. stand-alone LDAP servers by using the existing LDAPResult error message
  58. field to return a ``referral'' to knowledgeable clients.  The clients
  59. can then chase the referral to an X.500-aware LDAP server, another
  60. stand-alone server, etc.  The group agreed that the referral capability
  61. was useful and should be incorporated in LDAPv2 in a more standard way.
  62.  
  63. There was a short discussion of how to handle multiple character set and
  64. language issues in LDAPv2, though no conclusion was reached.  Proposals
  65. should be sent to the list.
  66.  
  67. At Danvers, various people promised to help produce an LDAPv2 draft by
  68. this meeting.  But for various reasons, the work was not done, a fact
  69. the chair could not complain about too loudly, since he was one of the
  70. main culprits.  The group agreed to redouble their efforts and produce a
  71. draft by Dallas.
  72.  
  73.  
  74.  
  75. WHOIS++
  76.  
  77. Patrik Falstrom led a discussion of the WHOIS++ portion of the agenda,
  78. first describing the recently-released Bunyip implementation of WHOIS++,
  79. called DIGGER. The two WHOIS++ RFCs (query language and architecture)
  80. have been progressed to Proposed Standard.  The remaining WHOIS++ RFC on
  81. the centroid indexing mesh is being held back pending the resolution of
  82. issues raised by the Area Director and others.
  83.  
  84. The issues raised included:
  85.  
  86.  
  87.   1. The document does not address scaling issues well enough.
  88.      Experiments are ongoing, and the group proposed to produce a
  89.      document by the Dallas meeting documenting the results of these
  90.      experiments.
  91.  
  92.   2. The meaning of ``word'' is not clear.  The group proposed that a
  93.      word be defined using the reserved WHOIS++ tokens.
  94.  
  95.   3. The character set issue was not addressed adequately.  The group
  96.      proposed to limit character sets to unicode and ISO-8859-1, with
  97.      every implementation required to support both.
  98.  
  99.  
  100. The proposed MODE command was also discussed.  The MODE command allows a
  101. WHOIS++ session to temporarily escape to another protocol.  The group
  102. expressed some misgivings about the need for this command, though some
  103. situations in which it would be useful were raised.
  104.  
  105. The current WHOIS++ server handle syntax was proposed to be replaced by
  106. an object identifier (OID). OIDs already have a distributed registration
  107. procedure.  The group agreed this was a good idea.
  108.  
  109. Patrik is to produce a draft by Dallas detailing results of the ongoing
  110. WHOIS++ pilot's scalability.
  111.  
  112.  
  113.  
  114. CIP
  115.  
  116. The WHOIS++ discussion led into the common indexing protocol discussion,
  117. where several issues were raised.  First, the group felt that the
  118. current CIP draft still has some WHOIS++ dependencies that should be
  119. removed.  These include the QUERY part of the centroid selection, which
  120. allows a WHOIS++ query, and the <handle,host,port> tuple used to
  121. identify the server from which a centroid came.  It was suggested, and
  122. the group agreed, that this tuple be replaced by a URL, pointing to the
  123. server.
  124.  
  125. On the subject of CIP use in non-WHOIS++ protocols, the group felt that
  126. a separate draft should be produced for each protocol specifying how it
  127. should use CIP.
  128.  
  129. There was some discussion of scaling issues with CIP, and the consensus
  130. of the group was that the only way to resolve the issues is to pilot the
  131. service and gain some experience with it as it grows.  A draft should be
  132. produced detailing the results of these experiments.
  133.  
  134. Chris Weider is to revise the CIP draft by Dallas
  135.  
  136.  
  137.  
  138. X.500
  139.  
  140. Roland Hedberg presented his draft for storing PGP information in the
  141. X.500/LDAP directory.  There was general agreement that this was a good
  142. thing to do, and the group agreed, based on discussion on the list, that
  143. the syntax for the pGPKey should be IA5String, which would allow
  144. ASCII-armored PGP Keys to be stored in the directory exactly as they are
  145. produced by the PGP software.  Roland is to revise his draft and
  146. experiment with the new format.
  147.  
  148. Ed Reed of Novell was not able to attend the meeting and raise the X.500
  149. issues he wanted addressed.  But the group did have a brief discussion
  150. on the problem of storing 93 schema information in the tree.  Ed had
  151. found the administrative area restriction too confining.  The group
  152. suggested creating sub-administrative areas that could, in turn, have
  153. their own sub-schema definitions.  Without Ed there, it was not clear if
  154. this addressed his needs.  He needs to post his questions to the list
  155. again if he wants more discussion.
  156.  
  157.  
  158. Any Other Business
  159.  
  160. There was no other business, and we ran a little over, so the meeting
  161. was adjourned.  The next meeting of ASID will be at the December IETF in
  162. Dallas, Texas, USA.
  163.  
  164.  
  165. Summary of Action Items
  166.  
  167.    o Tim to submit a charter to the Applications Area Directors for
  168.      approval.
  169.  
  170.    o LDAPv2 volunteers to get cracking and produce a draft by Dallas.
  171.  
  172.    o Patrik is to produce a draft by Dallas detailing results of the
  173.      ongoing WHOIS++ pilot's scalability.
  174.  
  175.    o Chris Weider to revise the CIP draft by Dallas.
  176.  
  177.    o Roland to revise his draft, for storing PGP information in the
  178.      X.500/LDAP directory, and experiment with the new format.
  179.  
  180.    o Ed to post his questions, concerning X.500 issues, to the list
  181.      again if he wants more discussion.
  182.  
  183.