Subject: RE: Translation in the Tower of Babble

From: Yaron Goland <[email-masked]>
Date: Tue, 4 Jan 2000 12:17:37 -0800

So spoke Yves:

> Hum, if you see the proxy as a HTTP resource, The HTTP 
> resource acting as
> a proxy may issue an ftp request then return a HTTP response 
> to the HTTP
> client", so even if it end up being a ftp request, the first 
> HTTP request
> was handled by an HTTP resource.
> No matter how the content is generated, it always an HTTP 
> resource that is
> handling an HTTP request.
> So Precept #1 should use "HTTP resources" and not resources. Also a
> resource may be at the same time an HTTP resource, and answer 
> according to
> another protocol.

I think the issue here is - does the object model deal with end-to-end or
hop-by-hop? That is, do we want to model a conversation between a client and
server differently just because there is a proxy in the middle? If we do
then I agree that we should change Precept #1 to state "HTTP resources". If
not then we may want to be more vague.

I suspect that we DO want to model hop-by-hop and we DO want to come up with
a simple shorthand for specifying end-to-end operations where the presence
or absence of proxies isn't of any relevance. Therefore I am amending
Precept #1 to state "HTTP resources".

> 
> > Corollary #1.3 - Since HTTP request messages can only be handled by
> > resources which respond with HTTP response messages then 
> even error messages
> > such as "Not Found" must have been generated by a resource.
> 
> Well if the resource can't handle HTTP request, the daemon 
> that will ask
> this resource to generate an HTTP reply should return to the client an
> error stating that the resource doesn't support this 
> protocol, like a Not
> Found with a good explanation in the body.
> 

Perhaps I'm misunderstanding but I assume you are just confirming that you
agree with #1.3. The resource which sent the "HTTP not supported" response
is an HTTP resource. What the resource is saying is "I don't want to talk to
you in HTTP." However the only way he could say that is if he supported
HTTP. He is still an HTTP compliant resource and therefore it was a resource
(in the object model) that generated the response.

>       /\          - Yves Lafon - World Wide Web Consortium - 
>   /\ /  \        Architecture Domain - Jigsaw Activity Leader
>  /  \    \/\    
> /    \   /  \   http://www.w3.org/People/Lafon - [email-masked]    
> 
> 

So when the hell will Jigsaw support WebDAV?!?!? I can't figure out why,
when we are completing the vision that TBL laid out in his book, that
support for WebDAV from the W3C has been largely non-existent. It is very
kind of the W3C to host the mailing lists and make the archives available
but that is a far cry from actually embracing WebDAV. What am I missing? Has
the W3C decided to invest in WebDAV and I just missed the announcement?

		Thanks,
				Yaron

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Wed, 5 Jan 2000 23:53:48 -0500

From: Yaron Goland <[email-masked]>

   <yg/>

   <yl/>

   <yg/>

For me, saying that "every resource must be an HTTP resource so that
it at least can say that it doesn't understand HTTP requests" is
another result of trying to eliminate the concept of a "server" (what
Yves calls a "daemon") from the model.  I believe a simpler (and more
intuitive) model is to just say that there is a server, and if the
server sees that a resource at a URL is not an HTTP resource, it
returns an "HTTP not supported" response.  This is the same server
object that owns the NR (name-to-resource) mapping data.

Cheers,
Geoff