On Thu, Jul 06, 2017 at 11:15:34AM -0400, John C Klensin wrote:
--On Thursday, July 6, 2017 00:36 -0400 Phillip Hallam-Baker
<phill(_at_)hallambaker(_dot_)com> wrote:
The X.500 and UDDI models were broken because there is no
point in putting information into a directory if the service
can return it in a service handshake.
The X.500 and UDDI approaches failed because... sorry, I lost
count of the reasons :-(
The complexity and general ugliness of x.400/x.500 naming (indeed, the
inability to correctly and canonically represent such names in TEXT!)
are all the reason anyone ever should have needed. (See what I did
there?) And yet some bits of that horrible thing are still with us
(PKIX, LDAP), though of course with various adaptations (eg, SANs) to
make them suck less and more Internet-like.
DNS is not a directory, but when your only off-the-shelf choices are DNS
or LDAP...
I'll contribute this extension to your earlier argument about root
sharing/non-sharing. I think new classes will only ever be feasible
provided that a) they share roots with IN, or b) are like a local HS not
really meant to federate at all (thus root sharing / alt. roots would be
moot). (a) classes would basically be an RR type extension field for
IN. (b) is probably not worth considering -- the lack of security in HS
was a big reason for not using it, and so DNSSEC (or something like it)
would be a requirement in order to use an HS-like class, but if you'll
want DNSSEC then you'll want delegation hierarchy anyways and thus
you'll want shared roots, making any HS-like classes just IN-class RR
type extension fields. It's easier to develop a new protocol for (b)
than to shove whatever it is into DNS.
So new classes will only be useful to extend the IN-class RR type
namespace. We won't get there. New RR types can be very difficult to
deploy due to lack of interest by registrars and domain hosting
services. TXT RRs forever. :(
Cheers,
Nico
--