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