home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / asid / asid-minutes-96jun.txt < prev    next >
Text File  |  1996-10-07  |  11KB  |  258 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, June 26, 1530-1730
  7.  
  8. - Agenda review/changes
  9.  
  10. The proposed agenda was accepted with minor reordering of some 
  11. items.
  12.  
  13. - application/directory MIME type drafts 
  14.  
  15. - application/directory framework
  16.  
  17. Tim reported that the application/directory framework draft had 
  18. received several minor comments which would be incorporated into the 
  19. next version. The group agreed that after these changes are 
  20. incorporated, the draft should go forward as a proposed standard. 
  21.  
  22. ACTION: Tim to produce a new version of the draft and 
  23. submit it for proposed standard.
  24.  
  25. - versit/pdi vcard profile
  26.  
  27. Patrik Falstrom led the discussion of a number of problems/changes he 
  28. has encountered with the vcard profile and application/directory 
  29. framework. The issues included:
  30.  
  31. - Character set: The default is currently 7-bit ascii. The group agreed 
  32. that this default could safely be changed to UTF-8, since it is a superset 
  33. of 7-bit ASCII, and since there were alternate methods of selecting 
  34. character set within the specification already.
  35.  
  36. - Encoding mechanism: The default is currently 7-bit clean encoding. 
  37. The group agreed to change the default to 8-bit encoding, with the 
  38. appropriate MIME or application/directory field-specific encoding to 
  39. be used if a 7-bit encoding was required.
  40.  
  41. - Linebreaks: The current versit vcard draft states that CR, LF, and 
  42. CRLF sequences should all work as line break sequences. Frank Dawson 
  43. confirmed that the intention here was to do the same thing RFC 822 
  44. does by allowing whatever end-system representation was natural, but 
  45. using a canonical representation on the network. Frank, Patrik, John 
  46. Myers, and Dave Crocker agreed to come up with clarifying wording for 
  47. the draft.
  48.  
  49. ACTION: Frank, Patrik, John, and Dave to clarify 
  50. wording in the vcard draft.
  51.  
  52. In the course of the discussion, Dave Crocker volunteered to write up a 
  53. separate Internet Draft describing how to handle the linebreak 
  54. problem in the general case, since it appears to be something many 
  55. people have run into before.
  56.  
  57. ACTION: Dave to produce "how to handle linebreaks" 
  58. draft.
  59.  
  60. - Timezone representation: The current draft allows a number of 
  61. timezone representations. The group agreed to standardize on always 
  62. using the single format defined in RFC 822.
  63.  
  64. ACTION: Frank and Tim to produce a new version of 
  65. the vcard draft with above revisions.
  66.  
  67. - Brief status of standards track documents 
  68.  
  69. - WHOIS++ documents
  70.  
  71. Patrik Falstrom reported that revisions to the WHOIS++ documents 
  72. are on hold pending the outcome of the FIND group, to determine how 
  73. the indexing portion of WHOIS++ will change when using the common 
  74. indexing protocol. 
  75.  
  76. - LDAPv2 documents
  77.  
  78. Revised drafts have been submitted. One issue was raised regarding the 
  79. language describing how T.61 strings are encoded in the attribute draft. 
  80. Harald was volunteered to come up with some better language. It was 
  81. also noted that the protocol version number (2) was not mentioned in the 
  82. attribute draft. Tim volunteered to fix this.
  83.  
  84. ACTION: Harald to produce revised T.61 language. 
  85.  
  86. ACTION: Tim to revise drafts and resubmit. 
  87.  
  88. - labeledURI objectclass/attribute
  89.  
  90. The IESG objected to the definition of two attributes in the draft. The 
  91. group agreed to revise the draft as the IESG requested, standardizing on 
  92. only one attribute (labeledURI), mentioning the other as historical. 
  93. After this revision, the draft will be put forward for proposed 
  94. standard.
  95.  
  96. ACTION: Mark Smith to revise the labeledURI draft and 
  97. resubmit.
  98.  
  99. ACTION: Harald to submit revised labeledURI draft for 
  100. proposed standard.
  101.  
  102. - PGP objectclass/attribute
  103.  
  104. Roland reported that he had received no comments on the latest version 
  105. this draft, except from David Chadwick, who pointed out that the 
  106. draft does not allow storage of multiple certificates. Roland and David 
  107. volunteered to work this out offline and submit a new version of the 
  108. draft. The group agreed that once these changes are made, the draft 
  109. should go forward for proposed standard.
  110.  
  111. ACTION: Roland and David to revise the pgp draft to 
  112. handle multiple values and resubmit for proposed
  113. standard.
  114.  
  115. - WHOIS++/WHOIS/RWHOIS URL formats
  116.  
  117. The group agreed that each scheme deserved its own URL prefix, and 
  118. decided on the following three prefixes: whois:, rwhois:, whois++:. 
  119. There was some discussion of whether the "++" in the whois++ prefix 
  120. would break any existing implementations. The characters are URL-
  121. legal, and the only problem people could think of was with some C++ 
  122. preprocessors, which the group doubted were in wide use as HTML-
  123. parsing or generating tools. 
  124.  
  125. ACTION: Martin to submit a revised whois++ URL draft. 
  126.  
  127. - LDAPv3
  128.  
  129. - Summary of changes from version 00 to version 01 
  130.  
  131. Mark Wahl presented a summary of changes between version 00 and 
  132. version 01 of the drafts. Changes include:
  133.  
  134. - subschema subentries: Addition to allow schema elements to be stored 
  135. in the tree itself, accessible as a group or from individual entries.
  136.  
  137. - manageDsaIT service control: Allows knowledge references within a 
  138. server to be manipulated, rather than the entries they reference.
  139.  
  140. - preferredLanguage service control: Allows the client to select a 
  141. preferred language. There was some discussion of the scope of this 
  142. service control, and the group agreed it should apply to attribute values 
  143. as well as error messages. An issue was raised on the list that language 
  144. was not enough to solve this problem. One also needs to know the 
  145. representation of the language (e.g., Kanji or Roomaji for Japanese).
  146.  
  147. - multi-stage binds: Allows a general
  148. challenge-response bind mechanism. There was discussion as to why 
  149. LDAPv3 did not use SASL (Simple Authentication and Session Layer) 
  150. for authentication. Discussion focused on two issues: 1) Does the 
  151. LDAPv3 bind mechanism support the same functionality as SASL? John 
  152. Myers thought not, but Mark Wahl thought yes, with the use of other 
  153. credentials in the LDAPv3 bind. 2) Is SASL appropriate for inclusion in 
  154. the LDAP protocol? There was much discussion, and the group agreed to 
  155. continue discussion on the list.
  156.  
  157. ACTION: John Myers to send a summary of his concerns 
  158. to the list to stimulate discussion.
  159.  
  160. - binary attributes requested with ";binary": Allows a client to request 
  161. that any attribute be sent back in binary (BER-encoded) mode. Servers 
  162. are only required to support some attributes in this format (certificates 
  163. and the like). If a server does not support ;binary for an attribute, it 
  164. should act as if the attribute does not exist.
  165.  
  166. - paged results from search: Allows a client to request search results a 
  167. page at a time, and to move around arbitrarily within the result set.
  168.  
  169. - modifyRights: This is currently a protocol addition. The suggestion 
  170. was made on the list that this be an operational attribute rather than 
  171. protocol extension. There was much debate over this, but in the end the 
  172. group agreed that this was marginal functionality and should just be 
  173. removed.
  174.  
  175. - add entry target system: From X.500, an extra parameter to the add 
  176. request that allows an entry and its knowledge reference to be added to 
  177. separate DSAs in a single operation. There was much discussion over 
  178. whether this was needed. There were two objections: 1) The current 
  179. form was X.500-specific, and included a presentation address; 2) The 
  180. same functionality could be provided by multiple operations using the 
  181. manageDsaIT service control. On the pro side, it was pointed out that 
  182. X.500 already uses this feature to solve a problem and why can't we use 
  183. the same thing? The group agreed to continue discussion on the list. 
  184.  
  185. ACTION: Tim to revive discussion on the list. 
  186.  
  187. - mapping onto SSL: A short section of the document was added 
  188. describing how to map LDAP onto an SSL connection. There was some 
  189. discussion as to whether SSL or TLS (Transport Layer Security) was the 
  190. appropriate thing to be mentioning here. The group agreed that TLS 
  191. should be added as soon as a stable document was produced that we 
  192. could reference. 
  193.  
  194. - Discussion of dynamic directory support 
  195.  
  196. There was much discussion on this topic, which involves whether 
  197. LDAP should be extended to support dynamic directories. A dynamic 
  198. directory is one whose data changes frequently, and must be refreshed 
  199. often. The prototypical application for this is a directory containing 
  200. the current IP address of users who dial in or are otherwise mobile. 
  201. There were several issues raised during the discussion.
  202.  
  203. First, does support for this belong in LDAP? Several people at the 
  204. meeting had implemented separate dynamic directory schemes only to 
  205. find that they ended up duplicating much of the functionality already 
  206. found in LDAP. Based on this experience, they felt that the small 
  207. extensions necessary to LDAP to support the required functionality were 
  208. a good idea and well worth the price. Arguments against include the 
  209. fact that LDAP is based on the X.500 models, which define a static 
  210. directory, and the added complexity that dynamic directory support 
  211. would introduce.
  212.  
  213. Second, how should this functionality be included? There were three 
  214. proposals, with variants, put forward. The first was to extend the 
  215. protocol with a new "refresh" operation allowing a client to 
  216. continually tell a server that it is still alive. Responses would also be 
  217. extended so the server could tell a client how often to refresh. 
  218. Information from a client that does not refresh would be deleted from 
  219. the directory. The second was to use the existing modify operation to 
  220. maintain dynamic directory information. In this scheme, the "refresh" 
  221. operation is accomplished by a normal LDAP modify operation. The 
  222. server could communicate the refresh time to the client in an 
  223. operational attribute the cient reads using the search operation. The 
  224. third was to define extended operations using LDAP's extensible 
  225. operation capability to handle this situation.
  226.  
  227. Objections to the first scheme were primarily related to the added 
  228. protocol complexity it introduces. Objections to the second scheme 
  229. centered around the abuse of the LDAP modify operation.
  230.  
  231. Third, how often must refresh occur? The answer to this question 
  232. depends in part on the application, how many clients are using the 
  233. directory, etc. The wide variety of answers to this question led to the 
  234. requirement that the server be able to tell clients how often it would 
  235. tolerate refreshes.
  236.  
  237. Much discussion ensued, which had to be cut short for lack of time. The 
  238. group agreed to continue the discussion on the list.
  239.  
  240. ACTION: Tim to revive dynamic directory discussion 
  241. on the list.
  242.  
  243. - Discussion of typeless DN support
  244.  
  245. This discussion item had to be cut due to lack of time. The group agreed 
  246. to discuss it on the list. 
  247.  
  248. ACTION: Tim to revive typeless DN discussion on the 
  249. list.
  250.  
  251. ACTION: Mark to revise the drafts to reflect consensus reached 
  252. at the meeting and during subsequent mailing list discussion. 
  253.  
  254. - Any Other Business
  255.  
  256. The meeting concluded, slightly late, with an agreement to meet again 
  257. in San Jose.
  258.