Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!zaphod.mps.ohio-state.edu!usc!ucsd!ucbvax!MIRSA.INRIA.FR!Christian.Huitema
From: Christian.Huitema@MIRSA.INRIA.FR (Christian Huitema)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings
Message-ID: <9007171112.AA01140@jerry.inria.fr>
Date: 17 Jul 90 11:12:11 GMT
References: <1217.648201567@UK.AC.UCL.CS>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 40

Rob,

I read your note, and think that we should work towards its fast
finalisation, perhaps clarifying a few points. 

My first remark concern the mapping ``towards X.400''. You follow-up
the mechanism which was first introduced in RFC-987, to build up a
hierarchical name as a sequence of ``typed'' tokens, e.g. a top
level "C$FR", a second level "ADMD$ATLAS", etc. This has the
advantage of precision, but it has also one serious disadvantage,
i.e. requiring the setting up of a complete new tree. I feel that
this kind of mapping is in fact contradictory with the whole
philosophy of RFC-987/1048, where after some specific top levels (C,
ADMD, PRMD) the next hierarchical tokens are mapped directly to DNS
name parts.

A specific start of the tree is certainly necessary, as the
subdomains of e.g. "C=FR" bear few relations with those of ".FR".
This could easily be provided by setting up a pseudo top domain for
"x400", in much the same way as "in-addr". But then, there is no
need to insist on the presence of the "C$" or "OU$" prefixes;
one should rather try to use the aliasing mechanism already
present in the DNS, in order to discover that e.g.
"cea.cea.atlas.fr.x400" is in fact the same domain as "cea.fr". This
has two advantages:
	* the same tree can be used at the lower levels,
	* there is no need for a specific "to-rfc" record.
This can also introduce my second remark, regarding routing and the
choice of gateways. If the naming heirarchies are in the same tree,
there is no need of inventing new routing mechanisms; you can as
well use the MX records! Indeed, there is at that point the need to
support X.400, hence the need to define a PSAP record associated to
the MX host, but this may be another matter...

My other remarks are much in the same line as Steve. I don't see
much need for a preference counter in the "to-x400" records, and I
don't see why the wildcarding mechanism should be different from
the one used for the MX records...

Christian Huitema