CURRENT_MEETING_REPORT_ Reported by Robert Hagens/University of Wisconsin OSI X.400 Minutes Agenda o Review of the Draft Proposal for the use of the Internet DNS to maintain RFC 987/RFC 1148 Address Mapping Tables. o Discussion of the structure of O/R Addresses used by the Wisconsin Pilot X.400 project. o Address mechanisms that allow non-X.400 users (i.e., RFC 822 mail users) to address X.400 users. The meeting was convened by Chair Robert Hagens. An attendance list will be published with the Proceedings of the IETF. The meeting had several attendees from the NIST/OSI workshop, X.400 SIG. A proposal has been circulated on several mailing lists; ``Draft Proposal for the use of the Internet DNS to maintain RFC 987/RFC 1148 Address Mapping Tables'' (by Cole and Hagens) which describes how the DNS could be used to store, retrieve, and maintain the mappings between RFC 822 domain names and X.400 O/R addresses. Implementations of RFC987 gateways require that a database store address mapping informAtion for X.400 and RFC822. This information must be disseminated to all RFC987 gateways. In the internet community, the DNS has proven to be a practical means for providing a distributed nameservice. Advantages of using a DNS based system over a table based approach for mapping between O/R addresses and domain names are: 1. It avoids fetching and storing of entire mapping tables by every host that wishes to implement RFC987. 2. Modifications to the DNS based mapping information can be made available in a more timely manner than with a table driven approach. 3. Table management not necessarily required for DNS sites. 4. One can determine the mappings in use by a remote gateway by querying the DNS (remote debugging). The proposal was discussed. A scenario was presented which demonstrated an example lookup: Given O/R Address: ``/c=us/admd= /prmd=nren/o=uw-madison/ou=cs/ou=dip/s=hagens'' and DNS record 1 ``*.cs.uw-madison.nren. .us.x400'' IN TO-822 6 cs.wisc.edu 1. O/R Address is rewritten as a domain name with attribute values used as domain components: dip.cs.uw-madison.nren. .us 2. Lookup domain name within X.400 top-level domain: lookup(dip.cs.uw-madison.nren. .us.x400) returns cs.wisc.edu (count = 6) 3. Since the count indicates that only 6 of the 7 attributes were matched, any unmatched components must be prepended. In this case, prepend ``dip''. 4. Result: dip.cs.wisc.edu The proposal received general acceptance. Several changes to the approach have been suggested which differ from that specified in the proposal. These changes are summarized below: 1. DNS representation of O/R address to use O/R attribute values directly, not appendix F notation. 2. The new tree of X.400->RFC 822 resource records should be placed within a new top level domain (the name of this top level domain is undecided). 3. Generation of table information from DNS is performed via recursive zone transfers of the x.400 tree (instead of an automated submittal process). This is probably the biggest issue to be resolved. It is vital that the process of extracting the mappings from the DNS be given a thorough analysis so as to insure that it is feasible. 4. Wildcard count field can be changed so that it is statically entered in authoritative input data, instead of computed by authoritative servers. 5. Discard preference field in proposed resource records. A portion of the X.400 session was spent discussing X.400 naming and in particular the construction of RFC822 addresses to reach users who are really using X.400. This discussion was led by Allan Cargille, University of Wisconsin I. Naming Choices. When determining initial X.400 O/R Names, one can either derive the new X.400 names from existing RFC822 addresses, or can start afresh with new names that take advantage of the semantics of the O/R Name structure. In particular, one can select X.400 Organization and Organizational Unit names that are more suitable for database lookup. For example, at the University of Wisconsin-Madison, they have existing addresses of the form user@cs.wisc.edu. Constructing the X.400 O/R Name from the existing RFC822 name could yield something like: c=us; admd= ; prmd=xnren; o=wisc+edu; ou=cs; s=user 2 while starting afresh could yield names like: c=us; admd= ; prmd=xnren; o=uw-madison; ou=cs; s=user So far in the NSF X.400 project they have taken the second approach, that of constructing new O/R Names instead of deriving them from existing domain names. Group opinion was that sites should have the freedom to select whatever O/R Name they felt would be most helpful, either derived from an existing domain name, or newly selected. II. Addressing X.400 Users From The RFC822 World. There are several approaches that can be taken. All have technical advantages and disadvantages -- it is not obvious that any choice would be ``right'' or ``wrong''. Assume that there are people in the U.S. Internet that are using X.400 as their email service. Users in the RFC822 world need to be able to address these X.400 users. It is assumed that part of the user population at a site may move to X.400, while the remainder of the users continue to use RFC822 mail. A. Default solution as per RFC987. Mail would be explicitly sent to an RFC987 gateway, with the X.400 address on the left hand side of the ``@'' and the gateway address on the right hand side. This would look like ``c=us;admd= ;prmd=xnren;o=uw-madison;ou=cs;s=user''@x400.gateway.us. This scheme does not require any special mapping records in the RFC987 gateway. B. RFC987 Regular Mapping Rule. This solution has been adopted by some European countries. The RFC822 address for an X.400 user is composed by using concatenating values of the X.400 address. For example, a user with the X.400 address c=us;admd= ;prmd=xnren;o=uw-madison;ou=cs;s=user would be addressed as ``user@cs.uw-madison.xnren.us'' (or something similar). This looks much like an existing Internet address. One would also register MX records to direct mail for xnren.us or organization.xnren.us to an RFC987 gateway. One complication of this scheme is that it requires a REGULAR rule for constructing the RFC822-style address from the X.400 address. This could be problematic in the U.S. in large. For example, some government sites will be using a value in the ADMD field, whereas other sites will only use a blank in that field. This scheme requires placing records in the global RFC987 mapping tables 3 but only a few, because general mapping rules are being used. This scheme creates a new address space inside the U.S. Internet in parallel to existing addresses. For a user who switched from RFC822 to X.400, mail to the that user's ``old'' Internet address would still work due to the use of a system alias or .forward file to forward the mail to the new address (and thus to the RFC987 gateway). C. Mapping to Existing Names. This solution would keep the names used to reach X.400 users consistent with the existing domain names. Each site would register a local MX record in their existing domain name space that points to an RFC987 gateway. This would look very much like just another hostname. Mail to the X.400 users would be sent to this new MX record and be forwarded to a gateway. For example, in the University of Wisconsin Computer Science Department, addresses look like user@cs.wisc.edu. Several people are starting to use X.400, and RFC822 mail was directed to them as: Last@x400.cs.wisc.edu, or First.Last@x400.cs.wisc.edu This scheme requires entering a mapping record for every organization into the global RFC987 mapping tables. Discussion. The Working Group recommended solution C above because it is most consistent with existing domain names, and does not require the creation of any new high-level domains. The Working Group expressed concern at the ``x400'' string being used as part of a user address (even though this is really just part of an MX record name) because in general we do not want to encourage people to externalize the kind of email end-system inside the email address. Based on this input, the Wisconsin NSF X.400 project has changed to Internet-style addresses of the form: Last@pilot.cs.wisc.edu, or First.Last@pilot.cs.wisc.edu Action Items: Prepare a new version of the DNS proposal. Complete by next IETF meeting. Attendees Dave Borman dab@opus.cray.com David Brent brent@staff.ucs.ubc.ca C. Allan Cargille cargille@cs.wisc.edu Isaac Chan isaac@gui.consumers.bc.ca Andrew Cherenson arc@sgi.com Richard Colella colella@osi3.ncsl.nist.gov 4 Curtis Cox zk0001@nhis.navy.mil Mark Crispin mrc@cac.washington.edu Ella Gardner epg@gateway.mitre.org Martin Gross gross@polaris.dca.mil Robert Hagens hagens@cs.wisc.edu Erik Huizer huizer@surfnet.nl Jim Knowles jknowles@trident.arc.nasa.gov Neil Koorland nkoo@cs.ubc.ca Walter Lazear lazear@gateway.mitre.org Judy Messing messing@gateway.mitre.org Paul Mockapetris pvm@isi.edu Jim Reinstedler jimr@ub.com Erik Skovgaard eskovgaa@uvcw.uvic.ca Einar Stefferud EStefferud@ECL Roxanne Streeter streeter@nsipo.arc.nasa.gov Peter Vanderbilt pv@sun.com Chris Weider clw@merit.edu Linda Winkler b32357@anlvm.ctd.anl.gov Jean Wu eskovgaa@uvcw.uvic.ca 5