RE: LDAP/X.500 location proposal (was: DN -> DNS: X.500 group's p roposal for using DNS to locate LDAP servers)

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 09:51 AM 3/27/01 -0500, Slone, Skip wrote:
>Kurt,
>
>A couple comments related to your most recent response...
>
>First, if we back up and look at the requirements (which haven't yet been
>fully articulated), we see a need to do lossless (or at least nearly
>lossless) mapping between RDNs and FQDNs. Even if we limit the set of RDNs
>we consider to, say, the subset that PKIX requires (not even the larger
>subset permitted by PKIX), we find that the currently defined RR types
>(namely A and CNAME) are insufficient, since those RRs are limited to the
>character set specified by RFC 1123.  (For reference, that set includes "A"
>through "Z", "a" through "z", "0" through "9" and the hyphen. Periods are
>permitted, but are treated as label separators.) Looking at what we might
>choose to call "reasonably well-constructed RDNs," I think it's reasonable
>to assume we will need, at a minimum, a character set that also permits
>apostrophes, periods, commas, and spaces. In order to do lossless mapping,
>it is necessary to EITHER define an RR type with a compatible character set
>OR define an escaping mechanism.  Since I'm hard pressed to even find a
>reasonable escape character in the RFC 1123 set, I'm led to the conclusion
>that it would be simpler to define a new RR type for this purpose.

Look at IDNa work.  I would suspect one of the numerous ascii
compatible encodings which likely could be used... likely base32
is usable.

>Second, regarding where this thing gets rooted, I again look at the
>requirements. One such requirement is the availability of a suitable (i.e.,
>scalable, distributable) registration infrastructure.  By this I mean a
>(mostly non-technical) set of supporting structures including registration
>authorities, processes, rules, administrators, and so on. Given that we need
>such an infrastructure, we have a choice between (1) defining a new
>infrastructure and (2) using an existing one.  If we define a new one, we
>can either define a new one rooted somewhere under the DNS structure (as
>you've suggested), or we can define one external to DNS (as X.500 suggested
>back in 1988).  Since the X.500 suggestion never took root (pardon the pun!)
>in the past thirteen years, I'm led to the conclusion that we're not likely
>to succeed if we go down that path.  That leaves option 2 (using an existing
>infrastructure) as the most viable. The only existing registration
>infrastructure that I know of is the TLD-rooted DNS registration
>infrastructure.  

I think you really need to look at this from who "owns" what
information.  ITU "owns" the X.500 root.  They should control
the DNS mapping "root" which maintains glue for the X.500. They should
be able to delegate control to RDNs under the root to appropriate
parties.  For example, they should be able to delegate the 
approrpriate subdomain under the DNS mapping root to ANSI for
"c=US".  ANSI should be able to delegate the appropriate subdomain
for "o=Example,c=US" to whoever "owns" it.

Your root approach doesn't delegate authority properly.  It
delegates control to add top level RDNs to ICANN, and second
(and third and fourth?) level RDNs to the TLD registries.  This
is, I think, not the appropriate delegation model.  These
registries have zero clue on how to ensure proper assignment.

I believe an approach similar to what I offer can be delegate
the control to the vested parties, the same parties which
already have infrastructure to register X.500 context prefixes.

Now, if you are actually try to deal with unregistered X.500
context prefixes, I think you would have a VERY hard time
getting the IESG, IAB, ICANN to take on yet another registration
rat hole.

>Having said that,
>I'll say that I don't think LDAPext is the appropriate forum for discussing
>whether the TLD operators are likely to take on the task.

You should discuss introduction of new RR and other DNS extensions
in DNSext.

You should discuss introduction of operational considerations in
DNSops.

Kurt