Re: [XRI] Back to XRI

On Aug 5, 2008, at 7:31 PM, John Bradley wrote:
> XRI resolution is about retrieving meta data for resources.   It is  
> not about retrieving resourced http: is about that.

All metadata is information.  Accessible metadata is a potential
resource.  Potential resources given a URI and a deployed retrieval
protocol are part of the Web.  XRI resolution is therefore about
retrieving representations of resources (that just happen to be metadata
about other resources), and whether you do that using a new identifier
or a preexisting identifier is nothing more than an implementation  
choice.

> I have stated this a number of times.  XRI  and XRDS is an  
> extensible way of describing and retrieving those resources.  Our  
> requirement is around extensibility and some other properties that  
> DNS is lacking.

And I'll state again that DNS doesn't work the way you think it does.
The entire XRI effort is based on one faulty assumption after another.

> On the other hand unlike DNS, XRI is not optimized for size,  I  
> would not expect that XRI would be  a good replacement for looking  
> up A records, in most situations.

Right, which is why it won't be deployed as widely as DNS.  The thing
about name resolvers is that they are mostly worthless until they are
fully deployed, and people won't deploy them until they are worth the
cost of deployment.  DNS works as a delegation mechanism because it
must be deployed to make any meaningful use of the Internet.
We are all dependent on DNS so we place a very high premium on
maintaining access to working name servers based on DNS.  At the same
time, we minimize the amount of stuff placed in DNS in order for it
to scale.  That's why most URIs use two-part delegation of name
resolution, because that's what gets us scalable systems.

> Through the HXRI proxy mechanism XRI is better at making that meta- 
> data available to web applications than DNS is.

No, it isn't even remotely comparable.  DNS (or its replacement) will
still be working for as long as the Internet exists.  It is not  
dependent
on any single research effort.  XRI will cease to work as soon as the
proposing companies lose interest.

> One of the things I cant get in http: are the DNS SRV records for  
> XMPP for a given host.

Why would you want that in http?  DNS is an information retrieval
protocol -- just do an SRV query using DNS.  There are some HTTP-to-DNS
gateways, but they obviously aren't intended to scale like DNS.

> Oh yes I could duplicate the information in RDF in some document  
> but what is the standard for that.
> (hint oAuth, openID,  and Google Friend Connect use XRI 2.0  
> resolution of XRDS documents to allow service discoverability)
>
> XRI supports a number of subsegment naming conventions besides  
> native XRI nodes.  You can have a XRI comprised entirely of URI  
> subsegments.
>
> Am I to take it that you are opposed to any proposal that would  
> encode XRI global authority resolution information in the path of a  
> http: URI?

No.  I couldn't care less.  XRDS seriously screwed up in defining XRI.
OpenID could have been deployed far more effectively if it had simply
reused existing information systems directly instead of inventing a
duplication of DNS using HTTP and making an incomprehensible mess of
its documentation as a result.

What I care about is the misinformation being spread about http and
DNS in this crusade to keep XRI alive.

The "http" resolution mechanism is not, and never has been, dependent
on DNS.  The authority component can contain anything properly encoded
within the defined URI syntax.  It is only when an http identifier is
dereferenced on a local host that a decision needs to be made regarding
which global name resolution protocol should be used to find the IP
address of the corresponding authority.  It is a configuration choice.
On my Mac laptop it happens to be /usr/sbin/lookupd:

   The lookupd daemon acts as an information broker and cache.  It is  
called
   by various routines in the System framework to find information about
   user accounts, groups, printers, e-mail aliases and distribution  
lists,
   computer names, Internet addresses, and several other kinds of  
information.

   lookupd keeps a cache of recently requested items to improve system
   performance.  It also implements a search strategy used to find  
information
   from the many information sources that are potentially available to a
   computer.  These include the Domain Name System (DNS), Sun  
Microsystem's
   Network Information Services (NIS),  Apple's NetInfo system, and a  
set of
   files found in the /etc directory.  lookupd also has a channel to  
query
   Directory Services, allowing access to data from LDAP and other  
directory
   systems.

It is actively harmful to the longevity of http names to make the choice
of global name service within the syntax of the identifier.

A metadata service, in contrast, never needs to dereference a URI.
It can simply use the entire URI as a primary key to whatever type
of lookup it intends to make (just as domain names are a primary key
for all the different types of DNS queries).  The identifier does not
imply the type of query.  It is therefore irrelevant to ask how the
http namespace should be carved up to support embedded XRI identifiers;
just ditch the XRI identifiers and lookup any URI in your metadata
service.

> Is it your position that other protocols using http: uri  
> identifiers should not encode other directory information in the  
> path, and treat them solely as opaque name strings?

I think metadata services should use indirect identification rather
than duplication within the identifier space.  But that wouldn't stop
me from providing an HTTP data service that consists of a gateway to the
metadata service.

> If this is the case how do you feel about ARK?
>
> In both HXRI, ARK, and PURL the Authority segment is just used as a  
> placeholder for a proxy for http: scheme computability.  The real  
> sub-scheme authority is encoded in the path.
>
> We are able able to do this without breaking the http: scheme spec  
> though we may well be violating the intent of the spec as perceived  
> by some people.

The path is delegated to the authority -- they can do anything that they
like within it, including hint that it duplicates some other namespace.
But, again, I don't think that this deals with the core issue, which is
that the XRI mechanism needlessly duplicates existing and already  
deployed
mechanisms for information retrieval.

> XRI certainly has a different graph model than http: is intended to  
> have.
>
> Fundamentally we and others want something different from a "naming  
> scheme that
> is delegated hierarchically by association with domain ownership,"
>
> That is why PURL, ARK, XRI and others exist.

No, they all have the exact same properties.  What PURL adds is a  
librarian.
What ARK adds is a set of librarians.  What XRI adds is?  None of  
them are
successful outside their original backers.  None of them are needed.
The identifier simply doesn't need to be changed to achieve  
decentralized
availability.  The Harvest system already proved that back in 1994.

> Despite opinions to the contrary I think that a http: sub-scheme  
> system that can bridge other protocols to http via proxies is  
> valuable,

I think I am fully aware of the value of proxies.  I don't see any value
in standardizing URI path prefixes (what you appear to be calling
sub-schemes).

> There are still open questions about how to do that.
>
> We may never agree on the value that XRI and XRDS add.
>
> I suspect that your position may that HXRI and other http sub- 
> schemes do not provide sufficient interlinking, and no extensions  
> to the existing identifier system should be allowed.

The identifier system is defined to be extensible.  That's why I said
that you are completely missing the point of the TAG's objection if
you think changing the identifier scheme will resolve the objection.

The objection (as I understand it) is that XRI identifiers are not
necessary because they address the same information universe as "http".
Any parallel system of identification is harmful.  Squeezing said  
parallel
system of identification within the syntax of another system of
identification does nothing to solve that problem.

If XRI actually accomplished something outside the scope of HTTP, then
it would be preferred to define an xri URI for that purpose.  The  
problem
is that it doesn't provide anything of value that isn't already deployed
in the form of HTTP services, so it is ludicrous for the W3C to  
recommend
that member companies duplicate their DNS infrastructure or upgrade all
their tools to support yet another variation on distinguished names.
That architecture has been repeatedly shown to be less useful
and no more secure than good old DNS.

....Roy

Received on Thursday, 7 August 2008 01:07:25 UTC