Subject: WebDAV Bindings - Issue Yaron.ApplePieToo

From: Yaron Goland <[email-masked]>
Date: Sun, 16 Jan 2000 17:27:55 -0800

Section 9 of the draft attempts to tackle the problem of how to
differentiate the behavior of a resource based on its bindings. It attempts
to discuss the difference between a static and non-static resource. However
the difference between these two types of resources is so unbelievably
arbitrary that I fail to see how attempting to differentiate between them
enhances interoperability.

For example, let us pretend we have the CurrentURI property. The value of
the property will be the Request-URI of the PROPFIND method used to retrieve
the value of the CurrentURI property. Now let us pretend we have two
servers, A and B. A runs a version of WebDAV that automatically generates
the CurrentURI property on top of whatever resources it supports. What this
means is that even if the underlying data store where the resource is
recorded doesn't know about the CurrentURI property, I can still get the
CurrentURI property through PROPFIND because A's server will intercept the
PROPFIND and insert the data itself. Server B doesn't support CurrentURI at
all. I now have a resource R that has bindings into A and B. This means that
if I ask for the CurrentURI property through the binding on A, I will get a
result with the URI on A. If I ask for the CurrentURI property through the
binding on B, I will not even see the property at all.

So the question is - Well is this a dynamic resource? Is it not? Can I have
the same resourceID on both URIs in this example? How does the language in
section 9 help me deal with this? Does it actually clarify anything in a
useful way?

As far as I can tell the language in section 9 is just motherhood and apple
pie language and that always makes for bad standard language.

Therefore I move that all the paragraphs in section 9 but the first
paragraph be stricken from the BIND spec.

---

From: "Slein, Judith A" <[email-masked]>
Date: Tue, 18 Jan 2000 10:31:17 -0500

The first paragraph doesn't really say anything substantive.  It just
introduces the section, listing the methods to which it applies.  The one
substantive statement that I think we would want to keep is "For these
methods, no new complexities are introduced by allowing explicit creation of
multiple bindings to the same resource."
 
I could be persuaded to reduce the section to just that.
 
But it still might be worth pointing out that BIND will make it much more
common to have multiple bindings to the same resource (even though that was
always possible).  And when there are multiple bindings to a resource, it is
possible for a resource's behavior in response to GET, HEAD, PROPFIND, etc.,
to be sensitive to the URI that was used to make the request.  Maybe we
wouldn't have to discuss the distinction between static and dynamic
resources in order to make that point.
 
--Judy

---

From: Yaron Goland <[email-masked]>
Date: Tue, 18 Jan 2000 08:12:05 -0800

I agree that we want to keep the sentence you identified below.

I also agree that we want to address the issue of a resource acting
differently based on the URI it is addressed from.

I suspect my problem with the language in the section derives from the
differentiation made between static and dynamic resources. In my experience
one can not really make the distinction because even if a "resource" is just
a file in a file system, there is always a server on top of it that may or
may not alter its presentation. If the language in section 9 were to be
re-written with the assumption that ALL resources are dynamic then I suspect
we would find the resulting language mutually acceptable. 

In other words, we should remove the terms dynamic/static completely and
instead talk about resources and the fact that their presentation can change
based solely on what URI they are accessed from. We shouldn't even try to
address the fact that in some cases, some resources for some period of time
may choose to look identical regardless of what URI they are accessed from.

		Yaron

> From: Slein, Judith A [mailto:[email-masked]]
> Sent: Tue, January 18, 2000 7:31 AM
> To: 'Yaron Goland'; [email-masked]
> Subject: RE: WebDAV Bindings - Issue Yaron.ApplePieToo
> 
>

---

From: [email-masked]
Date: Tue, 18 Jan 2000 17:26:11 -0500

I suspect my problem with the language in the section derives from the
  differentiation made between static and dynamic resources. In my
experience
  one can not really make the distinction because even if a "resource" is
just
  a file in a file system, there is always a server on top of it that may
or
  may not alter its presentation. If the language in section 9 were to be
  re-written with the assumption that ALL resources are dynamic then I
suspect
  we would find the resulting language mutually acceptable.

I agree that there is a perspective that there are no truly static
resources in the world,
but if we get hung up on that, we're verging on a meta-physical discussion
that will
distract from the point of this section.  And if we tried to write
something that works
for all dynamic resources, there truly wouldn't be anything meaningful said
in that
section.   That section is very readable right now and does a good job of
conveying a fuzzy concept/behavior:

There are a range of resources.  From the ideal static resource to the most
dynamic resource
you could imagine.  One will probably never encounter a resource at either
extreme.  Where
a given resource lies between these two extremes is in the eyes of the
beholder... but the
platonic ideal of a static resource acts in this fashion...

That being said, feel free to write up a new version of that section, but
please don't get overly
distracted trying to convey the fact the the nominal "static resource" is
only an ideal.
I do feel if one's focus is too much on that, they will write something
less effective
than the current text.   As I said, the current text seems to do a good job
conveying
a fuzzy topic.

---

From: "Slein, Judith A" <[email-masked]>
Date: Wed, 19 Jan 2000 10:39:55 -0500

Here's some text that doesn't mention static / dynamic.  It doesn't make the
simple, idealized statement that we wanted for static resources, but maybe
it says enough to be useful:

"This section describes the interaction of bindings with those HTTP methods
not yet explicitly discussed.  The semantics of the methods GET, HEAD, PUT,
POST and OPTIONS are specified in [HTTP].  The semantics of PROPFIND,
PROPPATCH, and MKCOL are specified in [WebDAV].

"For these methods, no new complexities are introduced by allowing explicit
creation of multiple bindings to the same resource.  However, the
introduction of the BIND method will make it more common for multiple URIs
to map to the same resource.  As a result, the introduction of the BIND
method may point up complexities that were already possible, but occurred
only rarely in the past.  

"In particular, when there are multiple URI mappings to the same resource,
it is possible for the resource's behavior in response to GET, HEAD,
PROPFIND, etc., to be sensitive to the URI that was used to make the
request.  For example, the Request-URI may appear in the response entity
body for GET on a particular resource, in which case the response entity
body produced by that resource will differ depending upon which URI was used
to make the request.

"The only way for a client to determine whether two URIs map to the same
resource is by retrieving and comparing the DAV:resourceid property defined
in the following section."

Or we could keep the current text, but add some remarks about the static /
dynamic distinction, along the lines that Jason suggests:

"This section describes the interaction of bindings with those HTTP methods
not yet explicitly discussed.  The semantics of the methods GET, HEAD, PUT,
POST and OPTIONS are specified in [HTTP].  The semantics of PROPFIND,
PROPPATCH, and MKCOL are specified in [WebDAV].

"For these methods, no new complexities are introduced by allowing explicit
creation of multiple bindings to the same resource.  However, the
introduction of the BIND method will make it more common for multiple URIs
to map to the same resource.  When these methods are applied to the same
resource using different Request-URIs, the rules for their behavior depend
upon whether the resource is static or dynamic.

"A static resource is one that always produces the same response to the same
method with identiical parameters.

"A dynamic resource is one that may produce different responses for
different submissions of the same method with identical parameters.

"In reality, a single resource may respond statically to some requests, but
dynamically to others.  However, for a pure static resource, these methods
obey the folowing rule:

"o  A method submitted through one URI mapping, on success, MUST produce the
same results as the same method, with the same headers and entity body,
submitted through any other URI mapping to the same resource.

"When applied to dynamic resources, it is not possible to state any such
rule.  For any method, a dynamic resource may be sensitive to the URI
mapping used to access it.  The resource may produce different results
depending upon which URI mapping was used to submit the request."

--Judy

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, January 18, 2000 5:26 PM
> To: Yaron Goland
> Cc: [email-masked]