home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / asid / asid-minutes-95dec.txt < prev    next >
Text File  |  1995-12-29  |  11KB  |  258 lines
  1. Editor's note:  These minutes have not been edited.
  2.  
  3. From: Tim Howes <tim@umich.edu>
  4. Subject: ASID Minutes from Dallas
  5. Date: Tue, 19 Dec 1995 09:58:08 -0500
  6.  
  7.  
  8.         Access and Searching of Internet Directories
  9.                 Meeting Minutes
  10.  
  11. What:    Access and Searching of Internet Directories
  12. When:    Wednesday, December 6, 1530-1730
  13.  
  14. - Agenda review/changes
  15.  
  16.     The chair apologized for getting the agenda out so late, and
  17.     for not producing a proper document archive.
  18.  
  19.     The proposed agenda was reviewed and accepted without changes.
  20.  
  21. - WHOIS++ status
  22.  
  23.     Patrik Falstrom gave a brief status report on the WHOIS++ query
  24.     protocol documents. They have been submitted to the ADs for
  25.     proposed standard status, and should be reviewed at the next
  26.     IESG meeting.
  27.  
  28.     ACTION: Harald to submit WHOIS++ documents for proposed at
  29.         the next IESG meeting.
  30.  
  31. - CIP status
  32.  
  33.     A new working group (FIND) is forming to define the Common
  34.     Indexing Protocol, and the BOF met just before the ASID
  35.     meeting. ASID will drop this item from its charter.
  36.  
  37. - LDAP status
  38.  
  39.     LDAP has been at draft standard status since last March, and
  40.     the group discussed whether LDAP is ready to progress to full
  41.     standard.  There are multiple independent interoperable
  42.     implementations.  There was a question raised as to whether the
  43.     Kerberos BIND credentials were supported by any implementation
  44.     other than the one from University of Michigan. The group
  45.     agreed that this question should be resolved before LDAP goes
  46.     forward, and Tim agreed to try and find out.  There was another
  47.     question raised as to whether LDAP had seen enough operational
  48.     experience. The consensus of the group is that it has.
  49.  
  50.     There was some confusion in the group about the difference
  51.     between the LDAP protocol and the widely-used University of
  52.     Michigan implementation of LDAP. The LDAP protocol has had one
  53.     version change. It went from version 1 to version 2 when the
  54.     MODRDN operation changed. There have been several versions of
  55.     the U-M implementation of LDAP released, the most recent of
  56.     which is version 3.2. Earlier U-M releases had some bugs in the
  57.     BER encoding that were hampering interoperability with
  58.     conformant LDAP implementations. These bugs have been fixed,
  59.     and the implementations now interoperate, though there are
  60.     still some old implementations out there.
  61.  
  62.     There was also some confusion as to what exactly was being
  63.     proposed for full standard. Again this appeared to stem from
  64.     confusion between the LDAP protocol as a front-end to the
  65.     X.500(88) directory as defined in RFC 1777 and RFC 1778, and
  66.     the University of Michigan implementation of LDAP, which
  67.     includes some experimental extensions transparent to existing
  68.     LDAP clients for doing stand-alone LDAP, passing back
  69.     referrals, indexing information, etc. It is only the former
  70.     that is being considered for standardization. The latter are
  71.     only useful experiments that will hopefully feed into the
  72.     design of the next version of LDAP.
  73.  
  74.     ACTION: Tim to check on implementations of kerberos LDAP BIND
  75.         credentials, and put LDAP up for full standard if there
  76.         are others that interoperate.
  77.  
  78. - LDAP URL format draft
  79.  
  80.     At the last meeting, the LDAP URL format draft was approved by
  81.     the group, provided that it be passed by the URI working group
  82.     for review. This was done, to little comment, and the group
  83.     now suggests that the draft be progressed as proposed standard,
  84.     after it is passed by Harald's URI checklist.
  85.  
  86.     ACTION: Tim to submit LDAP URL format draft to ADs for
  87.         progression as proposed standard.
  88.  
  89. - labeledURI draft
  90.  
  91.     At the last meeting, changes to Mark Smith's labeledURI draft
  92.     were discussed. The group consensus was that both labeledURI
  93.     and labeledURL attributes were useful. Mark changed the draft
  94.     to incorporate both attributes. The group agreed that with
  95.     these changes the draft should be progressed as proposed standard.
  96.  
  97.     ACTION: Tim to submit labeledURI draft to ADs for progression
  98.         as proposed standard
  99.  
  100. - LDAP/X.500 caching draft
  101.  
  102.     The group agreed that the caching draft was useful, but that
  103.     the function would be better served by creating an operational
  104.     attribute, rather than a user attribute to hold the TTL
  105.     information. Some reservation was expressed about the work,
  106.     since this is an area the X.500 standard has intentionally
  107.     avoided. The group agreed that this draft should be revised
  108.     and progressed as experimental.
  109.  
  110.     ACTION: Tim to revise caching draft and circulate to the
  111.         list for comment.
  112.  
  113. - application/directory MIME type draft
  114.  
  115.     Several comments on the application/directory MIME type draft
  116.     since the last meeting have been incorporated, but a new version
  117.     of the draft has not yet been submitted. Changes include the
  118.     addition of a home fax number and change to using multipart/related
  119.     rather than multipart/mixed.
  120.  
  121.     There was some discussion of potential uses for this draft, from
  122.     the straightforward carrying of directory information in email
  123.     from a simple directory query responder, to use as a method of
  124.     carrying directory synchronization information, to the provision
  125.     of directory information over HTTP. There was general agreement
  126.     the draft was useful.
  127.  
  128.     Concern was expressed that the draft defines both a general
  129.     framework for carrying directory information and the specific
  130.     content relating to a person. The issue is that the person
  131.     information implies some schema which should be harmonized
  132.     across all directory services, if this draft is to be useful as 
  133.     a general mechanism for carrying information. This schema
  134.     harmonization is already being tackled by the IDS group. The
  135.     suggestion was made, and the group agreed, that the draft be
  136.     split into two. One draft would define the MIME type and general
  137.     framework for carrying directory content of different types.
  138.     The other draft would define the content for person directory
  139.     information.
  140.  
  141.     A third draft was proposed to define the necessary content for
  142.     handling directory synchronization applications.
  143.  
  144.     ACTION: Tim to split the application/directory MIME type draft
  145.         into two drafts (one framework, one person information).
  146.  
  147.     ACTION: Greg Vaudreil and Ed Reed to write an application/directory
  148.         MIME type content draft for directory synchronization.
  149.  
  150. - leaf/nonleaf draft
  151.  
  152.     This draft was withdrawn by the authors (with the blessing of
  153.     the group), since it had been pointed out on the list that
  154.     the main function of distinguishing leaf from non-leaf objects
  155.     could be done by using an already defined X.500(93) operational
  156.     attribute.
  157.  
  158. - String encoding of presentation address draft
  159.  
  160.     The string encoding of presentation address draft has been
  161.     revised by Steve Kille to support the new IPv6 addressing scheme.
  162.     The group agreed that the draft should go forward, provided
  163.     that it be circulated to the ASID list for comment. The document
  164.     is a product of the TOSI group, so not directly in the ASID
  165.     charter.
  166.  
  167.     ACTION: Steve to circulate the presentation address draft to
  168.         the list.
  169.  
  170. - Storing PGP attributes in the directory draft
  171.  
  172.     Roland Hedberg gave a brief presentation on his draft defining
  173.     an object class and attributes for storing PGP certificates in
  174.     the LDAP/X.500 directory. The presentation prompted much
  175.     discussion.
  176.  
  177.     The debate focused on whether it is better to store
  178.     certificates in the directory directly, or to store a URL
  179.     pointing to the certificate in a PGP key server.  The primary
  180.     advantage of the latter method is one of easier maintenance. If
  181.     the user needs to maintain their key(s) in a PGP key server
  182.     anyway, the added administration and potential for
  183.     inconsistency introduced by storage in the directory is a bad
  184.     thing. On the other hand, storing only a pointer in the
  185.     directory places an extra burden on clients, which will have to
  186.     implement an additional access protocol to retrieve the key
  187.     from the PGP key server.
  188.  
  189.     The group was fairly evenly divided between the two approaches,
  190.     prompting the suggestion that the draft be changed to define
  191.     attributes appropriate for both solutions. The market could
  192.     then decide which was better.
  193.  
  194.     ACTION: Roland to revise the PGP draft to incorporate both
  195.         solutions, and post the revised draft to the list.
  196.  
  197. - SUM500 draft
  198.  
  199.     Vincent Berkhout gave a brief presentation of his SUM500 draft,
  200.     which defines a method of mining the Web and other information
  201.     services for X.500 information. Vincent's idea involves using
  202.     standard HTML pages that, if present on an organization's web
  203.     server, could be read and parsed to produce organization and
  204.     people entries for the X.500 directory.
  205.  
  206.     The group thought the draft useful, and there was discussion
  207.     of Vincent's proposal to rewrite the draft to use the
  208.     application/directory MIME type as the standard format.
  209.  
  210.     ACTION: Vincent to revise the draft to reference the MIME
  211.         type draft, and post the revised draft to the list.
  212.  
  213. - LDAP API RFC 1823
  214.  
  215.     Tim announced that informational RFC 1823 was available that
  216.     documented the University of Michigan LDAP API. The information
  217.     was presented to the group for informational purposes only,
  218.     though a short discussion ensued about the appropriateness of
  219.     doing API work in the IETF.
  220.  
  221. - LDAPv2 presentations and discussion
  222.  
  223.     Dave Horvath of Chromatix gave a presentation on the US Navy's
  224.     work to produce a secure version of LDAP. The Navy's approach
  225.     was to implement MDAP (Minimal DAP - essentially full DAP
  226.     PDUs over some other transport mechanism) as extensions to
  227.     LDAP. Their implementation is called SLDAP (Secure LDAP), and
  228.     it supports strong authentication and end-to-end digital
  229.     signing of search operations and results.
  230.  
  231.     Dave described how they produced a new Windows LDAP DLL that
  232.     implemented the protocol extensions and used the Fortezza
  233.     card for signing. The DLL approach means that existing Windows
  234.     LDAP clients can be used unmodified with the new DLL and still
  235.     receive the benefits of strong authentication and signed
  236.     operations.
  237.  
  238.     Kevin Jordan gave a brief description of the extensions that
  239.     CDC has made to their implementation of LDAP to support some
  240.     X.500(93) operations. The extensions include the addition of
  241.     a ModifyDN operation, an operation to add a context prefix,
  242.     and the ability to set new operational parameters, such as
  243.     the dontUseCopy service control.
  244.  
  245.     There were general apologies from the chair and several other
  246.     working group members because of the general lack of progress 
  247.     made since the last meeting on the LDAPv2 document. More
  248.     promises were made for a draft by the next meeting.
  249.  
  250.     ACTION: LDAPv2 volunteers to get cracking and produce a draft
  251.         by the next IETF.
  252.  
  253. - AOB
  254.  
  255.     No other business was presented, so the group adjourned almost
  256.     on time, agreeing to meet again at the next IETF in Los Angeles.
  257.  
  258.