alf-hansen%vax.runit.unit.uninett@TOR.NTA.NO (Alf Hansen) (06/24/88)
==================
Minutes of the RARE WG1 7th Meeting in Bari, June 1-2 1988
==========================================================
Secretary: Hannes Lubich, ETHZ, Switzerland
Present:
Klaas Lingbeek SURFnet lingbeek@hwalhws.earn
Pedro Veiga INESC / PT pmv@inesc.riup
Serge Aumont REUNIR aumont@cicb.cicb.fr
Christian Huitema INRIA huitema@mirsa.inria.fr
Alf Hansen RARE WG1 / UNINETT alf-hansen@vax.runit.unit.uninett
Haavard Kvernelv RARE MHS Project kvernelv@vax.runit.unit.uninett
Denise Heagerty CERN denise@priam.cern
Erik Huizer SURFnet huizer@hutsur51.earn
Encarna Pastor UPM / IRIS encarna@etsitm.iris
Ingnacio Martinez IRIS martinez@dcp.iris
Hannes Lubich ETHZ / SWITCH lubich@ifi.ethz.ch
Jim Craigie JNT / UK C=gb; A=gold 400; P=uk.ac;
O=rutherford; S=craigie; G=jim
Franz Haselbacher ACONET haselbacher@edoz.tu-graz.ptt.at
Vesa Keinanen FUNET vjk@tut.fi
Tom Wade HEAnet / IE t_wade@ccvax.ucd.ie
Serge Simonet BE sci@fun-cs.uucp
Domenico Rotondi IT dicomz@ibacsata.earn
Peter Kaufmann DFN C=de; A=dbp; P=dfn; OU=zpl;
S=kaufmann
Rob Blokzijl ECFA / HEPNET k13@nikhefh.hep.nl
Marco Bonac YUNET Telefax +38 61 219 385
Antonia Ghiselli INFN ghiselli@iboinfn.bitnet /
ghiselli@vxcnaf.cern
* * * * * * *
Item 1: Administration
======================
* No additional comments to the proposed agenda.
* Corrections to the minutes of the last meeting:
Denise Heagerty indicated that point 2 of status report from
CERN, given at the last meeting, should be replaced by the
following statement: "Permission for CERN to use french PTT
services is not excluded."
The minutes were accepted with the above correction included.
* Alf Hansen reported on funding of further WG1 meetings:
The cosine specifications phase ends in June/July, so there is
no funding for the next meetings.
The EC will pay further travel expenses following the CEC
tariffs, so the rule (1 member per country + invited experts)
still holds but meetings are supposed to take place either in
Brussels or in Luxemburg, where the facilities of the CEC can
be used for the meeting.
A decision was taken to have the next meeting scheduled in
Brussels at Oct 17-18.
It was also decided that there should not be more that 3
meetings per year.
Travel expenses for this meeting can be reimbursed by sending
the filled-in form and a copy of the travel tickets to:
RARE Secretariat
Kruislaan 409
Postbus 41882
NL 1009 DB Amsterdam
* * * * * * *
Item 2: Round Table Reports
===========================
There was a common sense that there should not be a recommendation to
the RFC-822 world to delay migration to X.400 until X.400(88) is
available.
X.400(88) is expected to be available early next year.
Round table reports:
====================
(Editor's note: Remarks that refer to the naming and addressing
schemes have been summarized under item 3 and are not explicitely
mentioned under item 2.)
Switzerland:
------------
There is no RFC-987 gateway operational, the old EAN addressing is
still used. The timetable for the migration is the following:
(0) The naming and addressing scheme is fixed now.
(1) The central RFC-987 gateway at the central system will be
available within the 3. quarter of 88.
(2) The SAS that will be needed at the universities will be
evaluated and put in place within 4. quarter of 88.
(3) RFC-987 gateways on the SAS will be available between 1. and
2. quarter of 89.
(4) The old EAN addressing will be replaced by standard attribute
addressing within the 2. quarter of 89.
The mapping tables will be administered centrally.
Portugal:
---------
7 UBC-EAN installations exist, acting as central mailbox machines.
1 DFN-EAN is installed, DFN-EAN will replace the UBC-EAN installations.
The naming scheme will be changed soon, the top level domain 'riup'
will be replaced by the country code 'pt'.
At the time being, only old EAN addressing is used, beginning in
October, standard attribute addressing will be used.
Germany:
--------
The 100'th EAN system has been installed recently. EAN is available
at about 60 universities and research institutes.
Ca. 50% of those installations are still EAN V1 systems, but they
will be phased out soon.
DFN will support Brasil in installing EAN, an agreement has been
reached about 3 -4 weeks ago.
The German Bundespost offers a X.25 research network without volume
charging that is connected to the public network Datex-P.
A corresponding agreement has been reached between DFN and the DBP.
Austria:
--------
There are 14 X.400 nodes in Austria at 8 universities.
One RFC-987 gateway will be operational at the end of June.
Two other gateways are planned, one to connect to EARN (operational at
the end of June) and one to connect to EUnet (operational at the end
of September). At that time, another 5 - 10 DFN-EAN systems are
expected to be operational.
With respect to addressing, users should have a choice to use either
RFC-822 or X.400 standard attribute addressing.
A short discussion indicated that there is clearly a need for
supporting both kinds of addressing during a migration period.
Ireland:
--------
There will be no full migration until X.400(88) and X.500
implementations are available. A national RFC-987 gateway will be
operational before the end of this year.
The top level domain will be changed from 'irl' to 'ie'.
Better connectivity to Eurokom users can be obtained. Users within
Eurokom can be addressed as <user@eurokom.ucd.ie>
In a short dicussion, the question was raised whether the end user
should be dealing with O/R-addresses, i.e. whether the user needs
basic knowledge about X.400. No conclusion was reached.
ECFA:
-----
A detailed presentation is given later by the national member bodies.
Netherlands:
------------
5 institutes are involved in a EAN V1 experimental network. There are
no 'real' users on that network, however. This experiment will be
finished in September.
There are plans to install a RFC-987 gateway.
There will be a X.25 subnetwork for SURFnet, based on the 84 version
of X.25. This subnetwork will have no volume charging and will be
connected to the public network.
France:
-------
There are no EAN V1 systems in France, only attribute addressing is
used, RFC-987 gateways (based on mailway) are available.
There exist all kinds of User Agents and mail systems in France.
There are 3 X.400 networks, the public Atlas system, the aristote
network and the reunir network. The Atlas system is not much used
by now, whereas the aristote network has many users. The reunir
network does not have any 'real' users by now.
An EARN gateway is needed, by now the well known entry point for
this service is the French uucp backbone, which is linked to the
RFC-987 gateway. This means that X.400 messages to EARN will be
routed via the UUCP backbone as an intermediate solution.
It is an identified goal to have one RFC-987 gateway per local
network but central maintainance and distributing of the gateway
tables.
Yugoslavia:
-----------
It is intended to install EAN V2 (UBC) by the end of this year. As
long as there is no mail system available, remote mailbox access is
used to communicate with RARE MHS.
License problems due to the COCOM restrictions have been solved finally.
Spain:
------
There are 20 MTA's running UBC-EAN, mainly used as central mailbox
servers that are accessed by XXX services.
Also MRX 400 and Data General X.400 installations are available,
X.400 products by IBM and HP are currently under test.
It is planned to install DFN-EAN to provide full connectivity.
A SUN-based X.400-EUnet gateway is existing, a DECnet gateway to
connect to HEPnet is planned. There are also plans to have a X.400
gateway to the Data General network.
A gateway to EARN is planned either on a VM machine or on VAX/VMS.
The top level domain 'es' has been registered and a new naming and
addressing scheme has been defined (see item 3).
Finland:
--------
There are 6 EAN installations and there is an operational gateway
from EAN to RFC-822.
A RFC-987 gateway is planned as soon as the mailway software is
available.
At the time being there are tests with 2 pilot public services.
Belgium:
--------
There is one EAN installation, that still needs to be connected to the
UBC-X.25 implementation. The installation is expected to be
operational and the end of June.
A naming and addressing scheme is currectly dicussed.
United Kingdom:
---------------
There are about 1000 Janet sites, that are connected to the 'old'
EAN by a gateway (ean-relay).
A X.400-relay is under development. It will contain the following
functionality:
* X.400(84) / X.25(80) expected to be operational within 4. quarter 88
* X.400(84) / connection-oriented network service on top of X.25(84)
this service might be only locally available
* X.400(88) / X.410-RTS over X.25(84) avail. middle of 89
* X.400(88) / Normal Mode RTS over X.25(84) avail. middle of 89
All four modes will be supported by the X.400-relay.
For addressing purposes, only standard attributes will be used.
The ean-relay will be phased out within 1. quarter 89, the Janet
sites will change to ISO 10021 / Normal Mode RTS which corresponds
to X.400(88) / Normal Mode RTS at the X.400-relay.
The top level domain for the British X.400 network will be changed
to correspond to the 'gb' country code.
X.400-relay will be the well known entry point for the domain 'gb'.
There will be a leased-line-based X.25 link between the UK and the
USA, which will carry Grey Book over SMTP over TCP/IP over X25.
It is also planned to run X.400 over this link.
The link can be possibly shared by other members of the RARE MHS
Project, as soon as the funding rules are defined.
The line will be installed in summer, DFN will join into this
activity and will work on the details.
Mail to New Zealand (NZ) can be relayed via the UK, since NZ runs Grey
Book via ean-relay, however, this has not been officially announced
by John Seymour yet.
It was mentioned that also DFN can relay messages to NZ via Australia.
CERN:
-----
CERN has tried to register 'cern' as a top level domain at the NIC
but has failed to do so. The proposal of the NIC to register CERN
within the 'org' top level domain has been rejected by CERN.
In the meantime 'cern' will remain a valid top level domain.
Both Switzerland and France agreed on acting as a well known entry
point for CERN, so connectivity from/to CERN will not be affected.
(Editor's note: At the time of writing, rumours say that a top level
domain for international organizations has been defined. This might
affect further discussions at CERN.)
CERN plans to have a RFC-987 gateway (mailway) operational at the
end of this year, however, inside CERN, RFC-822 will remain the
preferred mail protocol. No pressure will be put onto the CERN users
to change their addressing scheme.
A Norsk Data X.400 system that is expected to be operational at the
end of this year will remain the only real X.400 implementation at CERN.
Italy:
------
WAN protocols used in Italy today include
X.25
TCP/IP
SNA
DECNET
EARN
where DECNET and EARN are the mail protocols used.
There are several connections to:
ARPA/Internet
EARN/BITNET
EUnet
HEPnet, SPAN
4 - 5 X.400 entry points have been defined at several locations,
using both EAN and MRX 400. The UA up to now is VMSmail, but a new
UA is planned on top of 'all-in-one'.
One RFC-987 gateway is planned.
There are 2 EARN / EAN gateways (using PDMF) but are not yet
connected to RARE MHS.
Osiride is connected to RARE MHS but will disappear due to a new
naming scheme (see item 3).
Norway:
-------
About 20 nodes (having about 1200 users) form the Uninett X.400 MHS.
Using a non-RFC-987 gateway, uninett is connected to 4 EARN sites.
uninett is directly connected to the RARE MHS.
A RFC-987 gateway (mailway) is planned to connect to both the EUnet
backbone and about 10 - 20 ARPA nodes.
At the middle of this June, there will be a formal decision taken to
move from the top level domain 'uninett' to 'no'.
* * * * * * *
Item 3: COSINE
==============
Reports on the status of the work items to be covered by members of WG1:
T.345 on X.400 Products (Peter Kaufmann):
=====-------------------------------------
The information has been made available, the task is finished,
however there will be an update in summer, since new products emerge.
T.43 on X.400 Protocol Profiles (Alf Hansen):
====-----------------------------------------
Since this is subdivided into two studies, T.43 only means a summary
of S.431 and S.432 which will be completed if both studies are finished.
S.431 on X.400 Service Requirements (Christian Huitema):
=====---------------------------------------------------
The study is finished, the review is done.
S.432 on X.400 User Interface Requirements (Sandy Shore):
=====----------------------------------------------------
The study is almost completed and is currently reviewed by
James Hutton. Hannes Lubich will do a second review.
T.623 on Performance Measurements of Public X.25 Services (Alf Hansen):
=====------------------------------------------------------------------
This work item has been passed to Haavard Kvernelv.
Since it is difficult to gather detailed information, the document has
been delivered to COSINE as is. Although the COSINE task is
finished, there is a need to get more and more detailed information.
Logging of error codes has been identified as a first step in
getting more detailed information.
T.64 on Public X.400 Services (Alf Hansen):
====---------------------------------------
The information has been distributed already. The task is almost
finished. There will be an update of the delivered document, since
additional information is now available.
T.711 on MHS Directories (Christian Huitema):
=====----------------------------------------
The results have been delivered to RARE WG3 and will be included
in T.71.
S.731 on Charging and Accounting in MHS (Peter Kaufmann):
=====----------------------------------------------------
The study is finished and has been reviewed already.
T.741 on MHS Transport Services (Alf Hansen):
=====----------------------------------------
The study is finished and has been delivered.
S.77 on Convertors (Steve Kille):
====-----------------------------
The study is not yet ready and will be completed in June. The review
will be done by Peter Kaufmann.
T.791 on MHS Convertors (Denise Heagerty):
=====-------------------------------------
This study has been changed to be a task. The task is finished, the
review has been done as well.
T.82 on X.400 Migration strategies (Peter Kaufmann):
====------------------------------------------------
The task is subdivided into 3 tasks. T.82 is expected to be finished
in June.
T.821 on X.400 CEN/CENELEC Migration (Peter Kaufmann):
=====-------------------------------------------------
to be finished in June.
T.822 on X.400(88) Migration (Jim Craigie):
=====--------------------------------------
to be finished in June.
T.823 on Migration of non-X.400 networks (Peter Kaufmann):
=====-----------------------------------------------------
to be finished in June.
Report from COSINE Working Party B:
===================================
Working party B consists of members from RARE WG1, EARN, HEPNET and
EUnet.
A meeting has taken place at the last RARE networkshop in Les
Diablerets with Mr Tindemans (COSINE Policy Group). The decision has
been taken that James Hutton will chair WP B instead of Daniel
Karrenberg.
WP B has started to discuss requirements for a common European mail
gateway to the USA and is expected to make a proposal.
On a second meeting in Les Diablerets requirements for multinational
gateway projects have been discussed. Minutes of this meeting are
available on request.
A couple of requirements have already been defined:
- RFC-987 conformance
- reliable link to X.25
- all naming schemes handled properly
- good connections to European infrastructure
- working accounting scheme
- full connectivity, i.e. every user in Europe should be able
to reach every user in the USA and vice versa.
The meeting also revealed differences on serveral points, including
- funding
- management
- support
Those points are for further study.
In general, it was stated that the Europe/USA gateway will also be
available for inter-european use (EARN, EUnet, RARE MHS, ...).
James Hutton will organize the next meeting in June to discuss
further details.
Additional Information:
=======================
EARN:
-----
EARN will probably accept the offer by Northern Telecom to get
4 X.25 switches and additonal services / equipment.
DEC offered computer facilities and a leased line to NSFnet but
will only run X.400 over that line.
In this case, the USA will run a X.400 / NSFnet gateway and
Europe will have to run a X.400 / EARN gateway.
It might be useful to push NSFnet to offer gateway functionality
to DECNET in the USA as well.
JANET:
------
Janet is realizing a link from the UK to NSFnet.
The funding will have to be discussed if any other countries
will use this link but in principle, the link is open to all
countries. DFN is actively participating in this activity.
Possible funding by COSINE or RARE will have to be discussed.
Several related points were discussed:
- Will there be only X.400 on that link or will
additional protocols be supported?
- Who decides on the protocols used ? COA ?
- Will there be just one gateway or one gateway
per network ?
- Will RARE WG1 coordinate all academic networks or
just the X.400-based services?
A statement was made by WG1 that every user group will specify
it's requirements and leave it to the more political bodies to
decide how much they will fund.
On a technical level, it was recognized that the gateway should
be available within this year, but if COSINE or CEC should
fund it, there would be a major delay.
It was agreed that countries willing to use the gateway should
contact Bob Cooper to have a bilateral agreement.
DFN will offer an inter-european RFC-987 gateway for all
countries which are not able to run an RFC-987 gateway or need
such a gateway only for a very small period of time. Peter
Kaufmann is the contact person.
CERN expressed it's interest in hosting a joint mail gateway
to connect the European mail networks to each other and to
the USA networks.
* * * * * * *
Item 4: Naming and Addressing
=============================
It was pointed out that the discussion should focus on addresses
only and that naming issues should not be covered.
Also, a common notation for writing down a X.400 address (i.e. on a
business card) was defined, using Ruediger Grimm's notation in his
paper on a minimum profile for RFC-987. A X.400 address will
be written down using "the natural ASN.1 order", i.e. starting with
the country and working towards the least significant entry, thus
fixing an order of significance for the organizational units as well.
It was discussed whether RARE WG1 should just exchange information
or whether it should discuss the information and try to find an
agreement. Different proposals were made but no conclusion was reached
on that point.
Since there is already a number of countries having defined
RFC-987 mapping tables (although the gateway itself might not be
operational yet) a second round table presentation was made to
present the national viewpoints on
a) what standard attributes will be used for addressing;
b) how a mapping between RFC-822 and X.400 should be done;
c) how foreign network acronyms that are not valid country
codes will be handled in that mapping.
CERN:
=====
A draft proposal for CERN mail addressing strategy was presented and
was distributed to all participants.
Since CERN has no valid top level domain (i.e. country code) in the
X.400 world up to now, it is proposed that CERN is handled as a
PRMD, using the Swiss ADMD and country code.
Thus, CERN proposed to use the following standard attributes:
g=givenname; s=surname; ou=group; o=division; p=cern; a=arcom; c=ch
An example address using this scheme would be:
g=denise; s=heagerty; ou=cs; o=dd; p=cern; a=arcom; c=ch
The mapping from X.400 to RFC-822 is proposed as follows:
p=cern; a=arcom; c=ch # cern
p=cern; a=; c=ch # cern
The mapping from RFC-822 to X.400 is proposed as follows:
cern # p=cern; a=arcom; c=ch
Foreign network acronyms like 'bitnet' should be mapped to/from the
organsiation attribute. The mapping from X.400 to RFC-822 is proposed
as follows:
o=bitnet; p=cern; a=arcom; c=ch # bitnet
The mapping from RFC-822 to X.400 is proposed as follows:
bitnet # o=bitnet; p=cern; a=arcom; c=ch
Finland:
========
It was proposed to use the following standard attributes and values:
c=fi;
a=funet;
p=<university/institute>;
o=<university/institute>;
g=givenname;
s=surname;
In some cases, the PRMD entry will not be used,as in
c=fi;
a=funet;
o=tut;
s=keinanen;
g=vesa;
However, there will also be cases where the PRMD value will be used:
c=fi;
a=funet;
p=opmuakcom; (Spelling?)
o=tut;
s=keinanen
g=vesa
The mapping to RFC-822 addressing follows the scheme:
g.s@(ou).o.(p).(a).c
resulting in addresses like vesa.keinanen@tut.fi
or vesa.keinanen@tut.opmuakcom.fi
The mapping of RFC-822 addresses to X.400 addresses is proposed as
follows:
jtv@cs.tut.fi
is mapped to
c=fi;
a=funet;
o=tut;
ou=cs;
s=jtv;
Foreign network acronyms are mapped to the PRMD attribute, e.g.
user@host.bitnet
is mapped to
c=fi;
a=funet;
p=bitnet;
o=host;
s=user;
Italy:
======
Since there is no public service provider, the ADMD is not used.
All decisions are valid for the research community only.
The following attributes will be used for X.400 addressing:
Country, PRMD, O, OU, S:
c=it;
a=;
p=<INFN | any other organizations>;
o=<might be empty>;
ou=<used if needed>;
s=<surname>;
The exact usage of the attributes PRMD, O and OU depends on local
decisions.
No statement was made to cover the handling of foreign network
acronyms such as 'bitnet' in the mapping process.
UK:
===
The attributes Country, ADMD, PRMD, O, OU, S and G will be used.
RFC-822 addresses like
user@rutherford.ac.uk
will be mapped to X.400 attributes as follows:
c=gb;
a=gold 400; (yes, the blank is intended)
p=uk.ac;
o=rutherford;
s=user;
Foreign network acronyms like 'bitnet' will be mapped using domain
defined attributes, if there is no mapping specified in the routing
tables. The reason for the usage of DDA's is that GB is not willing
to route traffic e.g. to bitnet that does not origin within the 'gb'
domain.
A proposal was made to coordinate routing tables in a way that e.g.
mail to bitnet will always be routed to the nearest bitnet gateway
and to use the common European gateway as the default gateway.
This proposal was commonly accepted but it's realization was left
for futher study. At the time being, replies to a message will be sent
to the gateway the original mail came from.
Netherlands:
============
A proposal concerning naming and addressing in SURFnet was distributed
to all participants.
The attributes Country, PRMD, O, OU (up to 2) and personal name will
be used in the following way:
c=nl;
a=;
p=SURF;
o=<university/institute>;
ou1=<faculty/division>;
ou2=<group/laboratory>;
pn=<personal name>;
The mapping to RFC-822 follows the scheme:
pn@(ou2.)(ou1.)o.c
A RFC-822 address like
jansen@meetregel.wtb.tudelft.nl
will thus be mapped to
c=nl; a=; p=SURF; o=tudelft; ou2=wtb; ou1=meetregel; pn=jansen
Foreign network acronyms like 'bitnet' will be handled using DDA's.
Germany:
========
The attributes Country, ADMD, PRMD, O, OU and S will be used in the
following way:
c=de;
a=dbp;
p=<tu-berlin | mpg | ...>;
o=<mpg-mainz | ...>; (for universities usually empty)
ou=<physik | ...>;
s=<surname>;
Thus, a RFC-822 address like
name@physik.tu-berlin.dbp.de
will be mapped to
c=de;
a=dbp;
p=tu-berlin;
ou=physik;
s=name;
Foreign network acronyms will be mapped to the PRMD attribute:
c=de;
a=dbp;
p=<bitnet | uucp | riup | ...>;
Austria:
========
The attributes Country, ADMD, PRMD, O, OU and personal name will be
used in the following way:
c=at;
a=ptt;
p=<university/organization>;
o=<institute>;
ou=<group>;
pn=<personal name>;
Thus the mapping between RFC-822 addresses and X.400 addresses is
described by the following RFC-987 table entries:
ptt.at # a=ptt; c=at
and
a=ptt; c=at # ptt.at
Foreign network acronyms are handled by mapping to the PRMD value
and by leaving the ADMD value empty, e.g.:
at # a=; c=at (EUnet and EARN hosts in Austria)
bitnet # p=bitnet; a=; c=at
uucp # p=uucp; a=; c=at
The O attribute value will always be present.
Portugal:
=========
The attributes Country, ADMD, PRMD, O and OU will be used in the
following way (no explanation was given whether S and/or G will
be used, so S is assumed in the examples):
c=pt;
a=xdmhs;
p=<utl | ul | unl | uc | ...>;
o=<ist | ise | ...>;
ou=<deec | dm | ...>;
All values will be mapped, thus resulting in an RFC-822 address like:
user@deec.ist.utl.xdmhs.pt
being mapped to it's X.400 attribute equivalent:
c=pt;
a=xdmhs;
p=utl;
o=ist;
ou=deec;
s=user;
No statement was made concerning the handling of foreign network
acronyms like 'bitnet'.
Norway:
=======
The attributes Country, PRMD, O, OU, S and G will be used. The PRMD
will be used for the service providers as there will be more than
one (commercial) service provider in Norway. The ADMD will not be used
at all until an agreement has been reached with the PTT.
Universities will map onto the organization attribute.
The PRMD will not be mapped into a RFC-822 address, resulting in the
following scheme:
s.g@ou.o.c
Foreign network acronyms like 'bitnet' will be mapped onto the
organization attribute. In this case, 'uninett' is the PRMD entry.
Spain:
======
A paper describing the harmonization of services in IRIS was
distributed to all participants.
The attributes Country, PRMD, O, UO and S will be used in the
following way:
c=es;
a=;
p=iris;
o=<upc | ...>;
ou=<fib | ...>;
s=<surname>;
The mapping between RFC-822 addresses and X.400 addresses follows
the scheme:
s@(ou)...(ou).org.iris.es
Foreign network acronyms like 'bitnet' will be mapped onto the
organization attribute, e.g.:
ruiz@esanvx.decnet
will be mapped to:
c=es;
a=;
p=iris;
o=decnet;
ou=esanvx;
s=ruiz;
Switzerland:
============
The Swiss naming and addressing scheme was presented at the last
RARE networkshop in Les Diablerets. An updated written description
was distributed to all participants.
The attributes Country, ADMD, PRMD, O, OU, S and G will be used in
the following way:
c=ch;
a=arcom;
p=<university name>;
o=<institute name>;
ou=<subdivision name>; (not more than 2)
s=<last name>;
g=<first name>;
OU and G values are optional.
The mapping from RFC-822 addresses to X.400 addresses is
described by the following table entries:
ch # c=ch; a=arcom
arcom.ch # c=ch; a=arcom
When mapping X.400 addresses to RFC-822 addresses, the ADMD is not
mapped, however, even RFC-822 addresses that incorporate the ADMD
value are accepted and rewritten correctly.
The mapping from X.400 addresses to RFC-822 addresses is
described by the following table entry:
a=arcom; c=ch # ch
Foreign network acronyms like 'bitnet' are mapped onto the
organization attribute. In this case 'switch' is used as the PRMD
attribute value.
bitnet # c=ch; a=arcom; p=switch; o=bitnet
The reverse mapping is expressed by the corresponding table entry:
c=ch; a=arcom; p=switch; o=bitnet # bitnet
France:
=======
The attributes Country, ADMD, PRMD, O, OU, S and G will be used in
the following way:
c=fr;
a=ptt; (will be changed to 'atlas')
p=<given by atlas, identifies an atlas subscription;
the value might be an organization, a site, a service for
serveral organizations, etc., due to economic reasons>;
o=<organization name>;
ou=<subdivision of organization, host name, etc.>;
s=<surname>;
g=<given name>; (optional but recommended)
For mapping X.400 addresses to RFC-822 addresses, Country, O, OU and
S will be used, but additional usage of ADMD and/or PRMD will also
work.
Hence and
c=fr; c=fr;
a=; a=ptt;
p=; p=inria;
o=inria; o=inria;
ou=mirsa; ou=mirsa;
s=huitema; s=huitema;
will both be mapped onto
huitema@mirsa.inria.fr
Foreign network acronyms like 'bitnet' will be mapped using DDA's,
using the PRMD attribute value to indicate the gateway.
Belgium:
========
Belgium will probably use Country, ADMD, PRMD, O and OU but there is
nothing finally decided yet (no statement was made concerning the
usage of S and/or G):
c=be;
a=rtt;
p=<university name>;
o=<usage not yet defined>;
ou=<to be used>;
When mapping X.400 addresses to RFC-822 addresses, all attribute
values will be mapped. A RFC-822 address will carry the ADMD value, if
it originated in the X.400 domain, hence a RFC-822 address without
the 'rtt' subdomain will be assumed to have been originated in a
RFC-822 domain.
Yugoslavia:
===========
Since there is no X.400 installation available, nothing has been
decided yet.
Ireland:
========
Since a RFC-987 gateway is planned, a mapping has to be defined,
although nothing has been decided yet.
RFC-987 Gateways:
=================
As mentioned in the agenda under item 4, some countries will
introduce the X.400(84) subsystem without having any significant
operational EAN-V1 subsystem running, causing the problem of missing
connectivity if they are not willing/able to install and run a
RFC-987 gateway as well.
The question was raised whether RARE MHS could accept such 'holes'
or whether the connectivity could be reached by other means.
It was agreed that the problem will solve itself soon, since these
'holes' are expected to disappear in the migration process.
In addition, DFN offers to keep it's EAN-V1 gateway operational for
all countries that will need such functionality. It was pointed out
that the mailway software offers such functionality as well.
If any country needs to use the DFN (or any other external) gateway,
there will be a bilateral agreement between the service user and
the service provider. No additional actions should be taken by RARE MHS.
* * * * * * *
Item 5: RARE MHS Project
========================
Documentation:
--------------
It was reported that there are problems to get instant information
from the country representatives since the local network administrators
do not have the time to reply as fast as it would be necessary.
The documentation is now fairly complete, although there is still
information missing from France and the UK.
In a short discussion it was pointed out that it could be very
helpful to have some additonal information about the RARE MHS
member networks (reachable nodes, organizations, universities,
contact persons, etc.).
The granularity of the information should be such that at least
organizations (including contact persons) should be listed.
The actual format of the documentation is not feasable, due to it's
size and lack of machine readability. There is a common need to map
the documentation to local databases.
There are several format proposals available (EUnet, BITNET, Fr, UK)
that could be used for defining a data format for the RARE MHS
documentation. It is agreed that it is part of the RARE MHS project
to define a format. It is also indicated that a format should
include the ability to send/process updates to the documentation.
Since X.500 directory service implementations are expected to be
available within one year, no big efforts should be made, however.
An intermediate solution has been identified by including the
information into the THORN project, however it is agreed that this
will not mean an active participation in the THORN project.
This has the advantage that the documentation, once it is converted
into the THORN database, is in a machine readable format, and can
easily be converted to a different (X.500-) representation later on.
Gateway Tables:
---------------
Haavard Kvernelv will gather all available RFC-987 gateway tables.
X.400 Products:
---------------
There should be a list of operational products in the member
countries available to MHS 'newcomers' to indicate where they can
reach experienced people.
Functional Standards:
---------------------
RARE MHS should state the usability of available functional standards.
Haavard Kvernenv will gather this information from the member
organizations.
Error Statistics:
-----------------
Error statistics of the public X.25 carriers should be collected for
COSINE. Input is required on available software for logging of traffic,
PTT-related problems etc. All member organizations are asked to
monitor their traffic and transmission problems and to report the
results to RARE MHS.
* * * * * * *
Item 6: X.400 /84 --> /88
=========================
Jim Craigie gave a tutorial about the status of X.400(88). Although
this report is also a part of COSINE task 822, a short summary will
be given here.
Status of the Documents:
------------------------
CCITT: Message Handling Systems
ISO: Information Processing Systems, Text Communication, MOTIS
ISO CCITT
--- -----
10021-1 X.400 System and Service Overview
10021-2 X.402 General Architecture
10021-3 X.407 Abstract Service Definition Conventions
10021-4 X.411 Message Transfer Service
Abstract Service Definitions and Procedures
10021-5 X.413 Message Store Abstract Service Definition
10021-6 X.419 Protocol Specifications
10021-7 X.420 Interpersonal Messaging System
-- X.403 Conformance Testing (1984)
-- X.408 Encoded Information Type Conversion Rules
ISO 10021-1 to 10021-4 and ISO 10021-6 to 10021-7 are out for a 3
months ballot, whereas ISO 10021-5 is out for a 6 months ballot.
Final approvement is expected for October/November 1988, printing
and distribuiton will take place a few months later.
The latest draft version of ISO 10021 can be obtained in either A4
or A5 format by sending e-mail to <J.Dyer@rutherford.ac.uk>.
P1 Extensions:
--------------
1) Distribution Lists
A distribution list mechanism has been included in the
standard. Lists can be nested, there is an expansion
history to prevent loops (i.e. each list checks the
expansion history and stops processing the message if the
list name is already in the expansion history). Each sender
to a list has to be authorized, in case of nested lists,
the sending list has to be authorized to send the message
to the next list.
Reports go back on the distribution list chain and can
be sent to the owner of the list or to the previous list
until it eventually reaches the originator. Reports can
as well be discarded and not sent back at any point in the
distribution list chain.
2) Use of Directory
To support forthcoming directory services by making a
distinction between names and addresses, "O/R Names" have
been renamed to "O/R Addresses".
Furtheron the "CommonName" has been defined, to identify
roles, lists etc., since SurName and GivenName normally
refer to persons.
3) Redirection
In the 1984 version of the standard, the originator of a
message was allowed to set the "Alternate_Recipient" flag.
In the 1988 version, this mechanism has been expanded in
such a way, that the originator may now specify the
address of the alternate recipient. In addition, the
recipient can reassign a message, but the originator may
explicitely forbid the reassignment of a message by
setting the "Recipient_Reassign_Prohibition" flag.
4) Size Constraints
Several size restrictions have been harmonized between
CCITT and ISO.
5) Security
Several new mechanisms to improve security have been
added to the standard. New features include:
- message origin authentification
- report origin authentification
- probe origin authentification
- proof of delivery
- proof of submission
- content integrity
- content confidentiality
- message flow confidentiality
- message sequence confidentiality
- origin non-repudiation
- delivery non-repudiation
- submission non-repudiation
- message security labelling
- secure access management
P2 Extensions:
--------------
1) Language
The language of the body part is now indicated.
2) Incomplete Copy
If the message is incomplete, this is now indicated.
3) Extension Body Part Types
The type of the body part of a message (ODA, MSWord, etc.)
can be specified using ASN.1 body part identifiers.
4) Header Extension Mechanism
There are 'critical' flags defined in P1 for submission,
transfer and delivery of a message. This extension is
defined by integer values in CCITT P1 and object
identifiers in P2, the encoding is an open question
between ISO and CCITT.
There are problems when sending from a '84 system to a '88
system, since all messages are valid but not all users in
the '88 system can be addressed (use of CommonName,
encoding, etc.).
In order to gain connectivity when sending from a '88
system to a '84 system, a set of rules for downgrading a
message is defined. The message is discarded or rejected,
however, if it has been marked as critical in P1.
There is a list of 28 critical P1 extensions for transfer or
delivery that will be included in COSINE task 822. In
summary, 20 out of those 28 extensions can not be
downgraded. Of those 20 critical cases, 8 deal with
physical delivery and 7 with security.
There is no definition for downgrading P2, which, in
general, means that '84 transit domains should be avoided.
Although this is not required in the ISO standard, some '88
systems will also be able to talk to '84 systems, but '84
interworking will need special capabilities on the '88 MTA.
* * * * * * *
Item 7: External Contacts
=========================
CEN/CENELEC
-----------
Jim Craigie reported on the last CEN/CENELEC meeting. Two functional
standards will be produced, the first one dealing with MTA/MTA
connection (P1, P2 protocol) and the second dealing with the message
store (P7 protocol).
Work on the first functional standard has already started.
It has been agreed that there will be two different levels, the
first describing the absolute minimum, the second describing a more
usable level. A questionaire has been sent out concerning the
functionality of the second level and possible extensions.
A first draft is expected to be ready in July.
The second functional standard is expected to be available at the
end of '89, while NBS is expected to issue a P7 profile within 1988
and a P1 profile next year.
UBC/EAN
-------
DFN is holding a license for UBC-EAN, other X.400 products will be
installed as well.
There will also be EAN installations in the USA, one site will be
Livermore laboratories.
* * * * * * *
Item 8: Other Business and Next Meeting
=======================================
The next meeting will take place on Oct., 17/18 in Brussels, we will
probably start on the 17'th at lunchtime and end on the 18'th before
4 pm.
The meeting after that will probably take place in Lissabon but if
there is no funding, we will meet in Brussels.
The date of this meeting has been fixed to Feb., 16/17 1989
* * * * * * *
Appendix A: Distributed Material:
=================================
The following written material was distributed at the meeting:
* CERN: CERN's interest in a Europe - USA Joint Mail Gateway
distributed by Denise Heagerty
* CERN: Draft Proposed CERN Mail Addressing Strategy
distributed by Denise Heagerty
* SURFnet: Naming and Addressing in SURFnet
distributed by Erik Huizer
* IRIS: Harmonization of Services in IRIS
distributed by Ingnacio Martinez / Encarna Pastor
* SWITCH: Naming and Addressing in SWITCHmail
distributed by Hannes Lubich
* * * * * * *
* * * * * * *