Re: Review of new HTTPbis text for 303 See Other

[resent from the correct address]

lör 2009-07-18 klockan 12:55 -0500 skrev Pat Hayes:

> Unfortunately, this use of 'map' terminology only confuses things even  
> further. Many cases of the denotation relationship between URIs and  
> resources cannot be mapped by any server, if 'map' refers to any kind  
> of computable operation.

And the point is?

HTTP does not care how URIs map to resources (in any terminology, but
see the end for what resource is in HTTP terminology), it's the role of
the server implementers and webmasters/authors to define such
relationships if any.

For some URIs the mapping is trivial and often even 1-1 (but may be
n-m), for some it's less obvious, and for some it may even be
impossible. HTTP does not care. What HTTP cares about is to provide
means for representing this at suitable level of detail as needed for
proper operation of HTTP where the proposed 303 response to GET is one
possible outcome.

HTTP operates with URIs and the representations of resources servers
return in response to requests to those URIs. End of story. Such
accesses MAY render effects outside HTTP (such as items being shipped to
you from a web shop, robots making some move, some electron bouncing
around, a valve opening/closing somewhere etc) but those effects are
outside of HTTP specifications.

In addition it places certain protocol level restrictions on how servers
may behave when there is many possible representations accessible via
the same URI, but that's a different topic.

> No, that is not what I said, and your misunderstanding of what I said  
> is typical of the communication problems we find in these discussions.  
> The relationship of denoting (referring to, naming, being a name of)  
> is, prima facia at least, completely unrelated to issues of resolving  
> on servers. Servers and networks and transport protocols simply have  
> nothing to do with naming,

Good. So what is your argument exactly? At the level, view and context
of HTTP, ignoring the rest of the world.

> The picture given by Richard, and to which I was reacting in the above  
> quote, was this. URIs denote things. The HTTP GET takes a URI and  
> resolves it to a server (not a resource) which responds with a  
> **representation of the denoted resource** attached to a 200 code, if  
> it has a suitable such representation. ("Suitable representation" here  
> has to be given further gloss, as it is a nonstandard usage.)

In the context it simply means that the server is responsible to
determine if there is a representation available suitable to be used
when building the response and what that is if any. HTTP does not really
care how the server decides that.

> That  
> makes sense, given that we further specify that some resources just  
> don't have representations, so the server must issue a 303 code in  
> those cases.

Yes, or to be exact when there is no suitable representation available
to be used for the HTTP response to this request for a valid URI which
do refer to some kind of resource as identified by the server.

> Note that the represented, requested resource itself  
> plays no part in this picture: it is all about servers and  
> representations of resources.

Fully agree.

> Well, part of the passion in these exchanges arose from Richard C's  
> insistence that HTTP said *absolutely nothing* about meanings of URIs,  

And it doesn't. That's part of the application of URIs to something, not
HTTP itself. For most the semantics of such application of URIs is even
outside the URI specifications and solely left to the actual
implementation/application of URIs.

> so I am surprised to hear that the HTTP protocol intends any notion of  
> meaning at all.

Not in my world.

> But more to the point, it is now simply a fact that  
> URIs are used as denoting names on the Web.

HTTP does not really care about this either.

> Published W3C specs require them to play this role.

At the level of HTTP, or at the level of user experience of URIs when
accessed via some user agent?

And what does those unnamed W3C specs have to do with the HTTP
specifications?

> OK, that is good. It would help if that were stated explicitly, since  
> the same server and the same resource can be located/identified by a  
> different URI also. The wording which I was objecting to refers only  
> to resources, so this point is not clear, as the same resource might  
> be identified by several URIs.

The wording is in the context of how a sever can build a response to a
request for a specific URI, with no relevance to requests for other
URIs.

HTTP does not care much if the same resource has multiple URIs, with
just one minor optional exception (Content-Location).

> The suggested wording refers to the 'requested resource'.

Yes, as defined by HTTP. Not in the general English meaning (whatever
that is, I would not know what a "requested resource" is in general
English, or even Swedish for that matter).

> You here are talking about the 'requested URI'.

Yes, as a slight simplification I choose to ignore server driven
negotiation in this discussion, but that's besides the point.

> These are not the same. Which is correct?

In the terminology defined by HTTP the difference between an (HTTP-)URI
and resource is more of a special case, and not related to any of what
you talk about.

resource in HTTP terminology is NOT the general resource of anything you
seem to refer to, but in specific the resource within the server which
holds the information and/or processing required to build a suitable
representation to be used within HTTP (or as close to that you can get).
Yes it's a simplification, but defining or assume anything about
resources anywhere beyond that is outside of HTTP scope and nothing HTTP
cares about and is left to the application of HTTP and/or URIs. HTTP
does not care or imply anything about how those resources map to any
real-world or abstract resources beyond the operation of HTTP.

To quote the specifications:

p1-messaging, 2.1 Uniform Resource Identifiers

        HTTP does not limit what a resource may be; it merely defines an
        interface that can be used to interact with a resource via HTTP.
        
        [and reference to RFC3986 for further details about URI and
        resource in general]

p1-messaging, C. Terminology

        resource 

                A network data object or service that can be identified
                by a URI, as defined in Section 2.1. Resources may be
                available in multiple representations (e.g. multiple
                languages, data formats, size, and resolutions) or vary
                in other ways.

Note: "resource" in 2.1 above refers to the more general RFC3986
meaning, in the rest of the HTTP documents it generally refers to the
HTTP definition of resource.

> > which includes matching the intended
> > meaning of that URI by whatever name scheme the server implements
> 
> No, it cannot possibly do that, in many cases. No implementation of  
> anything is ever going to match anything to Julius Caesar, who has not  
> existed for around 2000 years.

Not what I was talking about, and I don's see what your point with this
is either.

This response was in response to your talk about a resource (in general
terms) having multiple URIs with different meanings. My response is that
it's the servers role to select a suitable representation of the
resource based on the meaning of the URI. A server ignoring such meaning
as defined by the server would be in error with itself. In the terms of
HTTP each of those URIs actually refer to a resource of it's own as they
have different URIs and meaning, even if those resources perhaps are
very closely related.

> Resources aren't sent in response, representations are. Did you mean  
> representation?

Yes and no. The resource to be used when making an HTTP representation
of the requested resource. But see above for the HTTP meaning of
resource in this context.

Regards
Henrik

Received on Saturday, 18 July 2009 20:36:12 UTC