he@idt.unit.no (08/07/90)
Well, after drawing a whole week of zilch response over in comp.protocols.tcp-ip.domains, I thought I'd drop this on your heads instead, as this place might be more appropriate (the subject has only slight relevance to the domain name system today). Sorry to those of you who see this a second time. Below follows a slightly edited version of my original article. There's one thing I've wanted to bring up for a while, which is becoming more relevant as this discussion surfaced [the discussion of storing RFC 987 etc mapping data in the internet DNS]. The issue is with the RFC987 mapping tables, and with the inability to distinguish between "wildcard" mappings for a domain-syntax name and mapping only for the domain-syntax name itself (to borrow some terminology used in appendix F in RFC987). Stated in DNS RR terms, it seems that the current mapping tables have no way to distinguish between the two following RR entries: $origin some.domain.no. @ WHATEVER TO-X400 something * WHATEVER TO-X400 something-else Instead, it would seem that an entry like the first automatically would be interpreted as a wildcard specification expressed by the second. The corresponding RFC 987 mapping table (domain->X.400) would only contain a single entry, "obscuring" the mapping specified by the second RR above: some.domain.no#something# This deficiency is inconvenient for several reasons. First, it runs a bit counter to the use of wildcard matching in the DNS. Second, it increases the size of the RFC 987 mapping tables in specific cases, illustrated by the following example: Say that you wished to use the address some.domain.no as the domain name of an X.400 mail system, and host.some.domain.no as domain names for your SMTP-speaking hosts. Furthermore, you wish to use a different TO-X.400 mapping for your SMTP-speaking hosts than for the X.400-speaking hosts. Under these conditions, the above mentioned deficiency forces you to register all RFC822/SMTP-speaking hosts with their own TO-X400 mapping! This is obviously not desirable if you start conversion to X.400 (without throwing out all SMTP/RFC822 mail systems all at once) and want to use a "natural" domain name for your X.400 service (ie. by *not* mapping ADMD and PRMD into the domain name). I checked (quickly) with the RFCs 1026 and 1148 (all concerned with mapping between X.400 and RFC 822), and they seem to have the same (IMHO deficient) design on this point. Is there an inherent property of RFC 987 et al (1026, 1148) or even in x.400 that has led to the current design? Is there any chance of having this amended? (Perhaps before we start storing the mapping data in the DNS?) Or am I beating a dead horse here? I should perhaps mention that my exposure to this problem is only second-hand, ie. I am in the happy position of not maintaining an RFC 987 mapping table myself. And -- if you haven't guessed already -- I come from "the TCP/IP camp", so please excuse any inaccuracies or inappropriate terminology above. Regards, Havard Eidnes, Postmaster &c @idt.unit.no, Uninett employee, ... Division of Computer Systems and Telematics, Norwegian Institute of Technology