CURRENT_MEETING_REPORT_
Reported by Kevin Jordan/CDC
X400OPS Minutes
Review of Agenda
The Agenda was approved without change. Although, some minor
adjustments were made as the meeting progressed.
Review of Charter
It was made clear that the focus of the Working Group is the operation
of X.400 mail on the Internet.
Rob Hagens presented a one page draft document describing the strategy
for deployment of X.400 in the Internet. The goals described in the
document were reviewed and discussed. The goals drafted by Rob were:
o The X.400 service will not, in the near future, completely replace
existing Internet mail service.
- It was pointed out that this is an assumption, not a goal. It
was suggested that a useful goal would be to work with the SMTP
Verison 2 Working Group in order to facilitate gatewaying
between SMTP V2 and X.400.
- People who had attended the SMTP V2 meetings on Monday, 3/11,
reported briefly on what was discussed there. It seems that
the SMTP V2 Working Group has just begun defining requirements,
so judging from previous experience, it will probably be at
least two years before SMTP V2 is widely implemented and
operational.
o The X.400 service in the Internet shall be fully connected to the
existing Internet Mail service via gateways.
- It was recommended that this goal be revised so that it
includes a clause about the need for X.400 gateways to be
highly interoperable with the existing Internet mail services.
1
o The X.400 service in the Internet will be connected to
international R&D X.400 service initiatives.
- UW-Madison has already established a direct X.400 link to
Norway, Finland, Canada, UK, France, Switzerland and Spain.
The Norwegian connection has agreed (at least for now) to act
as a relay between XNREN and the other participants of the
COSINE X.400 project in Europe, not directly connected to
XNREN.
o The X.400 service in the Internet will be connected to major ADMD
providers in the U.S., provided that a suitable arrangement can be
made.
- There was general consensus that this is a very important goal.
However, it is not yet clear how this goal will be attained due
to the fact that the ADMD providers are commercial
organizations who normally account and charge money for their
services.
- On the second day of meetings, Vint Cerf indicated that CNRI is
already pursuing this goal. CNRI is willing to provide the
physical plant necessary to provide a connection to an ADMD
provider, but human resource limitations may delay
implementation. Rob Hagens indicated that UW-Madison could
help.
o Although the 1984 protocols may be used on an experimental basis,
the primary deployment of X.400 should be based upon the 1988
version of X.400.
- It was recommended that this goal should be rewritten in terms
of driving toward general deployment of 1988 X.400 (or perhaps
1992 X.400), but that it is also necessary to provide backward
interworking with 1984 X.400. Conversion from 1984 to 1988 to
1992 and beyond will not occur all at once. The transitions
will probably be gradual, so backward interworking is
desirable.
o With respect to management domains, the Internet will be organized
as a collection of Private Management Domains.
Finally, the Technology section of the draft document contained the
following statement:
2
The X.400 service in the Internet will conform to the US GOSIP
profiles.
It was recommended that this statement be qualified because, for
example, GOSIP requires OSI lower layers, but the Interent X.400 service
will be based primarily upon TCP/IP (RFC1006) initially.
Relationship to other techinical groups
Some members of the X.400 Operations Working Group are also members of
other technical groups. It was suggested that this informal cross
participation would be used for communications between the X.400
Operations group and other groups. The groups mentioned were: IETF-DS,
IETF-ODA, RARE-WG1, R&D MHS Managers, NIST Workshops.
Round table presentation of current X.400 service status
Each of the Working Group participants discussed how X.400 is being used
(or is planned to be used) within his/her organization. Most sites are
planning to use X.400, but are not using it actively yet. Notable
exceptions are UW-Madison and CDC; these organizations are actively
using X.400 now.
Overall organization of the X.400 service in the Internet
o Technical requirements
Two types of MTA's were defined:
- MTA's supporting RFC1006, informally called Internet MTA's
- MTA's supporting TP0/X.25, informally called PDN MTA's
It was generally agreed that organizations wishing to particpate in
the Internet X.400 project should support Internet MTA's, meaning
that participating organizations should provide an MTA which
supports RFC1006.
However, the Working Group does not want to preclude participation
by organizations which are connected only to X.25-based PDN's.
Such an organization will need to make a bilateral agreement with
an organization which supports both RFC1006 and TP0/X.25, and
arrange for that organization to relay mail between the X.25-based
connection and the RFC1006-based Internet connection, or each PRMD
should implement mechanisms to insure end-user connectivity on top
of both stacks.
We should also be prepared to serve MTA's connected to the TP4/CLNP
infrastructure.
3
It was noted that these technical requirements are essentially the
inverse of the connection requirements established by COSINE for
its members. COSINE requires all participating organizations to
support TP0/X.25 connections to their respective country's PDN.
RFC1006 is not defined as mandatory by COSINE. This implies that
interconnection of COSINE and the Internet X.400 project will:
- require a relay in the U.S. to support both X.25 and RFC1006,
or
- require a relay in Europe to support both X.25 and RFC1006.
This, in fact, is the current state of affairs, or
- combinations of a. and b. above.
It was generally agreed that GOSIP should serve as a reference
document for X.400 upper layer technical requirements, where
``upper layers'' is defined to be the OSI Session layer and the
layers above it.
The term ``Internet WEP'' was introduced to identify a special MTA
acting as a Well-Known-Entry-Point for an Internet PRMD. UW-Madison
will distribute a draft definition of an Internet WEP to the list
for review.
o Internal organization of PRMD's
It was agreed that naming authority should be hierarchically
organized. Specifically, the names of organizations should be
coordinated with the PRMD's in which the organizations are created.
Similarly, the names of organizational units should be coordinated
with the organizations in which the organizational units are
created (but not necessarily with the PRMD administrators).
UW-Madison will maintain a list of Internet PRMD's.
UW-Madison will maintain FTP-able documents which describe
participating organizations and information about MTA's (e.g. MTA
connection information). ONLY operational organizations and MTA's
will be described in these documents.
It was agreed that an important characteristic to describe about an
MTA is its ability to operate over both RFC1006 and TP0/X.25.
Publishing this characteristic will make it easy for prospective
participants supporting only TP0/X.25 to locate existing
participants who might be willing to act as Internet relays.
UW-Madison will distribute a draft definition of an MTA document
format to the list for review.
Specification of RFC822 addresses in the X.400 world
It was agreed that RFC822 addresses should be expressed using X.400
domain defined attributes. Furthermore, a special PRMD named
``Internet'' will be defined to facilitate the specification of RFC822
addresses. For example, an X.400 user will address an RFC822 recipient
4
by constructing an X.400 address such as:
/c=us/admd= /prmd=Internet/dd.RFC-822=user(a)some.place.edu/
Participating MTA's will be configured to recognize ``/c=us/admd=
/prmd=Internet/'' as a special case. The presence of this address will
cause a message to be routed to a regional RFC987 gateway. In effect,
this special PRMD identifies a community of gateways to RFC822
recipients. This strategy is user friendly in that all users everywhere
need only remember this one gateway address, and it is efficient in that
it avoids having to establish a single, common gateway which would tend
to become a bottleneck and single point of failure.
Specification of X.400 addresses in the RFC822 world
After considerable discussion, it was agreed that RFC822 users should be
able to address X.400 recipients in RFC822/Internet terms. This implies
the necessity of maintaining and distributing address mapping tables to
all participating RFC987 gateways, at least in the short term. Other
mapping strategies were discussed (loudly and enthusiastically), but it
was shown that these alternate strategies would sometimes cause messages
(or replies to messages) to pass through more than one gateway. Since
this behavior would probably cause information to be lost in
translation, it was quickly agreed that the alternate strategies were
inferior to the good old table driven approach.
Nevertheless, it was also pointed out that some X.400 addresses do not
map cleanly to RFC822 addresses, even when the table driven mapping
strategy is used. For example, X.400 personal names which contain
generation qualifiers, personal names which contain initials but no
given name, and initials which contain periods can not be mapped to
RFC822 symmetrically such that a reverse mapping is possible.
Similarly, X.400 addresses which contain X.121 address elements
(sometimes used for expressing fax telephone numbers), unique UA
identifiers, or physical addressing attributes can not be mapped nicely.
Consequently, it will be necessary for RFC987 gateways to generate
RFC987 address syntax occasionally.
It was recommended that our RFC should contain guidelines for the
creation of X.400 personal names. In following these guidelines, users
will avoid creating personal names which can not be mapped nicely
between X.400 and RFC822.
It was generally agreed that long term reliance upon static mapping
tables is unacceptable. Therefore, it was agreed that the X.400
Operations Working Group should devise a strategy for using X.500
directory services instead.
5
Another option could be to use the DNS system for this purpose, if the
X.500 infrastructure appears to be too premature.
Future issues
The following list of issues were agreed to be important for the future
service, and the group should follow these issues closely:
o X.400/84 <--> 88 interworking.
o Use of DNS for RFC 987 address mapping management
o Use of an X.500 infrastructure for routing, table management and
user catalog purposes.
o Body types other than text.
Presentation of outline for RFC
Rob Hagens proposed an outline for the RFC to be produced by the Working
Group. Participants made comments and suggested additions.
UW-Madison will write a first draft and distribute it to the list for
review.
Future meetings
A tentative meeting has been scheduled for May 30 and 31. This meeting
will be held in Madison, Wisconsin or San Jose, California. The purpose
of the meeting will be to resolve comments against the draft RFC, in
case there are comments which can not be resolved via email.
The next general IETF meeting is scheduled for July 29 - August 2 in
Atlanta, Georgia. The X.400 Operations Working Group will definitely
meet at that time.
Action items
Rob Hagens Update and distribute the X.400 Internet Service Strategy
document.
Update and distribute outline for the RFC.
Alf Hansen Write and distribute a definition of ``Internet WEP''.
6
Kevin Jordan Distribute minutes from St. Louis meeting. Distribute
the X.500 schemas used by CDC to record information about
X.400 routes, MTA's, and address mappings. Include a
description of how these schemas are used by CDC's X.400
products.
Distribute a description of CDC's extensions to RFC987 in
support of multipart/multimedia X.400 messages.
Attendees
Vikas Aggarwal vikas@JVNC.net
Vinton Cerf vcerf@NRI.Reston.VA.US
Cyrus Chow cchow@orion.arc.nasa.gov
Alan Clegg abc@concert.net
John Dudeck jdudeck@polyslo.calpoly.edu
Ned Freed net@ymir.claremont.edu
Charles Fumuso cwf@cray.com
Shari Galitzer shari@gateway.mitre.org
Tony Genovese
Robert Hagens hagens@cs.wisc.edu
Alf Hansen Alf.Hansen@pilot.cs.wisc.edu
Kevin Jordan kej@udev.cdc.com
Mukesh Kacker mukesh@sun.com
Jim Knowles jknowles@trident.arc.nasa.gov
Ruth Lang rlang@nisc.sri.com
Mike Little little@ctt.bellcore.com
John Reinart reinart@cray.com
Ursula Sinkewicz sinkewic@decvax.dec.com
Michael Stanton "usermas@lncc.bitnet"
Michael Tharenos tharenos@jessica.stanford.edu
Linda Winkler lwinkler@anl.gov
Russ Wright wright@lbl.gov
7