W3C home > Mailing lists > Public > public-awwsw@w3.org > May 2008

RE: network endpoints

From: Williams, Stuart (HP Labs, Bristol) <skw@hp.com>
Date: Thu, 1 May 2008 09:27:09 +0000
To: Pat Hayes <phayes@ihmc.us>, Jonathan Rees <jar@creativecommons.org>
CC: Tim Berners-Lee <timbl@w3.org>, "noah_mendelsohn@us.ibm.com" <noah_mendelsohn@us.ibm.com>, "public-awwsw@w3.org" <public-awwsw@w3.org>
Message-ID: <9674EA156DA93A4F855379AABDA4A5C611CE9EE1BB@G5W0277.americas.hpqcorp.net>
Hello Pat,

I was wondering how you respond to the notion of attributing agency/action to the infrastructure of the web itself. Grant that in some sense the (http?) web infrastructure is able to inspect the 'state' of some things and report on it when asked. By web infrastructure I mean some aggregregation of origin servers (backed by app servers, databases, filing systems etc) and proxies/caches. Any given user agent (software) experience 'the web' via the requests it makes and responses it receives via some local API. I was suggesting to Jonathan not to attribute behaviour in a fine-grained way to the 'mechnical' artefacts that make up web infrastructure - but to a coarse-grained agreegation of all of those artefacts as perceived by a given UA. Not least that avoids having to account in detail for caching behaviours where a given request may never reach the relevant origin server.

Jonathan, would it work for your purposes to give an account of the kinds of requests and responses that the web infrastructure must/should support/provide for some variety (you choose) of resources/things to be correctly deployed on the web.


Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

From: Pat Hayes [mailto:phayes@ihmc.us]
Sent: 01 May 2008 01:38
To: Jonathan Rees
Cc: Tim Berners-Lee; noah_mendelsohn@us.ibm.com; Williams, Stuart (HP Labs, Bristol); public-awwsw@w3.org
Subject: Re: network endpoints

At 4:05 PM -0400 4/30/08, Jonathan Rees wrote:
On Apr 30, 2008, at 1:55 PM, Tim Berners-Lee wrote:
Real, you said, you wanted to connect to something real. Hmmm.
I don't find the abstraction of the 'network endpoint' associated with e resource to be any more real.  I find creating new abstract concepts is only useful when it gives us something which we didn't have before hang a lot of common meaning off.  In this case, we have the abstraction of the resource, and we do have a server which has a role in the HTTP protocol, and is controlled by the domain name owner, and so on.  I don't se a use for some concept like "that in the server which corresponds to this resource". If the resource is served up by a php script common to millions of resources on the server, I can't see the 'reality' of the network endpoint.

The server, though, is something closer to real.  It is actually the thing which responds with a 200. It has a domain name, port, etc.  It actually is in that sense a network endpoint - a transport level endpoint.  (The server host is a network level endpoint).

If you like, a resource is a web thing, and a server is a transport thing.   I don't see a need for the endpoint you describe.


I might have talked about servers, but was discouraged from doing so by Stuart and Noah. So I just said "the web" and "the web's behavior at U" as a standin for all the router, cabling, DNS, caches, servers, mirrors etc. apparatus that we use when we do GETs on U, to avoid the need to analyze all those things in detail. It is real in a sense that, say, numbers and functions aren't. An IR defined to be one whose awww:representations convey the declaration of US independence isn't real in the same way since it would have those awww:representations regardless of what happened on the web.

I thought I had heard you say that an information resource is an abstract document that might or might not be on the web, and that the URI names that resource, not what some server happens to do. Due to the wonders of URI ownership, it turns out that what the server does is (usually? always?) to give you awww:representations of the resource, but there are possible worlds in which this is not true. The point of giving a semantics is to rule out those other worlds. I will create as many "abstract concepts" as I need to in order to nail down a semantics that works - a different model for each TAG member if necessary. I'm sorry you don't understand the need for this - to me it is pretty important since it should tell me when a 200 response is allowed and when it isn't, something I don't understand right now.

To say that the information resource *is* a web thing is fine too - that would be the top box on my diagram - although it contradicts some other things you and others have said. I'm just trying to figure out what the intended semantics is. At this point I'm so confused that I don't care what it is, so long as it is defined clearly enough that I can understand it and its consequences.

This point (web-independent abstract document and real web thing are different but related things) seems to be very difficult to grasp - I know I've tried to make it many times in email without success. Perhaps someone else can help me out here, or maybe we should find a time to talk about it in person.

It seems pretty clear to me, for one. An abstract document isn't the kind of thing that can be expected to do anything. Documents - and abstract documents even more so - cannot act. In particular, it can't respond to GET requests (since it can't respond *at all*), it can't emit representations, and it can't make decisions about http codes. So whatever does all this stuff (and something surely does, or the Web wouldn't work) isn't an abstract document. So what is it?




IHMC               (850)434 8903 or (650)494 3973   home
40 South Alcaniz St.       (850)202 4416   office
Pensacola                 (850)202 4440   fax
FL 32502                     (850)291 0667    cell
http://www.ihmc.us/users/phayes      phayesAT-SIGNihmc.us
Received on Thursday, 1 May 2008 09:32:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:21:06 UTC