Subject: RE: DAV-Enabled field (was RE: A case for GETSRC)

From: CJ Holmes <[email-masked]>
Date: Mon, 4 Mar 2002 14:10:36 -0800

>The most fundamental question from a data modeling perspective
>is the following: "Is the source the same entity as its output?"
>Julian and I agree that it is not. RFC2616 section 9.3 says
>it is not. Julian has provided examples below, including the
>case of multiple outputs from the same source supporting that
>position.

I've given in on the source-vs-display URI.  In fact, I've always 
acknowledged that it is a perfectly good model.  What I'm trying to 
do is allow people who only use DAV for editing sources to not have 
to do extra configurations to make it happen.

All I'm asking for at this point is some way for server implementors 
to know when a GET arrives from a DAV client.  A DAV-Enabled (or 
whatever) field on the requests would do that.  I'm not trying to 
break the model, or add new methods.  I just want to know when a DAV 
client is GETting a resource vs a normal web client.

Why?  Because what most users expect is to be able to edit their 
pages at the same URI.  I realize that doesn't fit your model, but it 
is what most people really want from DAV.

Even assuming we were to implement a way for our DAV to map sources 
onto some user-configurable alternate URI space with a minimal amount 
of configuration, one of the first things people would ask us is why 
they can't use the same URIs for DAV and for their web browser.  And 
they aren't going to understand the data modeling argument.

I think having this field would:

	(a) speed up the adoption of DAV by solving a serious problem

	(b) retain the clarity of the data model and make it clear 
that a good implementation would have separate URI spaces

	(c) ultimately encourage use of DAV:source, since lots of 
people will finally be using DAV and start to understand the 
advantages of source vs display URIs

I realize adding such a field would not contribute materially to the 
data model or the theoretical soundness of the protocol, but it would 
remove a major headache from the configuration and management from 
most DAV servers.

cjh

--

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 4 Mar 2002 23:33:16 +0100

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of CJ Holmes
> Sent: Monday, March 04, 2002 11:11 PM
> To: DAV
> Subject: RE: DAV-Enabled field (was RE: A case for GETSRC)
>
>

This *is* the problem. GET is GET. It's an HTTP method. Once you are making
it depend on the type of client, you *are* breaking the HTTP model.

> is what most people really want from DAV.

People want to send around URL that point to output resources. They *also*
want to send around URLs that point to source resources. This isn't possible
if the URLs are the same.

Now what?

> they aren't going to understand the data modeling argument.

But maybe they would be able to understand my previous argument?

> remove a major headache from the configuration and management from

I disagree. Your proposal breaks GET in a very fundamental way.

---

From: CJ Holmes <[email-masked]>
Date: Mon, 4 Mar 2002 14:57:31 -0800

>it depend on the type of client, you *are* breaking the HTTP model.

GET returns different things for all kinds of different reasons.  The 
time of day, the browser in use, the phase of the moon, 
authentication credentials, your IP address, how much coffee is left 
in the coffee machine, etc..

The body that is returned from GET is a policy matter that is 
determined by the administrator, not by this list.

>if the URLs are the same.

Again, not your problem.  If someone *wants* to have a special URI 
space for DAV access, then they are welcome to configure their 
server's policy accordingly.

>But maybe they would be able to understand my previous argument?

Eventually.  But they would rather the thing "just work".  Latter on 
they'll read the manual, figure out other configurations, and decide 
if they want to change how they're doing things.

>I disagree. Your proposal breaks GET in a very fundamental way.

Nah...  It is still GET.  I'm just asking for the input I need for 
policy decisions.  The bandwidth is minimal, the processing time 
required is about nil, what's not to like?

cjh

--

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 5 Mar 2002 00:24:04 +0100

> Sent: Monday, March 04, 2002 11:58 PM
> To: DAV

Yes, but all of these *by definition* still are representations of the same
resource. You can't argue with this, this is how it is defined.

> determined by the administrator, not by this list.

Yes, but if you allow the same URL both to respond with it's source and
generated output, it will be hard to define what this resource *is* (give a
definition!). You can't say anymore: "it's a representation of the current
user's shopping cart".

> server's policy accordingly.

If they do, they can use DAV:source. Great. Problem solved. No need for a
new protocol which (in my opinion) breaks HTTP.

> if they want to change how they're doing things.

So you're proposing to change the basic definition of GET because you feel
it's harder to explain the proper solution to your users? That's really a
weak argument.

> required is about nil, what's not to like?

GET is GET. It shouldn't depend on whether a client happens to know that
WebDAV exists. Just because a user agent knows about PROPFIND doesn't mean
that it never will want to GET the output resource. And a user agent that
happens *not* to know about WebDAV still should be able to get the source.

WebDAV doesn't replace HTTP, it *extends* HTTP. HTTP defines how GET is
working, not WebDAV.