Re: TAG has resolved httpRange-14

How does this resolution interact with the legacy use cases that we have?

<TAG type="RESOLVED">

That we provide advice to the community that they may mint
"http" URIs for any resource provided that they follow this
simple rule for the sake of removing ambiguity:

    a) If an "http" resource responds to a GET request with a
       2xx response, then the resource identified by that URI
       is an information resource;

    b) If an "http" resource responds to a GET request with a
       303 (See Other) response, then the resource identified
       by that URI could be any resource;

    c) If an "http" resource responds to a GET request with a
       4xx (error) response, then the nature of the resource
       is unknown.

</TAG>

DC?    (case b?? or what)
Foaf?  (case a and fails???)
cc?    (case a and fails???)
.... ?

We could ask that the "is" (which I read as "MUST be") in case a is 
weakened to a "SHOULD be"

Does this address the mobile bandwidth issue?
       Would each of Patrick's resources require a GET with a 303 
response and then another GET to access the metadata at the OTHER
Also I note that RFC 2616 says ...

   The 303 response MUST NOT be cached


Will it address the wordnet separation issue?

What about ontologies (possibly infinite) that are separated using a 
server side script with URI likes http://example.org/foo.php?key=fred, 
where as fred ranges over some infinite set of integers the intent is 
that we get an infinite set of interesting resources and some means of 
getting metadata about them?

I don't think I'm convinced that this resolution addresses our use cases.
Anyone care to convince me otherwise?

Jeremy

Received on Thursday, 30 June 2005 10:27:44 UTC