Subject: Re: [p2p-hackers] Re: draft-thiemann-hash-urn-01.txt

From: Benja Fallenstein <[email-masked]>
Date: Fri, 05 Sep 2003 22:56:40 +0300

Bryan Ford wrote:
> Benja Fallenstein wrote:
>>So what *would* specify it? The point of having a central registry for
>>URI schemes, URN namespaces and so on is that you can go to that
>>registry to find out which specifications apply to a given URI. Who
>>specifies what format the remainder has and how it is to be interpreted?
> 
> 
> For clarity let's call the proposed "remainder" portion of a hash-based URN a 
> "relative name".  The relative name simply identifies a logical "portion" or 
> a "subcomponent" of the whole object indicated by the <hash-value>.  Since 
> the whole object can only be meaningfully interpreted in terms of its 
> content-type, whoever specifies a particular content-type is responsible for 
> defining the interpretation of relative names for objects of that type.

Hm. Ok, based on content type-- I understand better now.

But hey, why not use fragment identifiers? They seem to be *exactly* 
what you're looking for? And they work on *all* URI schemes.

(Note that fragment identifiers are, according to current 
interpretations, somewhat misnomed: They need not identify a "fragment" 
of the data behind a URI, but can identify anything, as specified by the 
content type. E.g. RDF specifies that fragids can identify absolutely 
anything-- including cars, people and so on.)

So you could define application/file-system-root, and say then use e.g.

urn:hash:application/file-system-root:sha1:LBPI666ED2QSWVD3VSO5BG5R54TE22QL#/foo/bar/blah

Then you could also make that data available through, for example, HTTP:

     http://example.org/myfiles#/foo/bar/blah

What do you think, does this address what you want?

- Benja

---

From: Bryan Ford <[email-masked]>
Date: Fri, 5 Sep 2003 15:01:38 -0400

Benja Fallenstein wrote:
> Bryan Ford wrote:
> > Secondly, your draft as written seems to imply that a hash-identifier URN
> > can contain _nothing_ but the media type, hash scheme, and encoded hash
> > value. This implication neglects important potential (and likely)
> > applications of this scheme in which the hash ID is used as a
> > _starting_point_ from which to find something else via a more
> > conventional naming strategy.  For example,
>
> ...
>
> > 	urn:hash::sha1:LBPI666ED2QSWVD3VSO5BG5R54TE22QL/foo/bar/blah
>
> ...
>
> > Of course, the meaning of whatever comes after the hash-value, if any,
> > can only in general be determined with respect to whatever object the
> > hash-value specifies, so your specification cannot and should not really
> > specify anything about the precise format of this "remainder" part of the
> > URN.
>

For clarity let's call the proposed "remainder" portion of a hash-based URN a 
"relative name".  The relative name simply identifies a logical "portion" or 
a "subcomponent" of the whole object indicated by the <hash-value>.  Since 
the whole object can only be meaningfully interpreted in terms of its 
content-type, whoever specifies a particular content-type is responsible for 
defining the interpretation of relative names for objects of that type.  Not 
all content-types need to define such interpretations: if the content-type 
specification doesn't define an interpretation for relative names, then 
relative names are undefined and should not be used in URNs for objects of 
that content-type.

It might make sense for Peter's hash-based URN specification to define 
specific interpretations of relative names for a few existing 
well-established content-types, such as "text/html" and "message/rfc822".  
But in general specifying the interpretation of relative names for a given 
content-type should be left  to whoever specifies the content-type, or to 
follow-on RFCs related to that content-type.

Cheers,
Bryan

---

From: Bryan Ford <[email-masked]>
Date: Fri, 5 Sep 2003 19:39:59 -0400

Benja Fallenstein wrote:
> > For clarity let's call the proposed "remainder" portion of a hash-based
> > URN a "relative name".  The relative name simply identifies a logical
> > "portion" or a "subcomponent" of the whole object indicated by the
> > <hash-value>.  Since the whole object can only be meaningfully
> > interpreted in terms of its content-type, whoever specifies a particular
> > content-type is responsible for defining the interpretation of relative
> > names for objects of that type.
>

After reviewing RFC2396, I see what you mean.  Since fragment identifiers are 
formally not part of a URI but merely part of a URI-reference, they can be 
attached to any URI, and their interpretation depends on the content-type of 
the object referenced by the URI - so far so good.  But on further analysis I 
see some serious problems with this approach.

> anything-- including cars, people and so on.)

True, but one (minor) problem is that they are at least _syntactically_ 
constrained - in particular, since they can only contain "URI characters" 
(*uric), and '#' isn't a URI character, the fragment identifier can't contain 
another '#', and so fragments aren't conveniently hierarchically composable.  
Adopting your syntax, suppose we want to name a fragment of an HTML file in 
an SFSRO-like file system of some kind.  The following natural syntax for a 
URI-reference is technically invalid because of the second '#':

	urn:hash:application/file-system-root:sha1:LBP...22QL#/foo/bar.html#sec1

Admittedly we could just require that the second '#' be escaped (which is why 
I call this a "minor" problem), but then if we ever get into a situation 
involving further compositions, we'd have to escape the third '#' twice, the 
fourth '#' three times, etc., which gets seriously obtuse.

The more serious problem arises when we consider the interactions with the 
relative URI resolution procedure as specified in section 5 of RFC2396.  
Suppose the file "bar.html" referenced above contains a hyperlink using the 
relative reference "blah.html".  What we _want_ to end up with is:

	urn:hash:application/file-system-root:sha1:LBP...22QL#/foo/blah.html

...but we won't, because the fragment part in the former URI-reference is not 
even considered part of the "base" URI, so the "/foo/" path gets incorrectly 
chopped off before we ever have a chance to append the "blah.html".  It's not 
even entirely clear to me what exactly happens according to the formal 
definition of the procedure, but whatever it is, it's not what we want.

It might be argued that URNs aren't supposed to have hierarchical path 
components at all, because hierarchical relationships imply location.  
(RFC2141 seems to imply this philosophy, since it defines the '/' character 
as "reserved" and makes no mention of if or how hierarchy is to be allowed 
for in the namespace-specific string portion of a URN.)  But I don't think 
that abstract hierarchical relationships necessarily imply anything about 
_physical_ location or access method, and physical locations and access 
methods are the things we're trying to get away from with URNs.

Take the case of a read-only, forever-immutable SFSRO file system-like tree 
structure.  Once you've identified the root of the tree with a fixed hash 
value, whose target will never change, you know that nothing else in the tree 
that you may find starting from that hash value will ever change either, 
however you may choose to walk through the tree and find data blobs 
representing the various directories and files.  Being able to name objects 
within the tree in a hierarchical fashion and use relative identifiers within 
it remains incredibly useful and compelling.  Hierarchical naming of this 
form does not break the URN model, because the hierarchical "locations" that 
these relative references refer to are completely abstract locations that are 
guaranteed never to change and have nothing to do with physical location or 
access method.

I really think this problem of hierarchy needs to be addressed somehow, 
although the best solution is not obvious to me given the apparent syntactic 
incompatibility between the definition of the "urn:" scheme and the 
hierarchical URI syntax.  If this problem isn't addressed, I fear that 
hash-URNs will only ever end up being used to name huge "packaged" data 
objects like downloadable zipfiles, tarballs, install images, and so on, 
because using them to refer to any more fine-grained data objects will just 
be too inconvenient to bother with.  For example, suppose you want to publish 
a whole web site, containing a bunch of little html files, images, etc., in 
"hash-URN" fashion...  Do you first have to walk through every html file in 
the tree (and everything else that may contain links) somehow and replace all 
the relative URIs with absolute URNs, and then assign and publish each 
individual file as an object, before anything will work?  If so, even with 
automated tools, I suspect few people will bother using hash-URNs this way 
simply because it requires changing the contents of the files being 
published.  If URNs are designed so that hierarchical relationships can be 
preserved when trees of objects are published and assigned permanent names, 
however, then it becomes much easier to move a whole tree of interconnected 
objects from "URL space" to "URN space" - perhaps without even changing a 
single file.

Cheers,
Bryan