p2p-hackers: Everything as a file in p2p

From: p2p-hackers@zgp.org (Gordon Mohr)
Date: Tue Jul 16 12:51:02 2002
Subject: [p2p-hackers] Everything as a file in p2p
Aaron writes:
> On Tuesday, July 16, 2002, at 01:07  PM, Gordon Mohr wrote:
> > Also, there's no need to include the actual signature of the name 
> > inside the URI. [...]
> 
> Oh, I guess I misunderstood you -- I actually had the same idea and 
> started on a draft for this several days ago:
> 
> http://www.aaronsw.com/2002/draft-swartz-pgp-urn-00.html (.txt, .xml, 
> etc.)

Yep, very similar.  My two snap comments would be:
 
  - Use "//" -- it's actually valid here, each key *is* the top of
    a  (potentially/usually) hierarchical namespace -- unlike in the
    world of thrown-together P2P URI-schemes (ed2k, sig2dat, gnutella)
    where people are just mimicking "http://" without considering the
    intended meaning.

  - Why artificially limit it to just PGP?  (More below.)

> > Are you suggesting that instead of a parameterized "kau" type, there be 
> > different URI types for each signing algorithm? That just pops the 
> > registration issue up a level, pollutes the URI-scheme namespace,
> 
> How is it pollution?

There are already a dozen or more public-key signing approaches. 
Why should simply wanting to swap in a new name-binding signing 
algorithm require the overhead of a URI-scheme registration? They'll 
all need the same basic namespace-specific-part syntax; encouraging
independent registration increases the risk of drift/idiosyncratic
specifications. 

Also, why use up short-name-tokens that could be valuable with 
other meanings? 

For example,  it would also be plausibly useful to have a URN
scheme named "pgp" which simply retrieves the key from its
fingerprint. That is:

    urn:pgp:4FAC4838B7D8D13FA6D92EDB4145521E79F0DF4B
 
...would mean "the key with this fingerprint". 

Or perhaps, to have a "pgp" URN scheme which means "get me
the signature for this content"  (rather than "the content 
which is suitably signed as having this name). That is:

    urn:pgp:4FAC4838B7D8D13FA6D92EDB4145521E79F0DF4B:sha1:BCLD3DINKJJRGYGHIYAX7HG5HXSM3XNH 
 
...would mean "get me any signatures of this content-hash by
this public-key principal".  

Perhaps these sorts of uses could be mixed-into your proposal. 
(That last one would implies an interesting reverse-lookup
capabilitiy.) But whether they are or not, they emphasize that
the short string "pgp" could serve many uses as a URI-scheme;
why not explicitly qualify its meaning as being the specification
of a "key-named authority"?

> > A software module need not understand the algorithms  to be useful; a 
> > DHT-based library might have a rule for finding the nodes responsible 
> > for certain "kau:" entities without knowing the algorithms in use.
> 
> I would hope such a library would be able to handle any URI, not just 
> kau ones. If it doesn't understand the signature algorithm, why does it 
> care if it's associated with a key or not?

In some cases, it might be nice for such a library to treat all URIs
as opaque identifiers.  But in others, better behavior might be possible
by understanding which class of identifiers a certain URI belongs to. 

For example,  it might aid in maintaining locality of reference to 
recognize all the names related to a certain key-naming-authority,
even if you don't interpret that key-type. 

And what if someone wants to build a system where all content must
be key-named?  They want to accept any and all "kau"ish URIs, no
other URIs. That task is easier if all "kau"ish URIs are labelled
as such, even if they are new signing algorithms unregistered when
the software was deployed.

> > You don't even really need a formal IANA-type registration  procedure 
> > when your universe of possibilities is small, and all people who might 
> > be choosing conflicting tokens can easily find each other.
> 
> This may be true, but sort of defeats the purpose of the URN 
> standardization process. The idea is to have a central registry where 
> people can get the correct answer and know that it's correct. Not just 
> guess based on common techniques. Furthermore, they should be able to 
> find the definitive specifications for all these hashes and formats by 
> following links to specs. If you want something less formal, why not 
> carve out a bit of HTTP space?

I'd agree that's the ideal of a centralized registry.  But people don't 
always respect (or share) that ideal, especially if there are few 
consequences to ignoring the authority and/or it's easier and 
sufficient to do things in a more slapdash way. Things fall apart...

> Google is simply another form of centralized storage and query, although 
> the input method is different and less structured. Even if we switch to 
> a totally decentralized system like a DHT, the fundamental need of 
> having a clear way to state "X is controlled by Y and specified in Z" 
> won't go away. I'm not the most fond of IANA or their "parent" ICANN, 
> but they do provide a useful service. Using Google to see if anyone has 
> registered a URI scheme called "the" is rather difficult without 
> consulting a specific registry.

Being a devil's advocate: then don't use "the", even if the registry
says it's OK. Someone might be using it unregistered.  And you'll
want people to find your usage, even if they don't check central 
registries, so it's a bad name anyway.

Actual usage -- and the "common knowledge" of prevalence -- counts 
more than formalities anyway. 

> BTW, was urn:sha1 ever registered? I don't see it at: 
> http://uri.net/urn-nid-status.html

Not yet registered. Needs to be, but I don't know when I or someone 
else will get around to it. 

- Gojomo