[ppml] Directory Services - Take 2

[Michael.Dillon at btradianz.com]

> > IRIS was primarily created to
> > meet the needs of domain name registries and registrars.
> 
> Actually, both the IRIS and FIRS proposals had the address registry 
> components from the start.  This type of argument can easily be used 
> in the following ways:
>    HTTP was primarily created to meet the needs of HTML (and not XML).
>    LDAP was primarily created to meet the needs of X.500 networks 
> (and not IP networks).

Actually, no. 

HTTP was primarily created to meet the needs of the international
scientific community for sharing research documents, in particular
the high energy physics community.

LDAP was primarily created for corporations who wanted to provide
IP network access to directories that were on non-IP protocol networks.

In both cases, the protocol was created to serve the needs of 
a group of PEOPLE. And in both cases, the application of the
protocol spread to meet the needs of a more general population,
i.e. all people who want to share any kind of documents, and all
organizations who want to publish directories of any type.

IRIS (formerly called FIRS) hasn't even gotten to first base yet.
And although the architects did envisage IRIS spreading slightly
beyond the domain name registrar community, that doesn't mean that
anyone has proven that it will meet those needs.

Actually, given the fact that someone whipped together a working
prototype of LDAP-based FIRS in a couple of days, I wonder why
people continue to chase this overly narrow protocol. Wouldn't 
it make more sense to develop an XML directory access protocol
that provides XML-encapsulated access to directories that are
currently stored in LDAP backends? In my opinion, there is 
absolutely no real-world need for IRIS that couldn't be met
by a more generic XML-encapsulated protocol.

Seems to me that the two main arguments against LDAP are that
some people find the wire-encoding used by LDAP to be ugly.
So why not create XDAP and replace ASN.1 with XML? That separates
the schema design from the protocol. And the second thing
that people have against LDAP is that it uses a hierarchical 
data schema (rather similar to RIPE and RPSL and SNMP) that is 
rooted in some ANSI/ITU top level. That was solved a long time 
ago by hanging things off of a branch registered by the IETF. 

I know this is veering a bit far from stuff that should be
written into ARIN policy, but this list is the only place 
I know of to provide public input to the ARIN BoT, ARIN staff,
and ARIN AC. The BoT and the staff do have a certain amount
of freedom of action to improve things without policies having
to be written and I would like to think that when they see
ideas expressed on this list, they at least give those ideas
some consideration as they put together thier own roadmaps
for the future.

Speaking of which, what is the future of ARIN in an IPv6
world? Do we close up shop? Or is the coordination and
communication and publishing role of ARIN still something
valuable which we should develop further?

--Michael Dillon