RE: network endpoints

Stuart Williams wrote:

> > [Jonathan Rees wrote:]
> 
> > I'll make the change in a day or two or three if I hear no outcry.
> 
> I guess consider this a little cry out :-)

Sorry for not chiming in earlier, as I've been traveling.  Anyway, I'm 
afraid I agree with pretty much everything Stuart is saying here.  I think 
the system is best thought of in layers.  When you refer to endpoint, I 
presume you mean something that has some sort of persistent existence 
across HTTP interactions.  At the layer we're modeling here, I don't think 
such an abstraction needs to be or should be visible, except insofar as 
its already implicit in the notion of resource.  Assume I send a GET or a 
POST out into the network, and something comes back.  According to the 
HTTP specification, and presuming the protocol is used properly, what 
comes back bears some relation to, or affects the state of something we 
call a "resource".  That resource is IMO an abstraction.  It doesn't 
necessarily live at any one point in the physical network, and indeed, 
very distributed implementations are possible.  Whatever software or 
hardware responds to the GET or POST is either taking responsibility for 
having sufficient knowledge of or control over the identified resource, or 
else in the case of a response like a 404 is explicitly saying that it 
cannot do so.  I think that's all we need to worry about at this level. 
Talking about endpoints here seems like level mixing, or perhaps I'm not 
correctly understanding what you mean by the term "endpoint".

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








"Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>
Sent by: public-awwsw-request@w3.org
04/17/2008 10:01 AM
 
        To:     Jonathan Rees <jar@creativecommons.org>
        cc:     "public-awwsw@w3.org" <public-awwsw@w3.org>, (bcc: Noah 
Mendelsohn/Cambridge/IBM)
        Subject:        RE: network endpoints



> -----Original Message-----
> From: Jonathan Rees [mailto:jar@creativecommons.org]
> Sent: 17 April 2008 13:46
> To: Williams, Stuart (HP Labs, Bristol)
> Cc: public-awwsw@w3.org
> Subject: Re: network endpoints
>
>
> On Apr 16, 2008, at 12:55 PM, Williams, Stuart (HP Labs,
> Bristol) wrote:
>
> > Hello Jonathan,
> >
> >> -----Original Message-----
> >> [mailto:public-awwsw-request@w3.org] On Behalf Of Jonathan Rees
> >>
> >> One thing I would like to add to my diagram: A box for "network
> >> endpoint" with the meaning of a real-world source of
> >> awww:representations (e.g. a "web page" operationally defined by the
> >> process of sending an HTTP request specifying a particular resource-
> >> name string to a particular server, using the Internet, and so on).
> >
> > Oooohhh, I'd really rather that you didn't - not unless you really
> > really have to.
>
> I didn't mean to say I wanted to analyze network or protocol
> phenomena in depth. I just want to put "the web" onto the diagram
> somewhere - right now the diagram is completely detached from
> reality, as there is no arc that connects abstract entities such as
> IRs and value clouds to real world phenomena such as the web.  I
> think I accept the same "the web" abstraction as you, and that the
> things I'm looking for are simply the specialization of "the web" to
> a particular URI. Let me take a crack at saying what this "the web"
> idealization is:
>
> let U = a URI, p = additional request parameters (such as Accept:), t
> = a time, V = a ft:value
>
> Submit a request (what in HTTP would be GET) for a
> awww:representation to "the web", using U to identify the
> awww:resource, at time t, specifying parameters p, with a successful
> result V, on a web W:
>
> webget(W,U,p,t) = V

Ok... though (see below...) I might allow different result types

  webget(W,U,p,t) = V \ {V,U'} \ U'

  V being normal 200 returned values.

  {V, U'} being 200 conneg'd values where U' is the URI for the
  corresponding variant obtained from a Content-Location: header
  (which may be gratitously present).

  U' arising from the :Location header of a 30x redirect response.

> This would be true if, for example, the protocol used is HTTP and the
> response is a 200.

yes...

> There may be other things you can do with W but this is the one we
> care about.

yes... I have wondered about a deep space probe landing on a far distant 
planet and beaming back an image of "http://www.google.com" carved into a 
rock face.

> I hope this idea matches the entity "the web" that you're
> talking about.

Yes I think so.

> As for 'network endpoint', all I'd like to see is the specialization
> of webget to a particular W and U. We can fix W for the purposes of
> the entire diagram (since there is only one that we care about). For
> each URI U I posit a thing E(W,U), the logical endpoint of U (or
> whatever we choose to call it so that it doesn't misevoke) on W,
> satisfying
>
> get(E(W,U),p,t) = webget(W,U,p,t)
>
> I hypothesize that this is the class that David Booth has talked
> about as "network source of representations".

Well ok... but I remain to be convinced that we'll have very much to say 
about these
E(W,U) things - though maybe since host->ip mappings etc change, it may 
need to be E(W,U,t).

> Now why such an artifice? Because it helps the diagram giving another
> thing for URI to map to (U has endpoint E(W,U), or class URI maps to
> class endpoint), and another thing that, like Value Cloud, has the
> potential to be faithful (in some way) to some IR. It's also helpful
> notationally in RDF and OWL since there are no n-ary predicates. (We
> have to do the same kind of "at time t" with these that we did with
> IRs and value clouds.)

ie. we need some bits of, possibly blank node, scaffolding in order or 
create n-ary predicates (i guess by extension).

> I imagine this 'webget'/'get' function hides 301/2/7 redirects behind
> the scenes.

Oh... another hobby horse... I'd rather that you didn't :-)

When you follow say a 303 and then get a 200 and a awww:representation the 
agent that did the following made a conscious decision to do so and 
performed a distinct webget operation using (see above) U'. I think that 
by respecting both operations as distinct we get to say things about both 
U and U'.

> To go one level of analysis deeper, instead of GET of a
> request (URI with parameters p) yielding a ft:Value (200), we talk
> about the more fine grained relationship of a request to an
> http:Response, and then we get to talk about redirects. Then we say
> how 'get' relates to the request/response relationship, which is
> where we were before.

I think that's sounding close to the 'model' I sketch in my homework item 
a few weeks back - though I only covered the 200 case.

> Yes, I agree we needn't talk about proxies,
> caching, or 404 at this time.


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

Received on Friday, 25 April 2008 14:33:51 UTC