Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!ncis.tis.llnl.gov!CS.UCL.AC.UK!S.Kille
From: S.Kille@CS.UCL.AC.UK (Steve Kille)
Newsgroups: comp.protocols.iso.x400.gateway
Subject: Re: on x.400 address RFC draft
Message-ID: <9133.616841027@UK.AC.UCL.CS>
Date: 19 Jul 89 08:43:47 GMT
References: <897IH172601095*Robert.Ullmann@EN-C06.X400.Prime.COM>
Sender: root@ncis.tis.llnl.gov
Distribution: inet
Organization: The Internet
Lines: 54
Approved: post-x400-gateway@tis.llnl.gov

Robert,

I believe your approach to be unworkable.  In this context, it is difficult
to formulate a positive reply.  I sent you a longish message analysing the
problems.  I am sorry to hear that you simply "filed the response
appropriately".

The Domain hiearchies around the world are being populated rapidly, and in a
pragmatic fashion.  They tend to be research and communication oriented
companies.  The 3166 top level domains are (mostly) being used to build
national services.  They are not being left as a "bucket" for
algorithmically derived X.400 addresses.  More importantly, many parts of
the "real domain" namespace will move to X.400, and wish to do so
transparently.  For this reason, you should not be able to tell whether an
address maps to an  822 or X.400 UA.   

X.400 hierarchies are being allocated by PTTs and RPOAs.  It is happening
more slowly, and in a very differnet and ad hoc fashion.   
X.400 administrations will not in general look much to the domain namespace.

You say "But, presumably, the intent is that X.400 will be as well self
connected as the internet".  I put it to you, that this is fundamental to
X.400.  More important, most of the X.400 world (providers at least) will
not be interested in the Internet, and will not want to know about C=XA.  

Co-ordination of tables is a problem, and we have set up some initial
mechanisms in Europe.  The administration is hierarchical, and so it is easy
to extend.  If the tables get too large, the syntax is designed so that it
can be easily supported by DNS.   It is all quite workable.

I note that a mapping very similar to what you propose is appropriate for
SOME PARTS OF THE ADDRESS SPACE.  For example, in the UK, under domain 
GB, we have (currenlty) defined:

   GOLD-400.GB   <->  /ADMD=Gold 400/C=GB/
   TMAILUK.GB    <->  /ADMD=TMAILUK/C=GB/
   AC.UK         <->  /PRMD=UK.AC/ADMD=Gold 400/C=GB/

This will lead to algorithmic assignments for all of the new commercial
stuff, but with a more natural mapping for the UK AC stuff.  For some
commercial orgs, we might define mappings onto the existing space.

  NPL.CO.UK     <->  /O=NPL/PRMD=N-Net/ADMD= /C=GB/
   
Thus, there are "nice" mappings where the worlds overlap (at the cost of
maintaining a few bindings), and algorithmic for the rest. If there are not
MX records for this lot, there should be!

But this is all caterd for in 987, and does not need a new spec!   

regards


Steve