home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / asid / asid-minutes-97apr.txt < prev    next >
Text File  |  1997-05-29  |  15KB  |  345 lines
  1. Editor's Note:  These minutes have not been edited.
  2.  
  3.  
  4. Access and Searching of Internet Directories WG Meeting
  5. Meeting Minutes
  6. Wednesday, April 9, 1545-1800, 2000-2100
  7. Reported by: Tim Howes and Patrik Faltstrom
  8.  
  9. - Introduction of new co-chair
  10.  
  11.     Patrik Faltstrom was welcomed as the new co-chair of ASID.
  12.  
  13. - Agenda review/changes
  14.  
  15.     The proposed agenda was accepted without change.
  16.  
  17. - Hour 1 1545-1700: LDAPv3 core documents
  18.  
  19.     The following documents were discussed, with the goal of
  20.     making any minor changes needed, issuing a last call, and
  21.     putting the documents forward for proposed standards status.
  22.  
  23.         draft-ietf-asid-ldapv3-protocol-04.txt
  24.         draft-ietf-asid-ldapv3-attributes-04.txt
  25.         draft-ietf-asid-ldapv3-dn-00.txt
  26.         draft-ietf-asid-ldapv3-filter-00.txt
  27.         draft-ietf-asid-ldapv3-url-00.txt
  28.  
  29.     There was some discussion of the master/slave designation
  30.     added to the LDAP url draft draft-ietf-asid-ldapv3-url-00.txt.
  31.     The group felt that this was not a good thing, in the
  32.     absence of a replication model, and since it did not fit
  33.     well into the general URL concept.
  34.  
  35.     ACTION: Tim to revise the URL draft to remove this feature.
  36.  
  37.     There were no revisions proposed to the filter draft
  38.     draft-ietf-asid-ldapv3-filter-00.txt.
  39.  
  40.     Chris Newman commented that the string dn format draft
  41.     draft-ietf-asid-ldapv3-dn-00.txt needed some revision
  42.     of its ABNF.
  43.  
  44.     ACTION: Chris to send proposed ABNF revisions to Mark (DONE).
  45.  
  46.     ACTION: Mark to produce a new DN draft.
  47.  
  48.     The following comments were made on the attributes draft
  49.     draft-ietf-asid-ldapv3-attributes-04.txt. The draft needs a
  50.     keyword index, to make it easier to find things. The keyword
  51.     index, though thought generally useful, was not a must-have at
  52.     this time. The userPassword syntax should be deprecated and
  53.     discussed in the security considerations section. The audio
  54.     syntax, which currently refers to the "SunOS 4.x format" should
  55.     either be updated to reference audio/basic, or removed.
  56.  
  57.     ACTION: Mark to produce a new attributes draft with these
  58.         changes incorporated.
  59.  
  60.     There was a fair amount of discussion on the protocol draft
  61.     draft-ietf-asid-ldapv3-protocol-04.txt. Most of the discussion
  62.     centered around the use of SASL in the document and whether
  63.     it was correct. The following concensus was arrived at:
  64.  
  65.     - The SASL credentials should be OPTIONAL
  66.     - No SASL mechanism name should be included on the BindResponse
  67.     - Some language was needed advising that changing the SASL
  68.       authentication layer during an LDAP session is allowed, but
  69.       changing the SASL security layer is not allowed.
  70.  
  71.     An additional point was raised by Nick Emery about the handling
  72.     of unknown filter components in searches. The current draft
  73.     says such components are to be treated as though they match no
  74.     entries.  This leads to the undesirable result that a filter
  75.     searching for (!(unknown component)) returns all entries. After
  76.     some discussion, the group agreed to adopt the tri-state logic
  77.     used by X.500.
  78.  
  79.     Jeff Hodges suggested a number of clarifications in the text
  80.     describing subschema subentries and extensible matching.
  81.  
  82.     Another discussion topic involved the lack of protocol
  83.     encoding examples in the draft. Examples of on-the-wire
  84.     client/server interactions were thought to be very useful,
  85.     and a pretty standard part of many other Internet protocol
  86.     specifications.
  87.  
  88.     Mark Wahl stated that he is working on a separate document
  89.     explaining the basics of BER encoding needed by LDAP. This
  90.     document will contain somewhere between 8 and one hundred
  91.     examples. Since BER encoding is (unfortunately) more complicated
  92.     than many of the simple text encodings used by other protocols,
  93.     a separate document (or perhaps appendix to the protocol
  94.     document) was thought to be the best approach.
  95.  
  96.     To avoid holding back LDAPv3 at this time, the group agreed
  97.     that the document should go forward, with examples being
  98.     added when the document goes from proposed to draft.
  99.  
  100.     The group also discussed the fact that the LDAPv3 drafts
  101.     referenced the SSL specification, which is not an Internet
  102.     standard. The group agreed that the goal is to reference
  103.     the TLS specification when it becomes available. The status
  104.     of TLS was not known, but it was thought that it should be
  105.     moving forward soon. The group agreed to change the LDAPv3
  106.     reference to TLS in anticipation of the TLS specification
  107.     being progressed along with LDAPv3.
  108.  
  109.     There was further discussion of the relationship between
  110.     SASL and TLS, and that the lack of clarity on that relationship
  111.     is contributing to the slow progression of SASL. The group
  112.     agreed that this relationship should be clarified ASAP.
  113.  
  114.     There was also discussion about the fact that the LDAP
  115.     documents reference the X.500 standard in many places,
  116.     and that X.500 is not freely available on the net. The
  117.     question was whether this would prevent the drafts from
  118.     progressing. Based on precedents set by SNMP and other
  119.     IETF work, the group did not feel this should be a problem.
  120.  
  121.     ACTION: John Myers to work with the security area director
  122.         and the TLS group to clarify the SASL and TLS specs.
  123.  
  124.     ACTION: Mark to produce a new protocol draft with these
  125.         changes incorporated.
  126.  
  127.     ACTION: Tim and Patrik to ensure that examples are included
  128.         before LDAPv3 goes to draft standard.
  129.  
  130.     The group agreed that after the documents were revised
  131.     (estimated time to revise: 1 week), last call should be
  132.     issued on the ASID list. At the conclusion of a successful
  133.     ASID last call, the documents should be given to the
  134.     area directors for approval of the IESG.
  135.  
  136.     ACTION: Tim and Patrik to issue last call to ASID on revised
  137.         documents.
  138.  
  139.     ACTION: Tim and Patrik to request progression of the documents
  140.         pending successful ASID last call.
  141.  
  142. - Hour 2 1700-1800: MIME-DIR and WHOIS++
  143.  
  144.     - WHOIS++ drafts
  145.  
  146.     Patrik reported that new WHOIS++ drafts have been produced
  147.     with no protocol changes, only revisions and clarifications
  148.     from operational experience implementing the protocol.
  149.  
  150.     One example of a such clarification is the addition of a
  151.     grammar for the output from a Whois++ server to the existing
  152.     grammar for the input to a Whois++ server.
  153.  
  154.     The group agreed that a last call should be issued on the
  155.     revised documents, after which they should be put forward
  156.     for draft standard status.
  157.  
  158.     ACTION: Patrik and Tim to issue last call on the revised
  159.         WHOIS++ documents and progress to the area directors.
  160.  
  161.     - application/directory framework
  162.  
  163.     There was much fruitful discussion of the application/directory
  164.     framework document. The first issue discussed was whether the
  165.     content-type should be changed to text/directory. The argument
  166.     for is that the information is primarily textual in nature and
  167.     the desired behavior is to have the content-type displayed to
  168.     users even if the type is unknown. After a brief struggle, the
  169.     group agreed to change the content-type to text/directory.
  170.  
  171.     A more conetentious issue surrounded the use of the "lang"
  172.     parameter defined in the draft. The values of the "lang" parameter
  173.     are currently defined to be language tags from RFC 1766. Patrik
  174.     argued that an additional tag (he proposed calling it "default")
  175.     was needed to support the use of text/directory in WHOIS++.
  176.     The tag is needed so that applications (like WHOIS++) may
  177.     determine which (if any) attributes to return in the event
  178.     that the language requested by the client is not present.
  179.  
  180.     After much debate, misunderstanding, and confusion, it was
  181.     decided not to add this to the spec. The argument was made
  182.     that 1) the default solution is not entirely correct, since
  183.     it does not also provide a way to determine the type of the
  184.     default language returned, and 2) the parameter set is already
  185.     extensible, so something could be defined later to solve
  186.     this problem.
  187.  
  188.     The final issue discussed was the use of the "charset"
  189.     attribute parameter, allowing the character set to be set on
  190.     individual values within a text/directory content-type.
  191.     This was felt to be a Bad Thing and contrary to the MIME
  192.     way of doing things and contrary to the IAB character set
  193.     proclamation (thou shalt use UTF-8) by several people.
  194.  
  195.     After a bit of debate, the group decided to remove the "charset"
  196.     attribute parameter and require the UTF-8 "charset" MIME header
  197.     parameter be specified by default on text/directory content-types.
  198.     The result of this is the loss of ability to switch charsets
  199.     on a per-value basis within a text/directory component, but
  200.     this was thought to be a good thing.
  201.  
  202.     ACTION: Tim to produce a new MIME-DIR draft with the agreed
  203.         on changes.
  204.  
  205.     ACTION: Tim and Patrik to progress the revised draft to the area
  206.         directors.
  207.  
  208.     - vcard profile
  209.  
  210.     One comment received prior to the meeting was the use of
  211.     English as the default language in the vCard profile. The
  212.     group agreed that this statement should be removed, and that
  213.     there should be no default language associated with the
  214.     vCard profile.
  215.  
  216.     Two additions to the vCard profile had been proposed to the
  217.     ASID list by the MOPA consortium (Mobile Office Promotion
  218.     Association). The additions were for a CLASS attribute and a
  219.     PCS property on the TEL attribute.
  220.  
  221.     The CLASS attribute would identify the class of the information
  222.     contained in the profile (e.g., PRIVATE or PUBLIC).
  223.  
  224.     The PCS property would identify a TEL attribute as referring
  225.     to a PCS telephone.
  226.  
  227.     The group considered these additions useful, but there was
  228.     some discussion of where we should draw the line before
  229.     putting vCard forward as a proposed standard. After a bit of
  230.     discussion, the group agreed to allow these two additions
  231.     and then progress the draft to proposed standard.
  232.  
  233.     ACTION: Frank Dawson to revise the vCard draft with these
  234.         changes.
  235.  
  236.     ACTION: Tim and Patrik to progress the revised draft to the area
  237.         directors.
  238.  
  239. - Hour 3 2000-2100: Various LDAP documents
  240.  
  241.     This hour began with the daunting task of listing the 15
  242.     (count them 15) documents submitted for the group's consideration.
  243.     The documents were:
  244.  
  245.     draft-ietf-asid-ldapv3-lang-00.txt
  246.         use of language codes in LDAPv3
  247.     draft-ietf-asid-ldapv3-strong-00.txt
  248.         SASL authentication mechanism for X.500 authentication
  249.     draft-ietf-asid-ldapv3schema-x500-00.txt
  250.         LDAPv3 definitions of X.500 schema
  251.     draft-ietf-asid-schema-pilot-00.txt
  252.         LDAPv3 definitions of pilot schema
  253.     draft-ietf-asid-ldapv3-simple-paged-01.txt
  254.         LDAPv3 extension for simple paged results
  255.     draft-ietf-asid-ldapv3ext-03.txt
  256.         LDAPv3 extension for dynamic directories
  257.     draft-ietf-asid-replica-selection-00.txt
  258.         How to use SRV records to select LDAP servers
  259.     draft-ietf-asid-ldapv3-sorting-00.txt
  260.         LDAPv3 extension for sorting results
  261.     draft-ietf-asid-ldapv3-referral-00.txt
  262.         referrals and knowledge references in LDAPv3
  263.     draft-ietf-asid-ldapv3-api-00.txt
  264.         Update of RFC 1823 for LDAPv3, etc.
  265.     *draft-ietf-asid-ldap-mult-mast-rep-00.txt
  266.         Multi-master replication proposal
  267.     *draft-ietf-asid-ldif-00.txt
  268.         LDAP text directory interchange format
  269.     *draft-ietf-asid-changelog-00.txt
  270.         LDAP text changelog format
  271.     draft-ietf-asid-email-routing-su-00.txt
  272.     draft-ietf-asid-email-routing-ns-00.txt
  273.         Two email routing using LDAP proposals
  274.  
  275.     The group started by agreeing not to try and discuss
  276.     all the documents, but rather to spend the first part
  277.     of the meeting deciding what to discuss. The group first
  278.     decided that the two email routing documents were outside
  279.     the scope of ASID, so they were crossed off the list.
  280.  
  281.     The group next decided that replication was the topic of most
  282.     interest, with replica selection a close second. So, discussion
  283.     began on replication with an attempt to answer three questions:
  284.  
  285.     1) Should we be working on directory replication?
  286.     2) What group should do the work?
  287.     3) What should be the scope of the work?
  288.  
  289.     There was much debate on these topics, mixed together with
  290.     debate about the future of the ASID group. The latter topic
  291.     was raised with the idea (put forward off-line by the area
  292.     directors) of splitting ASID into two groups: one for LDAP
  293.     and one for text directory stuff (WHOIS++, MIME-DIR, etc).
  294.     The group thought this was basically a good idea.
  295.  
  296.     Debate on question 1) quickly consensized on a decision
  297.     that replication is definitely a problem that we should be
  298.     tackling.
  299.  
  300.     Debate on question 2) was somewhat tangled up with the scope of
  301.     the work. Some people felt that replication was a big and
  302.     separable enough problem that a separate working group was
  303.     required. Others felt that replication would soon drag in other
  304.     problems (e.g., access control, schema) that really need to be
  305.     considered by the entire group. Consensus on this issue was
  306.     rough, at best, but the group seemed to be leaning towards
  307.     handling replication in ASID (or the as-yet-unformed LDAP
  308.     group), for the reasons given above.
  309.  
  310.     Question 3) generated lots of discussion. The proposals
  311.     ranged from a general replication solution, to a general
  312.     LDAP-only solution, to an LDAP-only solution specific to
  313.     either multi-master or single-master models. There was much
  314.     concern that to make any progress we should try to focus
  315.     the problem as narrowly as possible. After much discussion,
  316.     the group consensificated that we should narrow our focus to
  317.     LDAP replication, and not try to solve the more general
  318.     problem.
  319.  
  320.     After much further debate with little progress, the group
  321.     decided to switch gears and discuss one of the other documents.
  322.     The replica selection document was chosen. Paul Leach
  323.     described the draft briefly, which defines a method of locating
  324.     LDAP servers, given a domain name, based on SRV records. The
  325.     group thought the concept useful, but very similar to a general
  326.     procedure outlined in a draft from the DNS group for using
  327.     SRV records. The group agreed that Paul should talk to the
  328.     DNS group to ensure that they two documents did, in fact,
  329.     overlap, and that everything needed in Paul's document was
  330.     present in the DNS SRV record document.
  331.  
  332.     ACTION: Paul Leach to follow-up with the DNS group.
  333.  
  334.     ACTION: Tim and Patrik to chase the group-splitting issue
  335.         with the area directors.
  336.  
  337. - Any Other Business
  338.  
  339.     Noting the lateness of hour, the general glazed look of the
  340.     participants, and the fact that another meeting's attendees
  341.     begain filing into the room, the ASID meeting concluded, about
  342.     on time.
  343.  
  344.     The next ASID meeting will be in August in Munich, Germany.
  345.