Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!snorkelwacker!bloom-beacon!eru!luth!sunic!nuug!sigyn.idt.unit.no!he
From: he@idt.unit.no (Haavard Eidnes)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings
Summary: "Automatic" wildcard mapping in RFC 987 et al: amend that?
Message-ID: <1990Jul28.153108.16932@idt.unit.no>
Date: 28 Jul 90 15:31:08 GMT
References: <9007270211.AA02319@venera.isi.edu> <154.649052545@nma.com>
Sender: he@idt.unit.no (Haavard Eidnes)
Reply-To: he@idt.unit.no (Haavard Eidnes)
Distribution: inet
Organization: Div. of CS & T, Norwegian Institute of Technology
Lines: 54

There's one thing I've wanted to bring up for a while, which is
becoming more relevant as this discussion surfaced.  The issue
is with the RFC987 mapping tables, and with the inability to
distinguish between "wildcard" mappings for a domain name
and mapping only for the domain name itself. Stated in DNS RR 
terms, it seems that the mapping tables has 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, covering the mapping expressed by *both*
of the above RR's:

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 a X.400 mail system, and host.some.domain.no as domain names
for your SMTP-speaking hosts. Furthermore, you wish to use a different
X.400 mapping for your SMTP-speaking hosts than for the X.400-speaking
hosts. If you do this, 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" addresses for your (central?) X.400 service.

This should perhaps be amended, at least before we start storing 
the data in the DNS? (Not that it's not a problem for the table based
approach...)

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
problem.

I should perhaps mention that my exposure to this problem is only
second-hand, and I have yet to fully grasp all of RFC 987 and its
companions, so please excuse any inaccuracies or wrong terminology
above.


Regards,

Havard Eidnes, Postmaster &c @idt.unit.no, Uninett employee, ...
Division of Computer Systems and Telematics, Norwegian Institute of Technology