Re: SIMILE PI Call, 27-July-2003, 1200 EST / 1700 BST

I wrote and Kevin responded:

>> 1. A core argument of the Handle System is scalability and 
>> extensiblity beyond DNS. One way to interpret this is, 
 >> whereas the top-level domain of DNS is artificially
 >> constrained (this is the ".com," ".edu," etc. level), the
>> Handle System provides unlimited, self-administering "top-
 >> level domain" equivalents, known as HS "Naming Authorities."
>>  
> I don't buy this argument.  The top level DNS domains are essentially 
> categories, they are analogous to HS preallocating block number ranges 
> for certain classes of naming authorities (e.g. Simile).  That DNS 
> defines certain well known categories, while HS does not only leads to a 
> minor feature distinction; it doesn't fundamenally alter the scalability 
> of either system.  Properly characterized, the HS self administered 
> naming layer should be mapped to the DNS self administered naming layer.

JSE: To some extent, this is what DOI accomplishes: 10.* is granted to 
IDF, which administers everything under 10.* according to its policies. 
The independent entities that IDF assigns this authority to (i.e. 
namespace management under "10.1234/") are called Registration Agencies, 
and operate across institutional boundaries. The most active example is 
CrossRef, but there are several other major ones, with acronyms like 
CAL, TSO, LON, and MEDRA, as well as CrossRef and Content Directions.

BTW, I wouldn't characterize the current DNS top-level segmentation into 
"well-known domains" as "correct", simply arbitrary. It is not clear to 
me how this segmentation is useful...

John and Kevin continue:
>> 2. NA-level self-administration has implications like, the remainder 
>> of the DNS formalisms (second-level domain, sub-domain, etc) are 
 >> unnecessary --- or, more precisely, these formalisms are
 >> defined by the governance of the particular NA and
 >> are not dictated by HS itself. The equivalent of this in DNS
>> would be if .edu, .com, .mil, etc. could set their own rules for 
>> entitlement.
>>
> No, it is as if in DNS the second level domains e.g hp.com, yahoo.com, 
> etc., could set their own rules for entitlement.  As indeed they can, as 
> can any subdomain that they further delegate control to.

JSE: Only if you follow your earlier point, i.e. "properly 
characterizing" (or constraining...) the HS naming authority layer to 
align with the DNS second level...But this is not required within HS!

This *happens* to be how IDF chooses to do business, but it is *not* 
necessary for any other naming worlds to follow suit. The fact is, 
administration levels such as what IDF represents are arbitrary.

Finally, Kevin sez:

> Since DOI depends on HS, if we need to incorporate DOI then we should 
> probably incorporate HS as well.  In the absence of DOI, I don't think 
> that HS adds anything of technological significance to the system that 
> can't be done equally well with DNS.  Technological issues aside, HS may 
> change thought patterns somewhat, or it may represent a newer and 
> therefor cleaner namespace....

JSE: The IDF "party line" is that the DOI is a *naming system* that 
happens to be built upon the Handle System; it does not in fact require 
the Handle System (but might in fact require certain capabilities that 
currently unique to the Handle System)...

Regarding what can and can't be done (with the HS), the core think of 
value that it does is provide a secure way to intrinsically associate an 
aggregation of typed metadata with a globally unambiguous name. This 
association is then administered securely through a single protocol, 
from anywhere. And, if desired, each assertion of the record can be 
authenticated as an intrinsic part of how the system works.

I don't know how, in the current-generation internet naming, to 
accomplish this sort of name/metadata binding "equally well." Yes, of 
course mechanisms can be built to accomplish the same thing. It is the 
intrinsic part that can't be done.

> 
> There is nothing that I can find in HS that is incompatible with 
> Genesis, but I also don't think that it adds anything new.
> 
> Cheers,
> -kls
> 
>

Received on Monday, 30 June 2003 15:18:04 UTC