CURRENT_MEETING_REPORT_ Reported by Robert Hagens/Univeristy of Wisconsin AGENDA o Announcement of new name o Status of the quest for "NREN" o Review of Scope - 822 <-> X.400 gateway issues (RFC 987 and successors) - X.400 operational issues in a dual protocol internet o Review of Issues - 822 <-> X.400 Gateways * RFC 987 gateway background * Table Maintenance * Locating a Gateway * ORAddress Structure - X.400 Operation * Routing to destination or 822 gateway * Use of Internet Technology * Mixed Stacks * MTA names * Use of "NREN" Presentation of a new, unified address structure ooEnumerating and discussion of major tasks MINUTES The meeting was convened by chairman Rob Hagens. An attendance list will be published with the Proceedings of the IETF. The Domain Name WG meet jointly with the OSI-X400 WG during the afternoon. WORKING GROUP SCOPE The scope of the WG was presented: o RFC 822 <-> X.400 Gateway Issues - maintenance of RFC 987 mapping tables - routing toward a gateway o X.400 Operational Issues - Structure of OR-Addresses in the Internet - X.400 Routing - Nameservers The group determined that (with the exception of determining the structure of OR-Addresses in the Internet), they should not try to solve "pure-OSI" problems. These problems fall into the domain of other OSI groups. The WG should develop and maintain a close relationship with such groups: o NIST X.400 SIG o NIST X.500 SIG o GOSIP X.400 committee PRESENTATION OF ISSUES Rob Hagens presented a list of issues facing the WG. That list is included here: Issues, Problems, and Proposed Solutions to X.400 and 987 Gatewaying in the Internet 1. X.400-RFC 822 Gateway Issues (a) Background This background information serves as a very brief tutorial on RFC 987. The information presented below is far from complete. It is strongly recom- mended that anyone interested in the issues dis- cussed below should obtain and read RFC 987. RFC 987 specifies how messages should be gatewayed between RFC 822 based systems and X.400 (1984) based systems. Although the RFC describes the translation of various protocol elements from one system to the other, the following discussion is limited only to the translation of addresses. RFC 987 specifies that translation from one address space to another may occur in 2 ways. The normal method of translation (table lookup) is used when sub-trees of the different name spaces are associ- ated via mapping tables. The fall back method of translation (encoding in the other address space's format) is used when table lookup fails. Table lookup is accomplished through the use of 2 separate tables: an RFC 822 -> X.400 table, and an X.400 -> RFC 822 table. Each entry in the tables is indexed by a key. The address to be mapped is compared against each key in the table. The com- parison that matches the most components is selected (i.e., the "longest" match). The value associated with the key is a template that is used to construct the translated address. i. Table Driven Mapping For example, the 822 domain "merit.edu" could be associated with the OR Address space "C=US, PRMD=NREN, O=MERIT.EDU" in a mapping table. Thus, when translating the 822 address "hwb@merit.edu", the domain specification "merit.edu" would be compared against the various keys in the table. Assuming that the table con- tains two keys "edu" and "merit.edu", the longest match "merit.edu" would be selected. The template associated with the key "C=US, PRMD=NREN, O=MERIT.EDU", would be used to produce the address "C=US, PRMD=NREN, O=MERIT.EDU, OU=CS, PN=HWB". In this example, the translation of the last domain component "cs" is performed systemat- ically. The translation of the right-hand side of the 822 address "hwb" is specified by RFC 987. This example shows that a single entry can specify the translation for all addresses in the "merit.edu" domain. This entry associates the 822 domain "merit.edu" with the X.400 namespace under "C=US, PRMD=NREN, O=MERIT.EDU". An analogous scheme is used for the opposite direction. ii. Mapping Without Tables If a mapping table entry is not present, transla- tion may still occur. However, in this case, the translation is less sophisticated. Translation, in this case amounts to encoding the address in the other system's format. RFC 987 specifies default rules that may be used to perform this encoding. These rules specify the manner in which an RFC 822 address may be encoded in X.400, and vice versa. The following examples consider each direction separately: iii.RFC 822->X.400 In this direction, the domain-defined attribute "RFC-822" may be used to encode an RFC 822 address. For example, if an 822 address "hagens@janeb.cs.wisc.edu" was translated by a gateway that had an X.400 address "C=US, PRMD=NREN, O=MERIT.EDU", then that gateway (in the absence of a mapping table entry) would produce the address 'C=US, PRMD=NREN, O=MERIT.EDU, DD.RFC- 822="hagens@janeb.cs.wisc.edu"'. iv. X.400->RFC 822 In this direction, left-hand side encoding may be used to encode an X.400 address within 822. For example, the X.400 address "C=FR, ADMD=FRENCH-PTT, O=INRIA, PN=HUITEMA", when considered by a gateway with the 822 address "merit.edu", would be translated to '"C=FR, ADMD=FRENCH-PTT, O=INRIA, PN=HUITEMA"@merit.edu'. (b) Issues i. Table Maintenance The mapping table entries must be kept consistent among all the 987 gateways in the world. This is very difficult to accomplish by hand. How can the table maintenance task be automated? ii. Finding the Gateway How does a mail router find a 987 gateway? In the X.400->RFC 822 direction, it is the responsi- bility of X.400 routing. Note: X.400 routing is not defined by any standard. In the RFC 822- >X.400 direction, it is the responsibility of 822 routing. Conventional MX records could be util- ized to solve the problem. iii.Structure of X.400 addresses It is desirable to provide a default X.400 address for hosts within the Internet. This address will be structured so that the X.400 address space corresponds with the domain namespace. What is the best structure to use for this purpose? The choice of format of X.400 addresses, and the corresponence of these addresses to 822 domains will determine the contents of the of 987 mapping table entries. oProposed Solution The currently proposed solution is to map the top and second level domains to the ORAddress "organization" attribute. Subsequent lower level domains will be mapped to a sequence of "organization unit" attributes. For example, "venera.isi.edu" would map to "O=isi.edu, OU=venera". oUse of 'NREN' as a PRMD name The intended use of "NREN" as a PRMD name is to identify a management domain within which every registered Internet entity has a default X.400 Address. This address would be based upon the Internet domain name. We expect some or all currently registered entities to decide for themselves whether they wish to use the default or register another name in another way. This default provides a useful and helpful option without constraining any individual entity to keep what the default provides for them. Is it necessary to define a second PRMD name which would identify a management domain within the NREN that utilizes X.400 addresses that are not based upon Internet domain names? If this is true, is the original use of "NREN" incorrect? We need to show "ownership" of the name "NREN" so that other groups do not have the right to register it. Trademarking is the first step. Other uses of "NREN" should be looked into. Any way that we can show "use" of the name will help establish our "ownership". 2. X.500 Operation Issues (a) Issues i. Distinguished Names Who will determine the structure of X.500 dis- tinguished names (and the objects they locate) for use within the Internet community? ii. DNS coexistence How should the DNS and X.500 coexist? iii.Domain Distinguished Names Is it acceptable, for transition purposes only, to suggest that Domain names be used as Dis- tinguished names? DISCUSSION OF ISSUES Non-USA Internet Sites The default OR Address may not be acceptable for Internet sites that are not within the USA. 1) The WG cannot mandate the format of addresses within a foreign country. 2) the NREN is a national object. Are these reasons sufficient to prevent the definition of a default name using NREN? At least, it should be made clear that the default name is valid for USA-Internet sites only. This may not be inappropriate if many foreign countries have already defined the X.400 registration policy that would affect the foreign Internet sites. "NREN" The name "NREN" was originally choosen to be a PRMD name. The purpose of this PRMD was to contain OR Addresses based upon Domain Names. It was suggested that perhaps "NREN" is not appropriate for this use. No other name was decided upon. Possible candidates are names that convey some concept of Domain Names, such as "DN". This change would allow the name "NREN" to be used by a FRICC-run PRMD. Another option for a PRMD name would be to use the numeric form. The effort to pre-register "NREN" as an ANSI OSI Organization name failed. It is not clear that the OSI X.400 WG should attempt to register the name until its exact use has been determined. It was suggested that the WG should consider producing a specification for written OR Addresses. PRESENTATION OF A NEW, UNIFIED ADDRESS FORMAT Paul Mockapetris presented his ideas regarding a new style of address. He would like to see the world move forward with the development of a unified, simple address structure. His proposal is a format that has RFC 822 compatible syntax, whose semantic value is that of an X.500 distinguished name. These new addresses would be very short and user-friendly. The new addresses could be used to look up both X.400 ORAddresses as well as conventional 822 addresses. The look up mechanism could utilize the DNS as well as X.500. GATEWAY SCENERIOS A discussion of RFC 822 - X.400 gateway (987) scenarios produced the following questions: o Will any 987 gateway provide connectivity to every X.400 MTA? The answer to this question will determine whether an 822 transfer agent must choose a specific 987 gateway based upon the destination address, or if the closest, default 987 gateway will always suffice. o Is there really benefit to table driven mappings or is it sufficient to simply use default encodings? A scheme that utilizes the DNS to aid a 987 gateway was discussed. The scheme requires the following components: o An ASCII (canonical) representation of ORAddresses. o A new tree of the DNS that is based upon canonical ORAddresses strings (called ORADDR). This tree is populated with MX records (that store the SMTP 822 address of 987 gateways), and TO-SMTP RRs. o Two new DNS resource records. TO-SMTP RRs are stored in the ORADDR tree. They contain the information necessary to translate an X.400 address into an 822 address. TO-X400 RRs are stored in the existing DN tree. They contain information necessary to translate SMTP 822 addresses into X.400 addresses. A distributed collection of TO-SMTP and TO-X400 records correspond to the 987 mapping tables X.400 to RFC 822 (mapping 1) and RFC 822 to X.400 (mapping 2), respectively. A sample scenario would be: 822->X.400 Case A The destination address is an SMTP address which has been previously associated with an ORAddress. This means that there is a TO-X400 RR that describes how to translate the SMTP 822 address into an ORAddress. The originating transfer agent will look up the destination address and receive an MX record and a TO-X400 RR. The MX record identifies a 987 gateway and is used to transfer the message to that gateway. The TO-X400 record is ignored by the originator. When the 987 gateway receives the message, it will lookup the destination address and receive an MX and TO-X400 RR. The MX record is ignored, but the TO-X400 RR is used to translate the destination address into an ORAddress. Case B The destination address is an ORAddress. The originating transfer agent will look up the destination ORAddress in the ORADDR tree and receive an MX record. The MX record identifies a 987 gateway and is used to transfer the message to that gateway. The destination address sent in the SMTP envelope will contain "ORAddress"@gateway. X.400->822 Routing to the 987 gateway is not within the scope of the WG; it is assumed that the message has already reached the 987 gateway. Case A The destination address is an ORAddress which has been previously associated with an SMTP 822 address (sub)tree. This means that there is a TO-SMTP RR that describes how to translate the ORAddress into an SMTP 822 address. When the 987 gateway receives the message, it will lookup the destination address in the ORADDR tree and receive a TO-SMTP RR. The TO-SMTP RR is used to translate the destination address into an SMTP 822 address. Case B The destination address is an 822 address which has been encoded in an ORAddress. When the 987 gateway receives the message, it will translate the destination address into an 822 address using the default encoding rules.