I hate to burst ignorantly into a discussion I know little about...
but that's what I'm going to do. Forgive me.
Regarding the creation of local URIs for use in APIs requiring URIs: I
want to consider, just as a what-if meant for clarification of
requirements, the use of the tag: URI scheme [1], which appears on
first blush to be a good fit.
Suppose that the desired suffix of the URI is to be zzz. The URI would
look like
tag:widgets-r-us.org,2008:8948372837/zzz
where
- 2008 is fixed by convention (knowledge of date can sometimes be a
security leak)
- widgets-r-us.org is any domain name permitting this use (not
necessarily fixed for all time, but cooperative at least at the time
of the date or year occurring in the URI) (not necessarily bearing any
relation to the client) and
- 8948372837 is a random number, or checksum of something (the zip
file maybe? ...), that is extremely unlikely to collide with anything
anywhere. This avoids information leakage. (This could just as easily
be put in the domain name / email address part of the URI.)
The commitment on the part of the domain holder is extremely weak: the
domain name is only used to avoid collisions with other tag: URIs - no
promises of DNS resolution or persistence of ownership are required.
(Alternatively a similarly hands-off email address could be used.)
The local software would have to know how to look these things up, but
the algorithm would be pretty simple: separate the URI into its parts
using a regular expression, look the archive up in a table, and use
zzz to get the file inside the archive. If you don't want to create a
new local registry, figure out some other identification scheme and
use that in the tag: URI, again being careful not to leak any local
information that shouldn't be known to components that will see the URI.
-Jonathan
[1] http://tools.ietf.org/rfc/rfc4151.txt
