CURRENT_MEETING_REPORT_
Reported by Kevin Jordan/CDC
X400OPS Minutes
Welcome.
There were no additional comments against the St. Louis meeting
Minutes.
The IETF X.400 Operations Working Group.
Alf Hansen and Rob Hagens are now Co-Chairs of the Working Group. Alf
is returning home to Norway. The old X.400 Working Group has been
merged with the X.400 Operations Working Group. The most significant
work item completed by the old X.400 Working Group was an RFC describing
how to use DNS to store RFC1148 mapping information. The status of this
RFC is that it is awaiting proof of concept through implementation.
Because the two X.400 Working Groups have merged, the Working Group
Charter will be updated to add a new goal: the Working Group will
attempt to drive X.400 deployment in the Internet.
The X.400 Operational Requirements RFC was originally scheduled to be
available for comment in July. This schedule needs to be revised
because a lot of work is left to be done (especially considering the
comments and resolutions discussed in Atlanta).
The following questions were asked: ``Is XNREN a U.S. or an
international PRMD? How would an organization outside of the U.S.
join?''
Alf attempted to provide an answer by indicating that the IETF should
find a way to register XNREN as a PRMD in each country. It is not clear
exactly how this would be accomplished, but extensive cooperation from
the international Internet community is required.
Status of the document, ``An X.400 Internet Strategy''.
Work on the document continues. It is slightly behind schedule.
Roundtable presentation of current X.400 service status.
At this point, the Working Group members who are currently operating
X.400 services described the status of those services:
SURFNet (Netherlands) The SURFNet operations team is currently
working to improve the robustness of the service by
providing live backups for key service elements, i.e.,
redundant WEP's and RFC987 gateways.
An international agreement is needed on how to define
1
backup WEP's with associated priorities (like the MX
concept in SMTP and DNS) so that MTA's can try
alternate backup connections. Note: RARE WG1 has
begun work on this concept.
SURFnet currently serves about 800 active X.400 users,
and the number of users is growing rapidly.
X.400 implementations for Mac's and PC's are being
evaluated, as are X.400 gateway products for Mac/PC
LANS (e.g. cc:Mail, Banyan).
SURFNet Observation: Most currently available X.400
user interfaces are still quite primitive.
COSINE Cooperation for OSI Networking in Europe. COSINE is a
program funded by a number of European Governments
(basically the European Community plus European Free
Trade Association countries) plus the Commission of
European Communities. Broadly, the mission is to
provide OSI based services for the European research
community. The prime contractor entrusted to fulfill
this mission is RARE.
COSINE includes:
RARE Reseaux Associe pour la Recherche Europeenne
EEMA European Electronic Mail Association EEMA is an
association whose membership is comprised of a number
of European organizations, some very large (almost
exclusively non R&D based). They come together to
discuss issues related to electronic messaging in
Europe. RARE/COSINE decided to become a member of
EEMA, with a view to feed back the experiences learned
by the RARE/COSINE MHS services into industry, (i.e.,
act as an experience pool), To make the views of the
COSINE user community felt in this forum.
Y-Net OSI Services for ESPRIT researchers Y-NET is a
project with its primary aim being to provide OSI based
services to European Community SMEs (Small and Medium
sized Enterprises) involved in the ESPRIT program.
COSINE MHS is mandated to coordinate with Y-NET. An aim
of COSINE MHS is to provide a seamless service between
the Y-NET and COSINE MHS user communities.
EurOpen
COSINE-MHS is a project which was chartered to drive deployment of
X.400 in the European research community. Transport
service stacks include: TP0/CONS/X.25/LAPB,
TP0/CONS/X.25/LLC2, TP0/RFC1006/TCP, TP4/CLNS.
X.400 '84 is used universally within the COSINE-MHS
community. Some organizations are experimenting with
X.400 '88, but there is no wide spread use of '88 yet.
The European public service providers (the PTT's) offer
'84 service only.
The COSINE-MHS project is currently comprised of
between 20 and 25 WEP's. Connectivity between WEP's is
2
not universal. Even with this relatively small number
of WEP's, the amount of static configuration
information which must be maintained and coordinated is
approaching an unmanageable level. There is a very
urgent need for dynamic configuration management via
X.500 directory services and/or DNS.
Some countries consider COSINE-MHS to be an operational
service, and some countries consider it to be a pilot
service. Consequently, varying degrees of support and
administration are provided.
A universal gateway service, COSINE-GW, is being
implemented in Trieste, Italy. This gateway will
provide connectivity between practically all commonly
used electronic mail networks including: X.400,
RFC822, BITNet/EARN, HEPNET (Mail-11), and SPAN
(Mail-11). Connectivity with XNREN is also being
implemented.
SWITCH (Switzerland) SWITCH has one main WEP which provides
access to the Swiss research community. This main WEP
has ADMD connectivity. SWITCH serves about 8000 real
end users. About 50 academic and research
organizations are connected. Five commercial
organizations are connected. Commercial organizations
must connect as independent PRMD's.
UK Two main X.400 services operate within the UK
academic/research community: EAN and MHS-Relay
(PP-based). Connectivity with 3 ADMD's is provided.
Most UK sites are operating X.400 '84 services, but 3
sites are experimenting with '88 internally.
GARR (Italy) GARR is registered as an official Italian ADMD,
but it primarily services the academic/research
community and is not a public service provider. GARR
is connected with 2 public service ADMD's in Italy.
GARR's potential user community numbers between 10,000
and 100,000 people.
GARR provides one principal access point (WEP) to
COSINE. Backup WEP's are planned, pending international
agreements on how to define and configure prioritized
alternative MTA's for X.400 destinations.
X.400 '88 deployment is being considered, but GARR
currently has no time table in place for deployment.
ARC (NASA-Ames Research Center) The primary WEP for ARC was
recently transferred from a microVAX to a SUN. While
the transfer was in progress, connectivity to ARC was
lost. ARC is working on connectivity to SPRINT. A fax
gateway is planned. ARC is considered an experimental
rather than an operational X.400 mail service.
CDC Control Data operates its on PRMD named CDC. Control
Data has a connection to XNREN via Internet and is also
3
a subscriber to ADMD ATTMail. CDC is connected to
ATTMail via AT&T's public X.25 network named Accunet.
Internally, CDC operates an X.400 network which
currently interconnects 3 principal corporate
locations: Arden Hills, Minnesota; Bloomington,
Minnesota; and Santa Clara, California. It is
estimated that well over 1000 X.400 messages per day
are exchanged between and within these three locations.
The number of users served is in the hundreds.
CDC has produced two main X.400 implementations. These
are marketed as Control Data products, and they are
also used very heavily within the company. One of the
implementations, named MHS/4000, runs on the Control
Data 4000 series of computer systems (based on the MIPS
RISC chipset and running CDC's variant of UNIX named
EP/IX). The other implementation, named Mail/VE, runs
on the Control Data CYBER 180 series of mainframe
computer systems under the NOS/VE operating system.
Several of CDC's customers in Europe (particularly
Germany) are taking advantage of CDC's connection with
XNREN. They are able to exchange true X.400 mail
between their sites and Customer Support analysts at
CDC in Minnesota. One of the customers even sends
periodic X.400 ``pings'' from his X.400 mailbox in
Germany to an autoforwarding mailbox at CDC in
Minnesota. The autoforwarding mailbox forwards mail
back to his mailbox in Germany. This allows him to
verify that the international X.400 network is fully
operational (between Germany and Minnesota at least).
CDC has implemented an X.400-based fax gateway and is
currently using it internally. This gateway will be
released as a CDC product in the Fall. The gateway can
accept messages containing IA5-Text, Unidentified (aka
Bilateral), and G3-Fax body parts. IA5-Text body parts
can contain plain text, PostScript, uuencoded digital
imagery, and digital imagery encoded using Macintosh
BinHex format. TIFF, GIF, PICT, MacPaint, XBM, XWD,
PBM, PPM, PGM, and Sun Raster digital image formats are
recognized. Unidentified type body parts may also
contain any of these formats (without having to be
uuencoded or BinHex encoded). The gateway provides
access controls and accounting, it honors deferred
delivery requests, and it generates X.400 delivery
reports. It also allows the network administrator to
design customized cover sheets. It can receive as well
as send faxes, and, of course, it can serve non-X.400
users across an RFC987 gateway.
ESNet ESNet is implementing X.400 connectivity with XNREN.
Internally, ESNet is providing pilot services to energy
research labs. As ESNet must meet U.S. GOSIP
requirements, the internal ESNet OSI backbone will be
4
based on TP4/CLNS. The potential ESNet user community
is about 4500 people.
CDNNet (Canada) CDNNet is topologically organized as a star.
A WEP and RFC987 gateway are located at the center of
the star. About 40 organizations, Canada-wide, are
connected to CDNNet. CDNNet has connections with XNREN
and Envoy. CDNNet is considering becoming an ADMD.
CDNNet participates in support of EAN. The number of
X.400 end users served by CDNNet numbers in the
thousands.
MITRE MITRE's X.400 service is '84 based. MITRE's X.400
network has two main relays. One is located in
Bedford, Massachusetts, and the other is located in
Washington, D.C. Routing is hierarchical and
concentrated at the two main relays. Departmental
MTA's are configured with simple default routes to the
central relays.
MITRE's X.400 service is confined within the
corporation. MITRE does not yet exchange X.400 mail
with other organizations because MITRE has not yet
integrated the OSI protocol suite into its security
perimeter mechanisms.
The MITRE X.400 service is currently operating as a
mail backbone transport service only. X.400 mail is
not yet exchanged with end users directly, i.e. X.400
user agents have not been deployed.
X.500 (Quipu) is being used for address lookup and
distribution list expansion. The principal user agent
in use is MH 6.7 with the enhancements that support
X.500.
MITRE's current view of OSI: ``It's tough to show the
added value of OSI at this time.'' OSI products are
immature. GOSIP is incomplete. It requires only
IA5-Text support in X.400 body parts, it does not
require X.500, and it does require any sort of network
management support. The standards are incomplete. For
example, the standards do not specify standard textual
representations for host names or email addresses.
XNREN X.400 traffic passing through the main XNREN relay
steadily increases, but it is still relatively light.
In June, between 7000 and 8000 X.400 messages were
processed. Most traffic originates from X.400 and is
destined for SMTP users.
PP (release status) Steve Hardcastle-Kille provided the
following information about forthcoming releases of PP:
A beta release of PP was distributed very recently. PP
6.0 is currently scheduled for general release in
September or October. PP 6.0 will include a fax
channel. At the present time, the fax channel works in
5
the outbound direction only, but inbound should be
working soon. In addition, the fax channel is
currently implemented to interface with a fax modem
which is not currently sold in the U.S. A Mail-11
channel will become available. 88->84 downgrading will
be supported per Steve's draft RFC. The Domain table
has been revised to look like the O/R table. An
implementation of Message Store and an X Window User
Agent will become available. The X Window UA will
probably be released with PP 6.0, but its quality will
be VERY beta in that release. It will be suitable for
experimentation, but not for end user usage.
The PP API will be published. Note: this API will not
be compatible with the X/Open API for X.400, and there
are currently no plans to implement an X/Open
conformant API for PP.
Review of draft RFC, ``Requirements for X.400 PRMD's Operating in the
Internet.''
The Working Group went through the draft RFC section by section,
discussing issues and resolving them. One major outcome of the dialogue
is that the focus of the document has changed from being U.S.-centric to
being international in scope.
o Status of this Memo: It was pointed out that the format of this
section may not follow the approved wording format for Internet
RFC's.
o Introduction: It was suggested that this section does not really
introduce the reason for the existence of the document. It dives
into technical details too quickly. This section should provide
answers to the following questions:
- What is the rationale for deploying X.400 on the Internet?
- How does X.400 deployment relate to the forthcoming
enhancements to SMTP?
- Why is this document being written?
One justification for deploying X.400 on the Internet is that there
are a number of Internet-connected organizations which are
beginning to operate internal X.400 services (in compliance with
U.S. GOSIP), and it should be possible to use the Internet to
interconnect these services.
Among other things, the document should provide a boilerplate which
describes how to connect an organization to the Internet X.400
network.
6
After considerable discussion, the following conclusions were
drawn:
- We probably need to produce a separate document which clearly
lays out the rationale for deploying X.400 on the Internet.
- The document needs to be expanded such that it accommodates the
international R&D community. In particular, the document must
accommodate both of the XNREN and RARE/COSINE communities.
- Our basic goal is to foster an international X.400 service for
the Internet.
Profiles
The intent of the profile section was to document the upper layer
X.400 profiles which must be supported by participating
organizations. It was agreed that the document should merely refer
to other documents which define standardized inter/national
profiles because, in practice, existing X.400 implementations are
interoperable, and they conform to standardized inter/national
profiles.
o Management Domains: Given that the document will be revised to
accommodate international requirements, and given that a variety of
management domain schemes are already in use, this section should
describe existing practices. In particular, it should describe the
existing variety of PRMD's and ADMD's and point out that management
domain interconnection requirements will vary from one country to
the next.
Lower Layer Stack Incompatibilities
Discussion of this section prompted a long and lively dialogue
concerning what the definition of ``Internet'' truly is, whether it
is still necessary to retain the I-WEP concept, and whether it
should be a requirement that all I-WEP's and/or WEP's be capable of
direct interconnection. In the process of resolving these issues,
it was pointed out that the IAB has revised the definition of
``Internet'' as follows:
Internet is a multiprotocol community which shares a common
name service.
Given this definition, the Working Group produced the following
proposals for the definition of ``Internet X.400 Service'' or
``Internet X.400 Community''. The proposals were produced in the
order indicated below, each was discussed thoroughly, and then a
revised proposal (based on the discussion) was generated.
7
- p1: The Internet X.400 Community consists of X.400 communities
which are connected with X.400 to the international R&D X.400
community without the assistance of a third party intermediate
ADMD.
- p2: The X.400 Internet includes all sites where you can send
an X.400 e-mail and get a non/delivery report in response.
- p3: An organization is a member of the X.400 Internet
Community if it meets the connectivity requirements defined in
this RFC.
These proposals made it clear that our basic goal is to use the
Internet as a vehicle for maximizing X.400 connectivity. Given
that agreement was reached on this goal, it became obvious that we
should allow organizations to connect to the X.400 Internet using
any of the following three lower layer stacks: TP0/RFC1006/TCP,
TP0/CONS, TP4/CLNS
Furthermore, it should not be a requirement that every MTA or PRMD
directly support all three stacks, but if a particular stack is not
directly supported by a PRMD, the PRMD will need to make bilateral
agreements with other PRMD(s) in order to assure that connectivity
from all stacks is available.
The final agreed definition of ``Internet X.400 Sevice'' became:
The Internet X.400 Service includes all organizations
meeting the international requirements described in
RFCxxxx.
where RFCxxxx is an RFC which describes requirements for connecting
to the international Internet X.400 network. As mentioned above,
the lower layer protocol stacks supported by the international
Internet X.400 network are:
TP0/RFC1006/TCP, TP0/CONS, TP4/CLNS
Connection requirements include:
- An organization must support at least one of the above stacks.
- An organization must insure that it is reachable from all
stacks. An organization can achieve universal reachability by:
* Directly supporting all stacks
* Negotiating bilateral agreements with other organizations
which share a common stack and which either:
+Support a stack not common to both organizations, or
8
+Are willing to relay mail to organizations which do
support other stack(s)
Editorial note: The TP0/CONS stack should probably be
subdivided into the following two stacks: TP0/CONS/X.25/LLC2,
TP0/CONS/X.25/LAPB. These two stacks qualify as TP0/CONS, but
their link layer solutions prevent them from being
interoperable, so they are effectively as different as TP0 and
TP4.
Having made the resolutions described above, it was agreed that all
references to the term I-WEP should be changed to WEP. It was
agreed that the I-WEP concept is no longer necessary.
In conjunction with the decisions made above, new proposals were
made for the structure of routing tables maintained for the X.400
network. Two tables, an MTA table and a Domain table, will be
defined. The MTA table will define the names of well known MTA's
(WEP's) and their associated connection data including selector
values, NSAP addresses, supported protocol stacks, and supported
X.400 protocol version(s) (i.e., 1984, 1988, 1992, etc.).
Each entry in the proposed Domain table will consist of an X.400
address, followed by a list of MTA's which are willing to accept
mail for the address or provide a relay service for it. Each MTA
name will be associated with a priority value. Collectively, the
list of MTA names make the address reachable from all protocol
stacks. In addition, the list may provide redundant paths to the
address, so in this case, the priority value indicates the
preferred path, or the preferred order in which alternative routes
should be tried. The format of a Domain table entry might look
like:
C=CH; ADMD=ARCOM; PRMD=SWITCH
PRIO=1, MTANAME=switch.ch
PRIO=2, MTANAME=relay.dbp.de
PRIO=3, MTANAME=mhs-relay.cs.wisc.edu
Architectural Principles
This section will be removed as it is no longer required that all
WEP's be directly interconnected.
o Description of PRMD policies: All references to PRMD will be
changed to MD (Management Domain). This will allow ADMD's to
operate within the Internet X.400 Service.
X.400 address registration
This section will be updated such that it supports the
9
specification of numeric country codes, ADMD names, and PRMD
identifiers. Support of numeric identifiers is required by the
X.400 standards and implementors agreements.
The description of ``unique address'' will be softened. The basic
requirement is that all originator addresses transmitted into the
Internet X.400 Service must be universally ``repliable''. In
support of this requirement, the document will recommend that users
align their addresses with exactly one ADMD name in cases where
they have a choice of ADMD names.
It was pointed out that the requirement that organization names be
nationally unique is not justified. Organization names must be
unique within the context of the subscribed PRMD or ADMD, but they
need not be nationally unique. The document will be updated
accordingly.
The document will include a strong recommendation about the syntax
of PRMD, O, and OU names. Specifically, such names should consist
of letters, digits, and hyphens only. Also, a hyphen should
neither occur as the first nor the last character of a name, nor
should a name begin with a digit.
The document needs to contain information about officially
supported DDA's. In particular, the supported DDA's should be
listed along with their required syntaxes and semantics. The
document must indicate the DDA's for which support is mandatory.
The document should reference the forthcoming RFC which describes
'88->'84 downgrading, and it should indicate that support of that
RFC is mandatory for organizations connected to the Internet X.400
Service.
- An organization with no defined X.400 address space
This section will be reworded such that it clarifies the fact
that the address of an RFC987 gateway need not be precisely:
C=US; ADMD= ; PRMD=Internet
In particular, the country name C=US is not mandatory. Each
country is free to choose its own well known RFC987 gateway
address. For example: C=CH; ADMD= ; PRMD=Internet
General comments/issues:
- The document should mention that issues concerning X.400 '88
are, in general, left for further study. This leaves a hook
for future work.
10
- The document should reference a separate RFC which will
describe the details of routing. Section 4.3 of the current
draft will be moved into the routing RFC.
- The ``6A'' concept described in the current draft needs to be
revised such that it reflects the new international flavor of
the document.
- X.400 network coordination and administration will need to be
distributed between continents. The X.400 Working Group, in
concert with RARE/COSINE, will need to document administrative
responsibilities and how they are divided between countries.
- We must determine how the commercial ADMD service providers
relate to the Internet X.400 Service.
Use of distributed databases for routing/mapping purposes:
Claudio Allocchio presented his experiences in experimenting with DNS as
a solution for managing RFC987 routing/mapping tables. First, Claudio
experimented with using PTR records for storing and managing mapping
tables. His conclusion is that this is a reasonable short-term solution
(pending a better X.500-based solution).
Next, Claudio experimented with using MX records for managing X.400
routing information. Again, he concluded that this is a reasonable
short-term solution.
Claudio is planning to implement and make generally available a portable
tool (written in C) which will allow an administrator to create the
standard RARE/COSINE routing/mapping tables from information stored in
DNS.
Kevin Jordan reminded the Working Group about the description he
distributed after the previous IETF meeting of CDC's use of X.500
directory services for managing X.400 routing/mapping information.
Kevin agreed to update this information and redistribute it to the
Working Group as a formal proposal.
X.400 84/88 downgrading:
Steve Hardcastle-Kille presented his draft RFC on '88->'84 downgrading.
He accepted comments from the Working Group and will make some minor
changes to the document.
Future issues:
No additional future issues were discussed.
Summary of conclusions and actions:
R. Hagens, A. Hansen. The RFC authors will revise the document in
11
accordance with the comments and conclusions generated at this meeting.
A new draft will be distributed prior to the next IETF meeting, no later
than November 11.
K. Jordan: Kevin will update his previous white paper which described
CDC's usage of X.500 directory services in support of X.400
routing/mapping. He will distribute the updated paper to the Working
Group as a formal proposal.
Kevin will also distribute a proposal for mapping X.400 O/R addresses to
X.500 distinguished names. This mapping will allow X.500-based
routing/mapping information to be distributed easily across the
Internet, in a fashion similar to the way in which DNS information is
distributed.
C. Allocchio, E. Huizer, U. Eppenberger: This team will distribute a
proposal for using DNS and/or FTP-based services for managing X.400
routing/mapping information.
S. Hardcastle-Kille: Steve will update the '88->'84 downgrading RFC and
work with EWOS to make support of DD.COMMON well defined and mandatory.
P. Yee: Peter will do some research into North American groups such as
EMA and NADF. He will discover what they are currently doing and
recommend a level of involvement for XNREN and/or the X.400 Working
Group.
Future meetings:
The next general IETF meeting is scheduled for November 18 - 22 in Santa
Fe, New Mexico. The X.400 Operations Working Group will meet on
Wednesday and Thursday (November 23 and 24). Also, if there is
sufficient interest, a BOF meeting may be organized.
Attendees
Claudio Allocchio claudio.allocchio@cosine-gw.infn.it
William Biagi bbiagi@cos.com
Peter Boos peterb@bnr.ca
David Brent brent@CDNnet.ca
Vinton Cerf vcerf@nri.reston.va.us
Henry Clark henryc@oar.net
Curtis Cox ccox@wnyose.nctsw.navy.mil
Urs Eppenberger eppen@v
Tony Genovese genovese@es.net
Arlene Getchell getchell@nersc.gov
Robert Hagens hagens@cs.wisc.edu
Alf Hansen Alf.Hansen@delab.sintef.no
Steve Hardcastle-Kille S.Kille@cs.ucl.ac.uk
Phillip Hasse phasse@honchuca-emh8.army.mil
Tim Howes Tim.Howes@umich.edu.
Erik Huizer huizer@surfnet.nl
P. Allen Jensen allen@audfax.audiofax.com
Kevin Jordan kej@udev.cdc.com
12
Jim Knowles jknowles@trident.arc.nasa.gov
Walter Lazear lazear@gateway.mitre.org
Jack Liu liu@koala.enet.dec.com
Carl Malamud carl@malamud.com
Joseph Malcom jmalcom@sura.net
John McGuthry mcguthry@gateway.mitre.org
Harvey Shapiro shapiro@wnyose.nctsw.navy.mil
Keld Simonsen keld.simonsen@dkuug.dk
Linda Winkler lwinkler@anl.gov
Russ Wright wright@lbl.gov
Peter Yee yee@ames.arc.nasa.gov
13