RE: Comments on 26 August draft

Hi Tim,

A couple of comments on your comments. Apologies if you picked these up
during yesterday's telcon.


> This is getting there.  A large proportion of the following are calls 
> for subtraction :)

:-)

<snip>

> ==============================
> 
> 2.2.1 first para "One interacts with a resource through 
> representations...".  No, when I do an HTTP put to move a robot, no 
> representations are involved.  One *retrieves* representations.
> 
> ==================================

Hmmm.... not sure. I'm prepared to think of the bits that go over the wire
as being representations of resource state regardless of whether they are
being got or put (or posted - although that has more subtelties). Granted,
the language in RFC2616 around what the entity body of an HTTP PUT request
is feels  a little awkward,...

RFC2616 Section 9.6 3rd paragraph:

   The fundamental difference between the POST and PUT requests is
   reflected in the different meaning of the Request-URI. The URI in a
   POST request identifies the resource that will handle the enclosed
   entity. That resource might be a data-accepting process, a gateway to
   some other protocol, or a separate entity that accepts annotations.
   In contrast, the URI in a PUT request identifies the entity enclosed
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   with the request -- the user agent knows what URI is intended and the
   ^^^^^^^^^^^^^^^^
   server MUST NOT attempt to apply the request to some other resource.

...but I think the only reasonable interpretation is that the entity body is
a representation of the state that resource identified by the request URI is
being asked to take on. I think it would be ok for client to PUT say a jpeg,
or a png representation of an image and for the server to generate
'equivalent'  gif, tif etc. representations of that same resource.


To be concrete on the wording of the opening of 2.2.1, how about:

"One interacts with a resource by the exchange of representations of the
state of the resource."

That said, I think this statement doesn't feel like it is applicable to all
URI schemes. It doesn't feel right for, say, telnet: or mailto: resources.
These may be anachronisms, but the document is still talking about URI in
general and has not yet started to be scheme specific.

<snip/>

> ==========================================
> 
> 2.3.1  There's a problem here.  As the section points out, 
> file:/etc/passwd is highly context-sensitive, but then it says it's OK 
> to use it if you're confident you're on the right operating system? 
> I.e. you claim the concept of the resource is "this computer's password 
> file"?  I think this sucks, and I think what we're trying to say is that 
> you *shouldn't* use this kind of thing outside of a single-computer 
> environemnt, i.e. you shouldn't EVER publish file:/ URIs on the Web
> 
> ===========================================

I think we need to be careful about this one. I made some mistakes about
file: URI earlier in a thread on context independent URI [1,2].

file: URI can have an authority part [RFC1738] eg.
file://example.org/etc/passwd and indeed the authority can be an Internet
Domain Name... so as it was pointed out to me, the file: scheme is no more
or less context dependent than the http: scheme.

I think that the kind of URI that we're trying to discourage are URI that
dereference different resources depending on the context in which they are
used. So, http://localhost/index.html would be as good (or as bad depending
on POV) as file:/index.html or file://localhost/index.html.

I think the concept of "valid use" of an absolute URI does need explaining
(and agreeing upon:-)) in that the use of an absolute URI that does not
always and without ambiguity identify the same resource may be said, by
some, to be an invalid use of such a URI. You picked this up in one of your
other comments [i think].

Cheers,

Stuart
--
[1] http://lists.w3.org/Archives/Public/www-tag/2002Jul/0238.html
[2] http://lists.w3.org/Archives/Public/www-tag/2002Jul/0247.html

Received on Tuesday, 27 August 2002 12:40:23 UTC