Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.

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,2008:8948372837/zzz


- 2008 is fixed by convention (knowledge of date can sometimes be a  
security leak)
- 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.



Received on Friday, 5 December 2008 13:43:21 UTC