[prev in list] [next in list] [prev in thread] [next in thread] 

List:       namedroppers
Subject:    Re: re-sent message: DNS and rouring data
From:       Paul A Vixie <vixie () pa ! dec ! com>
Date:       1993-03-02 16:23:44
[Download RAW message or body]

I've only been half-glancing through the mail on this X.400 thing, so
I may be speaking from ignorance.  It is also well-established that I
do not think X.400 is a good protocol and I am loathe to waste time
on it.  However, Digital has its own OSI-based mail product set, called
"DECnet Phase V" and while I don't really want to switch from TCP/SMTP
to an OSI-based mail system, I was very intimately involved in designing
the encapsulation namespace for the OSI->SMTP gateway.  Something like
it ought to serve the Internet X.400 community perfectly well.  The thing
I'm sad about is that we're not getting the X.500 directory stuff out of
any of this, and X.500 was the only thing that made X.400 worth using.
Anyway, here's what DECnet Phase V does to messages it has to transport
over SMTP (either to an Internet address or tunnelled to a remote Phase V
address -- the syntax is the same):

this:
	vixie@DEC:.ucp.cognition
becomes
	vixie@cognition.ucp.dec.d5net.dec.com

Salient items are:

1. Phase5 addresses are left-to-right, Internet addresses are right-to-left.
2. "d5net" is an arbitrary pseudodomain; "v.easynet" was also specified as
   being possible.  this token facilitates top-level MX RR's for the gateway.
3. the "DEC:" namespace is just tokenized, no big deal, the transformation
   algorythm has a default for this if it wasn't specified on the input.
4. "dec.com" is arbitrary, it's our domain, other encapsulated PhaseV nets
   would obviously use their own top-level domain.
5. there is also a syntax for encapsulating NSAPS but it's obscure and ugly.

Now, I don't know which of the many X.400-like syntaxes we are trying to map
in today's discussion, but I'm betting that they are amenable to this 
solution.  These objects do not have to have terminal MX RR's -- we use a
top-level wildcard -- but they could have terminal MX RR's.  Either way we
have here a mechanism that hides a non-IP network in the DNS with no new RR
types needed.

This doesn't help X.400 nodes find eachother when no Internet is involved,
of course.  If today's X.400 discussion has that aim, then I have to wonder
how these X.400 nodes will be able to send and receive IP/UDP packets at all
(they need this to reach the DNS).  If all X.400 nodes will have to have a
dual-stack (including IP/UDP in other words), then they can just use their
Internet A RR and forego the whole X.400 naming issue.

In other words the discussion to date appears to be a solution in search of
a problem.

[prev in list] [next in list] [prev in thread] [next in thread]