home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / asid / asid-minutes-94dec.txt < prev    next >
Text File  |  1995-02-28  |  7KB  |  178 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Tim Howes/University of Michigan
  5.  
  6. Minutes of the Access/Synchronization of the Internet Directories
  7. Working Group (ASID)
  8.  
  9. ASID met once at the 31st IETF on Tuesday, 6 December.
  10.  
  11.  
  12.  
  13. Agenda Review/Changes
  14.  
  15. The agenda was reviewed and accepted with the change that the WPS group
  16. was given an agenda slot to report on their progress, since they did not
  17. have a regular working group slot scheduled at this IETF meeting.
  18.  
  19.  
  20.  
  21. UFN: Review of New Draft
  22.  
  23. Steve Kille produced an updated version of ``Using the OSI Directory to
  24. achieve User Friendly Naming.''  This draft corrects some small errors
  25. in the current RFC. There was no discussion, and the group recommended
  26. that this draft be progressed as soon as possible.  Tim Howes is to
  27. submit the UFN draft to the ADs for progression.
  28.  
  29.  
  30.  
  31. DN String:  Review Of New Draft
  32.  
  33. Steve Kille produced an updated version of ``A String Representation of
  34. Distinguished Names.''  This draft corrects some small errors in the
  35. current RFC. There was no discussion, and the group recommended that
  36. this draft be progressed as soon as possible.  Tim Howes is to submit
  37. the string DN draft to the ADs for progression.
  38.  
  39.  
  40.  
  41. LDAP: Review of New Drafts
  42.  
  43. New versions of the two LDAP drafts were produced, fixing several
  44. editorial and BNF errors, and fixing one small protocol error with the
  45. ModifyRDN operation in the previous documents.  The group decided to
  46. progress these documents to Draft Standard as soon as possible, pending
  47. confirmation that there exists at least two server-side implementations
  48. of LDAP. Tim Howes is to confirm the existence of two independent LDAP
  49. server implementations and then submit the two drafts to the ADs for
  50. progression.
  51.  
  52.  
  53. CLDAP: Final Review of Draft
  54.  
  55. The CLDAP draft was reviewed on the list and submitted for Proposed
  56. Standard.  The IESG had one comment concerning addition of language
  57. describing potential retry algorithms.  This text was added to the draft
  58. and it has been resubmitted for Proposed Standard.
  59.  
  60.  
  61. CENTIPEDE Pilot - Brief Report on What's Happening
  62.  
  63. Chris Weider gave a brief report of a meeting held in Paris in October
  64. amongst some WHOIS++, SOLO and LDAP developers, as well as various other
  65. parties interested in using the WHOIS++ centroids concept as a general
  66. distributed indexing service.  The goal of the group is to develop a
  67. centroids-passing protocol that is independent of any end-user directory
  68. service protocol, and to launch an Internet-wide pilot of this
  69. technology, focusing initially on white pages directory service.
  70.  
  71. The group expects to hold a BOF at the upcoming Danvers, MA IETF
  72. meeting.
  73.  
  74.  
  75. WHOIS++:  Final Review of Drafts
  76.  
  77. Chris Weider explained that in light of the centipede pilot, there would
  78. be changes to the centroid portion of the WHOIS++ specification.
  79. Therefore, the group decided to progress the non-centroids WHOIS++
  80. documents as Proposed Standards.  The centroids document will be revised
  81. by Chris Weider and resubmitted for progression by the next IETF
  82. meeting.  Tim Howes is to submit the two non-centroid WHOIS++ drafts to
  83. the ADs for progression to Proposed Standard.
  84.  
  85.  
  86. SOLO: Latest Developments and Draft
  87.  
  88. A new version of the SOLO draft ``Simple Object Look-up protocol
  89. (SOLO)'' was released in October, just before the centipede meeting.
  90. Christian Huitema suggested that the draft be split into two parts,
  91. similar to the way the WHOIS++ drafts are split.  One part would talk
  92. about the query language, information model, etc., while the other would
  93. talk about navigation and the use of centroids.  The goal here would be
  94. to progress the query language draft, while revising the centroids
  95. navigation draft in light of the centipede experiments.  The group
  96. agreed.
  97.  
  98. It was also noted that the solo draft should be given a name under
  99. draft-ietf-asid-*.
  100.  
  101. Christian Huitema is to split the SOLO draft and submit new versions
  102. through the ASID Working Group.
  103.  
  104.  
  105. X.500 Schema Management - Review Latest Draft
  106.  
  107. A new version of the ``Schema Publishing in X.500 Directory'' draft was
  108. submitted since the last IETF. The only comment on this version was some
  109. concern that the draft does not adequately address the issue of schema
  110. publishing support in the 1993 X.500 standard, and how this draft
  111. relates to it.  The general feeling was that this draft provides some
  112. capability that the 1993 standard does not (ability to look up an
  113. unknown object by OID), and provides an interim solution for the schema
  114. publishing problem.  The authors agreed to add some text to the draft
  115. better explaining this, and then to submit the draft as an Experimental
  116. RFC. Glenn Mansfield is to revise the schema draft and submit it as an
  117. Experimental RFC.
  118.  
  119.  
  120. X.500 LabeledURL Draft - Review Latest Draft
  121.  
  122. Mark Smith produced a draft on storing URL information in X.500 and LDAP
  123. directories via a labeledURL attribute.  In his absence, Tim Howes read
  124. a message from Mark detailing outstanding questions.  The group
  125. overwhelmingly rejected the notion of putting more structure into the
  126. attribute (it is currently a simple string).  The group also rejected
  127. the requirement of including URL: in the syntax, though a note about
  128. implementors tolerating such a thing might be added to the draft.
  129.  
  130. Several members of the URI Working Group were present and suggested that
  131. the attribute might more properly be called labeledURI, so that it might
  132. hold URLs, URNs, and any other UR? that might come along.  There was
  133. general agreement that this would be a good thing.
  134.  
  135. Mark Smith (in absentia) is to revise the labeledURL draft in light of
  136. the working group's input.
  137.  
  138.  
  139. Ph to X.500 Gateway
  140.  
  141. Roland Hedberg gave a presentation on a CCSO Nameserver to X.500 gateway
  142. he has developed.  The gateway brings up issues such as schema mapping,
  143. and the fact that there is no formal specification for the CCSO
  144. protocol.  It would be helpful in developing this and other gateways if
  145. such a specification existed.  The group agreed that the CCSO people
  146. should be approached about documenting their protocol in an ``existing
  147. practice'' RFC, much like was done with the Gopher protocol.  Roland
  148. Hedberg is to contact the CCSO people about this.
  149.  
  150.  
  151. OID Assignments in RFCs - Request From the RFC Editor via Erik
  152.  
  153. A discussion was held on the ``oid in RFCs'' problem raised by the RFC
  154. editor.  The problem has two aspects.  First, should OIDs defined in
  155. Internet Standards all be under some predefined IANA-managed OID arc?
  156. If so, how should this arc be managed?  Second, what should be done
  157. about the existing illegal OIDs that have found their way into RFC 1274,
  158. the Internet X.500 schema document.
  159.  
  160. In answer to the first question, the group felt that there should be
  161. such an arc, and that there should be a procedure by which people can
  162. easily obtain OIDs under it.  It was agreed that OIDs should not be
  163. moved to this arc for existing objects, or objects previously considered
  164. experimental.  This was thought to create a needless transition problem.
  165.  
  166. There was no real answer to the second question, except that it was
  167. noted that Colin Robbins had produced a draft on how to handle this
  168. problem via an OID aliasing mechanism.  Colin's scheme is specific to
  169. the QUIPU implementation of X.500, but might be adapted to other
  170. implementations.
  171.  
  172.  
  173. Next Meeting
  174.  
  175. The meeting concluded early and the group planned to meet again at the
  176. upcoming IETF meeting in Danvers, MA.
  177.  
  178.