INTERIM_MEETING_REPORT_ Reported by Kevin Jordan/CDC Minutes of the MHS-DS Working Group (MHSDS) May 11, 1992 The following documents written by Steve Hardcastle-Kille are to undergo serious reviewing by the MHS-DS Group: 1. Representing Tables and Subtrees in the Directory 2. Representing the O/R Address hierarchy in the Directory Information Tree 3. MHS use of Directory to support MHS Routing 4. Use of the Directory to support mapping between X.400 and RFC 822 Addresses 5. MHS use of the Directory to support distribution lists 6. A simple profile for MHS use of Directory 7. Use of the Directory to support routing for RFC 822 and related protocols Classification by Harald Tveit Alvestrand 1. Non controversial 2. Simple 3. This is the principal document. You need to understand 1 and 2 first. 4. Simple use of 1 and 2 5. Simple 'repairing' of an X.400(88) bug 6. Terse. You must understand 1, 2 and 3 first! It tells you what you need to implement as a minimum. 7. Terse. This document is about applying the algorithms of 3 to Internet-like networks. In addition, document 3 currently covers issues related to content conversion. Harald has recommended that this be removed from document 3 into a new document (8). Harald also gave a short tutorial on the documents. (This does not replace a serious reading of the documents by everybody but helps understanding the overall concept.) Parallel efforts in ISO 1 There exists also a proposal from Robert Willmoet, UK, distributed within OSI. It has a different concept. Steve Hardcastle-Kille intends to forward his proposal also to ISO and CCITT. There is not much hope to get a stamp by CCITT since the proposal allows to bypass the ADMD infrastructure. There is at least some hope to get it accepted within ISO. Secretary's note: (I learned in the mean time that DEC will release a X.400(88) SW with X.500 usage for MHS routing and mapping (Dec 1992). I do not know the methods they use but it is probably different from Steve's and Robert's proposals. I even do not know how the mapping works: DEC, RFC987, RFC1148, RFC1327...) Security There is the still unsolved problem of the need of bilateral agreements to make the X.400 service a little bit more secure than SMTP. (There is the possibility of strong authentication in the applications.) It is proposed to spend some time on inserting more security functions into Steves documents. The hooks are already built in (see doc 3, chapter 20). PAP: The researchers in the internet are happy with what they have now. With any new solution we should take the industrial community into account. Authentication is an important topic there. Questions and Answers A part of the discussions was based on questions put forth by the meeting participants, and answers were provided mainly by those who have read Steve's papers. Will people implement it? Yes, Control Data and the ISODE Consortium will lead to two implementations. Other commercial suppliers know that they must sort out the routing problem, so there might be a chance to get more implementations. A solution for the EAN software depends on funding. Will it work and be fast enough? Probably. Will people keep the data up to date? Yes, as soon as it is needed for proper operation. What happens with an email address containing ADMD=`single space'? This is solved. See doc 2 fig 1. How to use trees? How many trees are needed? This is very open. Practical experience will show what is reasonable. Doc 3 drafts several solutions. Users will probably also start to set up private subtrees, on a service provider level as within networks, or even within universities where they do not want to publish user information in the public tree. 2 How to control access to the trees? What info should go to the open tree? Even UA information can be stored in the open tree. It is possible to set ACLs such that UA/user information is hidden. The routing algorithm will select routing information from higher up in the tree. What is the behaviour of the algorithm, if it gets errors back on queries? This may happen due to ACLs set, or unavailable DSAs,... We need a list of possible failure reasons and a definition of the appropriate behaviour of the algorithm. Where to locate the open tree? Discussion lead to the proposal to put the routing tree under @O=x400routing. This gives independence from the owners of the country entries. How to optimise access to the DIT? Attribute inheritance was found a good solution to optimise DIT access. Reading an attribute at the end of the DIT will then also give back the routing info stored higher up. Attribute inheritance is not defined in X.500 yet. How does a network without DSA access send mail to the DSA-documented world/MTAs? Such a network will have to have an agreement with an MTA which has access to DSAs. At a first glance this seems feasible. In addition, it will probably be necessary to develop tools which extract routing information from the directory and generate static tables like the tables currently used by the RARE X.400 community. These tools will allow existing X.400 implementations to migrate toward direct usage of X.500 over time. How does routing through body type converters work? It is proposed to take this item out of the documents until the problems are better understood. A pilot Alf Hansen proposes to start a pilot project to check if the ideas really work. A very simple implementation will be included in the next public release of PP. The pilot should take into consideration: o The co-ordination of the MTA managers which start to use it o Mechanisms for loading the directory information tree with existing data o Strategies for transition from current table-based routing and mapping methods to Directory-based methods o Implementation and distribution of tools to support MTAs in both worlds, i.e., both Directory and table-based MTA's o Time frame - date mentioned: spring 1993 o The co-ordination could also be done in the COSINE-MHS framework. This should then be included in the follow-up contract for the 3 organisation which wants to provide these services in 1993. The distribution list (all of the following addresses should work) o mhs-ds@mercury.udev.cdc.com o S=mhs-ds;OU=mercury;O=udev;P=CDC;A=ATTmail;C=US o S=mhs-ds;OU=mercury;OU=oss;OU=arh;O=cpg;P=CDC;A=ATTmail;C=US will be used for the co-ordination of the pilot in a first stage. Next Meeting The next meeting of the MHS-DS Working Group will take place at the IETF meeting in Boston, Massachusetts. Scheduled sessions are, Monday, July 13th at 4:00pm and Tuesday, July 14th at 9:30am. Everybody is invited to attend this meeting. Further discussion will also take place on the distribution list (see above). Send request for registration to the list to: o mhs-ds-request@mercury.udev.cdc.com o S=mhs-ds-request;OU=mercury;O=udev;P=CDC;A=ATTmail;C=us o S=mhs-ds-request;OU=mercury;OU=oss;OU=arh;O=cpg;P=CDC;A=ATTmail;C=US Attendees Harald Alvestrand harald.alvestrand@delab.sintef.no Denis Buffenoir denis.buffenoir.inria.fr Jim Craigie craigie@jntg.ac.uk Havard Eidnes havard.eidnes@runit.sintef.no Urs Eppenberger eppenberger@switch.ch Andrew Findlay Andrew.Findlay@brunel.ac.uk Ole Frendved Hansen ole.frendved.hansen@uni-c.dk David Goodman d.goodman@cs.ucl.ac.uk Alf Hansen Alf.Hansen@delab.sintef.no Erik Huizer huizer@surfnet.nl Wolfgang Jaretzki jaretzki@dfn.dbp.de Kevin Jordan kej@udev.cdc.com Peter Kaufmann kaufmann@dfn.dbp.de Bruno Koechlin bruno.koechlin@inria.fr Erik Lawaetz uniel@uts.uni-c.dk Jean-Paul Le Guigner leguigner@cicb.fr Thomas Lenggenhager lenggenhager@switch.ch Damanjit Mahl damanjit.mahl@brunel.ac.uk Michael Mueller mueller@z1wnsv.gmd.de Hector Nunez h.nunez@cs.ucl.ac.uk 4 Paul-Andre Pays paul-andre.pays@inria.fr Catherine Pierre-Radenac catherine.pierre-radenac@inria.fr Colin Robbins c.robbins@xtel.co.uk Jim Romaguera romaguera@cosine-mhs.switch.ch Marjo Rottschaefer marjo.rottschaefer@surfnet.nl Peter Sylvester sylvester@gmd.de Katy Treca treca@urec.fr Panos Tsigaridas tsigaridas@fokus.berlin.gmd.dbp.de Ton Verschuren ton.verschuren@surfnet.nl Peter Yee yee@ames.arc.nasa.gov 5