This is only a rough draft - Megan 04/13/92 Minutes of the 1st meeting of the IETF MHS-DS Working Group San Diego, California March 17, 1992 Reported by Kevin Jordan The first meeting of the MHS-DS Working Group took place on March 17 in San Diego. The duration of the meeting was two hours, from 10:00 until 12:00. Despite the shortness of time, very good progress was made. The meeting was co-chaired by: Harald Tveit Alvestrand of Delab Sintef, Norway Kevin Jordan of Control Data Corporation, Arden Hills, Minnesota, USA After brief introductions and a review of the working group charter, Steve Hardcastle-Kille provided an overview of his paper entitled "PP Use of Directory" This paper defines a comprehensive approach for using X.500 Directory Services to support X.400 routing, RFC1148 address mapping, distribution list expansion, and various other purposes suited to electronic mail. The paper establishes the basis for further work by the MHS-DS Working Group. The working group decided that the following seven draft RFC's will be derived from "PP Use of Directory": 1. An RFC which describes how to represent tables in the directory and which also defines the concept of X.400 routing trees. 2. An RFC which defines the mechanism for mapping X.400 O/R addresses onto X.500 distinguished names. This RFC will define the basic mapping rules, and it will also describe how knowledge information and cross references can be used to avoid unnecessary chaining and referrals through DSA's managed by ADMD service providers. 3. An RFC which defines the mechanism for using X.500 Directory Services to support X.400 routing. This RFC will draw heavily from the concepts defined in the first two RFC's. 4. An RFC which defines the mechanism for using X.500 Directory Services to support mapping between RFC822 addresses and X.400 addresses, in compliance with RFC1148bis. This RFC will also draw heavily from the concepts defined in the first two RFC's. 5. An RFC which defines mechanisms for using X.500 Directory Services to support practical implementations of distribution list expansion and management. 6. An RFC which defines mechanisms for using X.500 Directory Services to support RFC822 mail routing and distribution. 7. An RFC which defines a simple profile of the other RFC's, especially RFC's 1 through 4. This RFC could be used as a guide to producing minimal implementations of the first six RFC's above. We agreed that these RFC's should be released initially as Experimental Drafts. As working implementations become available and practical experience establishes proof of concept, the RFC's will be evolved into Internet Standards. The Working Group openly expressed optimism that working implementations would be available by the end of this year. In fact, a PP-based prototype is already underway. The first four RFC's have top priority. They will be created and distributed before the last three. Our goal is to bless the final drafts of the first four documents at the next general IETF meeting in Boston this summer. It was generally agreed that well performing implementations of these RFC's will need to implement mechanisms for caching information obtained from the directory. This will be necessary in order to minimize the number of directory operations requested during normal operations, thereby optimizing response time in critical functions such as route discovery. A recommendation was made that at least one of the RFC's should provide guidelines for the implementation of caching. In particular, guidelines should be provided for recommended time-to-live values of cache entries. Harald reminded/informed the working group of related work occurring within ISO. Specifically, R.H. Willmott has written a paper concerned with using X.500 Directory Services in support of X.400. This paper is being circulated within the ISO standardization community. Harald brought a copy of the paper to San Diego and provided copies to the MHS-DS membership. We agreed to review this paper and evaluate its relevance to our work plan. Before the meeting was closed, Steve Hardcastle-Kille summarized some new features which will be added to the RFC's in response to comments he has received recently. These features include: 1. Improvement in the mechanism for defining and managing MTA passwords in the directory. Specifically, a mechanism will be defined for using the normal X.500 compare operation to compare MTA passwords. It is likely that this will enhance the security of MTA passwords stored in the directory. 2. Added support for explicitly defining a UA which always causes nondelivery reports to be generated. It is not clear how useful this feature truly is, but it does provide a mechanism for catching undeliverable X.400 addresses as early as possible. 3. Added a hook for discovering MTA's which are common to a community of recipients. This feature allows mutually remote MTA's to optimize their usage of network resources by detecting that a large group of recipients can be reached by relaying mail through a common MTA which will perform a distribution function. For example, an MTA in the US can use this feature to send a single copy of a message to a WEP in France, and the French WEP will distribute the message to a group of MTA's within France. This optimizes utilization of the network link between the US and France. Action items: 1. Kevin Jordan will update the MHS-DS charter such that it specifies the RFC's we intend to produce and the time-frame in which we intend to produce them. 2. Steve Hardcastle-Kille will generate the first four draft RFC's from his "PP Use of Directory" paper and make them available to the working group for review and comment. He will accomplish this prior to the upcoming JENC-3 conference in May. 3. Erik Huizer will provide Steve with an OID to be used for identifying the new draft RFC's. Future meetings: The next meeting of the MHS-DS Working Group will take place at the upcoming JENC-3 (3rd annual Joint European Networking Conference) in Innsbruck, Austria. The meeting will probably take place on Friday, May 15. The third meeting of the MHS-DS Working Group will take place at the next general IETF meeting in Boston, Massachusetts, in July.