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