Subject: Translation in the Tower of Babble

From: Yaron Goland <[email-masked]>
Date: Mon, 3 Jan 2000 11:50:09 -0800

I believe that there are too many different unstated assumptions held by
members of this group for this group to be ready to deal with specific
locking proposals. The fact that Geoff, Eric and RFC 2518 can come out with
such different proposals helps to illustrate the issue. Rather than
attempting to achieve consensus in one fell swoop by having everyone read
and critique full proposals I would suggest that we start from a simpler
basis. Let us first see if we can establish agreement on some very basic
precepts. I will start with just one precept and see if we can get agreement
on just that.

Precept #1 - HTTP clients send HTTP request messages to resources that
respond with HTTP response messages.

Corollary #1.1 - All HTTP proposals can only be written in terms of how a
resource processes a HTTP request from a HTTP client and generates a HTTP
response as a result.

Corollary #1.2 - HTTP requests do not necessarily have to be handled by HTTP
resources. For example, it is possible to send a HTTP request with a FTP
request-URI. Some HTTP proxies are set up to act as gateways that can handle
translating the HTTP request into a FTP request and then translate the FTP
response into a HTTP response. That is why precept #1 states "...to
resources..." rather than specifying a HTTP resource.

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.

Let's see if we can just get agreement on this single precept and its
corollaries.

	Merci,

			Yaron

---

From: Eric Sedlar <[email-masked]>
Date: Mon, 03 Jan 2000 16:08:31 -0800

Yaron,

The problem with discussing abstractions like this without concrete examples is
like trying to write legislation without loopholes--you don't really know if
it's well written until you see its effects.

My guess is that the direction you are heading in is defining a resource as the
base class of all WebDAV objects capable of responding to an HTTP request.
This is a good abstraction.  It follows from this that an HTTP method like LOCK
should not apply to a URL that does not identify a resource, since there is no
resource to respond to the request, which would outlaw the lock-null approach.

It might be useful to give more of an "agenda" for where this thread is going
(even without filling in the details), so people can better place your
discussion in context of the world of WebDAV problems.

In general, however, I think that any solution to the locking problems
discussed recently has to fit in some general model like the one I anticipate
that Yaron will propose.  However, I prefer a complete model to be laid out
before me before I comment on particular precepts of the model.

For example, following this level of abstraction, we should define a resource
better.  I would say that a resource has a set of properties, which can be
represented via an XML document.  Some of these properties are
"live" properties, which are read-only and are set as a side effect of other
methods ( for example a modification date).  Attempts to set the value of a
live property directly via generic property mutator method(s) (e.g. PROPPATCH,
PUT, etc.) should always be ignored.  A collection is a subclass of resource
that has a live property containing a list of tuples including at least a name
(and possibly with other values such as a resource ID associated with that
name).  A BIND request is treated as a method that modifies the values of the
collection's name tuple list.

This should all be worked into the versioning model document
(http://www.ics.uci.edu/pub/ietf/webdav/versioning/model990209/), which while
defining some of the functional methods available on a resource, doesn't define
the properties on a resource as well as a number of the other assumptions along
the lines Yaron proposes.

--Eric

---

From: Yves Lafon <[email-masked]>
Date: Tue, 4 Jan 2000 10:21:15 +0100 (MET)

> resources..." rather than specifying a HTTP resource.

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.

> 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.

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