Re: [OT] RE: Using URIs to identify non-information resources

Benjamin Nowack wrote:

>
>>The same is true of thing-described-by.org.  Anyone can offer a similar
>>service, though obviously better optimization is possible if there are
>>fewer such sites to recognize.
>>    
>>
>so you *are* proposing a centralized service. 
>  
>
Yep. I'm also very uncomfortable with the idea of bottlenecking the
identification of all non-"Information Resource" entities through
a handful of HTTP-based services.

To be very clear here, we are talking about *billions* of
objects. Look at the marketplace for RFID-based services.

>>I don't think that's quite correct.  If you are given an arbitrary http
>>URI that you have not seen before, and you want to determine whether it
>>is being used to directly identify a Web page at that address or
>>indirectly identify something else, it seems to me that you MUST perform
>>an HTTP access on that URI to find out whether it returns 2xx (meaning
>>it directly identifies a document at that address) or 303, meaning you
>>need to look elsewhere to learn what it identfies.  However, if you are
>>given a thing-described-by.org URI, you can determine by inspection that
>>it does not directly identify a document at that address, because of the
>>delegation of authority provided by thing-described-by.org:
>>http://thing-described-by.org/#Delegation_of_Authority
>>That is a significant optimization.
>>    
>>
That assumes knowledge of the 'http://thing-describe-by.org' rules
in the first place. And if thing-described-by.org is not to be
alone in the world, we'll need some way of finding out other equivalent
services. I'm skeptical.

>yeah, but you are proposing it as a service, not as a technique/practice.
>and I actually think it'd be more straight-forward to simply tell people
>how to adjust their htaccess files to make the 303 mechanism work
>directly on their systems. but maybe that's just me.
>  
>
That's the core of my concern too. It is a centralised service,
with all the associated risks. How long do we expect the service
to be maintained for? (10 years? 20? 50?). What procedures
are in place to ensure the domain name fees are paid on time
during that period?  The service at thing-described-by.org:80
currently seems to be running Apache/1.3.29 while
http://www.apache.org/dist/httpd/Announcement.html suggests
that this ought to be upgraded to at least 1.3.33. From a quick
skim of http://www.apache.org/dist/httpd/CHANGES_1.3 there
don't seem to be any major security holes since 1.3.29. But who
will skim that list for the next 20 years? Does the Web server
at thing-described-by.org keep logs of any kind? In  particular,
HTTP_REFERER logs risk exposing intranet use of URIs. Does the
service have a privacy policy? Will it ever set cookies? Offer
discrete adverts to pay for bandwidth bills? Offer premium
services for members? If the box is ever compromised, what risks
could that create? (eg. exposure of referer URIs). These are just
a few of the questions we should ask of all centralising Web services,
even if we have great trust in the parties who originally establish
them (as I do in David).

I could go on, ... but I should make clear I'm not beating up on the
basic idea. It's a nice enough approach, if implimented in a decentralised
fashion. Implimented as a Web-wide service, it would need a *lot* more
policy and support structures in place before it could be something
I'd encourage people to use.

Dan

Received on Friday, 19 August 2005 11:55:28 UTC