Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!decwrl!ucbvax!CS.WISC.EDU!hagens
From: hagens@CS.WISC.EDU
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: Proposal for use of DNS to store RFC 987, etc mappings
Message-ID: <9007181733.AA00361@janeb.cs.wisc.edu>
Date: 18 Jul 90 16:33:04 GMT
References: <9007171112.AA01140@jerry.inria.fr>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 34


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

Christian,

Our basic assumption for this work is that we will need many specific
mapping entries because the OR Address tree will not be directly derivable
from the DNS tree. For example, in the pilot project here, my X.400
address has an Org of "uw-madison". The components "wisc" and "edu" do 
not appear in my address. Thus, I need a more specific mapping entry
than just C and PRMD.

If you assume that a few general mappings will work, then obviously you don't
need our proposal...

Lets discuss this more in Wisconsin! Have a good flight

Rob