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