Subject: RE: bind draft issues

From: "Clemm, Geoff" <[email-masked]>
Date: Thu, 6 Mar 2003 18:50:17 -0500

How about the following statement about PROPFIND:

"If two URLs are mapped to the same resource, the property
 values returned by PROPFIND on those two URLs MUST be
 identical."

Cheers,
Geoff

-----Original Message-----
From: Brian Korver [mailto:[email-masked]]
Sent: Tuesday, March 04, 2003 6:21 PM
To: WebDAV
Subject: Re: bind draft issues

Geoff and I had a short out-of-band conversation to discuss
the issue I raised when I mentioned "URL properties".
Geoff pointed out that there had been text in the binding
spec that explained the behavior of properties in the
face of different operation, and that it might be good
to revisit the issue and include such explanatory material
in draft.

Would someone like to volunteer to draft that text?
Since I'm not familiar with the previous text and the
discussion that ensued, perhaps Geoff could explain
what the text should include?

-brian
[email-masked]

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 7 Mar 2003 09:52:44 +0100

>  values returned by PROPFIND on those two URLs MUST be

Hmm, I think I know what you mean, however there are cases
where you might want this to break:

1) variants. /news/english/ and /news/german/ might be the same
   resource with different content based on the "access" URL. All
   get* properties will probably vary. (They can already vary on
   a resource with a single binding)
2) live props with URI References can report different relative uri
   references. They are semantically equivalent, but the string value
   of such a property will differ.

What exactly is it, you want to prevent to happen?

//Stefan

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 7 Mar 2003 09:59:26 +0100

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Clemm, Geoff
> Sent: Friday, March 07, 2003 12:50 AM
> To: WebDAV
> Subject: RE: bind draft issues
>
>
>
> ...

I think the statement is correct, and directly follows from RFC2518, section
4.1, first sentence. If this helps to clarify, it may be a good idea to add
it.

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 7 Mar 2003 10:06:36 +0100

> [mailto:[email-masked]]On Behalf Of Stefan Eissing
> Sent: Friday, March 07, 2003 9:53 AM
> To: Clemm, Geoff
> Cc: WebDAV

That would mean that entities may vary based on the request URI. Is this the
case?

>    of such a property will differ.

For instance?

> What exactly is it, you want to prevent to happen?

People falling into the trap of believing in "URL properties", I guess.

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 7 Mar 2003 10:33:41 +0100

Am Freitag, 07.03.03, um 10:06 Uhr (Europe/Berlin) schrieb Julian 

> That would mean that entities may vary based on the request URI. Is 

I thought that's what I wrote.

>>    of such a property will differ.

../../../../version-history/1/2/12
for PROPFIND result on /a/b/c/d/vcr
and
../../../version-history/1/2/12
for PROPFIND result on /a/b/c/vcr
with both "vcr" being bindings to the same resource.

> People falling into the trap of believing in "URL properties", I guess.

Probably a good guess of Geoff's intentions. Why not give a guess
what an "URL property" exactly is? That would be most welcome.

//Stefan

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 7 Mar 2003 10:45:20 +0100

> Sent: Friday, March 07, 2003 10:34 AM
> To: Julian Reschke
> Cc: Clemm, Geoff; WebDAV

OK, I rephrase it: that would mean that a resource is *allowed* to vary
based on the request URL. I don't think we all agree on that.

> with both "vcr" being bindings to the same resource.

OK, this means that we'll have to clarify the "sameness" of property values.
If a property value is a relative URI, it's to be resolved against the
request URL. If they resolve to the same absoluteURI, the property value is
the same.

RFC2518bis issue: the spec normatively refers to RFC2616's term "URI", but
RFC2616 does not formally define it. We need to rephrase this using the BNF
terms URIreference and absoluteURI.

> what an "URL property" exactly is? That would be most welcome.

Our (Geoff's any my) understanding is that there *are* no URL properties. A
URL property would be something that varies with the request URL (under the
relaxed "sameness" definition stated above).

Julian

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 7 Mar 2003 11:00:03 +0100

Am Freitag, 07.03.03, um 10:45 Uhr (Europe/Berlin) schrieb Julian 

> based on the request URL. I don't think we all agree on that.

Uhh, it can vary based on "Accept-Language" request header. Why should
it not vary on the request URI of the GET?

[...]
> relaxed "sameness" definition stated above).

So: properties can vary based on HTTP request headers, but not based on
the HTTP request URI? Or do you think they should not vary based on
HTTP request headers either? Or that only the get* properties are 
allowed
to do that?

//Stefan

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 7 Mar 2003 11:25:50 +0100

> From: Stefan Eissing [mailto:[email-masked]]
> Sent: Friday, March 07, 2003 11:00 AM
> To: Julian Reschke
> Cc: Clemm, Geoff; WebDAV

If we allow the entity to vary based on the URL, what exactly can I rely to
be constant? What's the point of having the concept of "same" resource then?

> the HTTP request URI? Or do you think they should not vary based on

Yes.

> HTTP request headers either? Or that only the get* properties are  allowed
> to do that?

Properties right now do not distinguish between resource properties and
entity properties. That's a design bug inherited from the HTTP header
mechanism. I don't think there's an easy way to fix this.

---

From: Brian Korver <[email-masked]>
Date: Fri, 7 Mar 2003 11:58:34 -0800

[snip]
> what an "URL property" exactly is? That would be most welcome.

I think I gave that the other day:

    Perhaps "URL properties" isn't the right term, but what is?
    In the face of bindings, "URL properties" are those properties
    which are (potentially) effected by operations on bindings, where
    "resource properties" are not effected by such operations.

In other words, they are the class of properties whose values
(potentially) differ based on the URL specified in the PROPFIND
(when more than one binding exists to a resource).  "URL properties"
isn't intended to imply that the property is stored with the
URL or anything else like that: it is merely descriptive of
behavior.

As we discussed earlier, some implementations treat DAV:displayname
as just such a property.

-brian
[email-masked]

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 7 Mar 2003 21:15:00 +0100

> [mailto:[email-masked]]On Behalf Of Brian Korver
> Sent: Friday, March 07, 2003 8:59 PM
> To: WebDAV

I'll comment based on my understanding of the URL-to-resource relationship
in HTTP and WebDAV.

The URL is an identifier for the resource, which allows the client to
interact with the resource (in HTTP mainly by retrieving and manipulating
representations of these resources). WebDAV has added collections and
properties, but these do not really change the underlying model.

When I submit a request to an HTTP server, it uses the request URL to locate
an internal resource object. HTTP allows multiple URLs for the same
resource. Once the object was located, the name (the request URL) becomes
irrelevant -- the results of the interaction should be independant of the
way the server located the resource.

Using my favorite analogy (the Unix filesystem :-): path name and file name
of a file are stored separately of the inode (which holds metadata and has a
reference to content). Once a filesystem has located the internal file
object, one only interacts with the resource and the filename becomes
irrelevant. In particular, I can interact with an open file even though all
bindings (hard links) pointing to it are already gone.

Stefan has raised two issues:

- properties that use relative URIs -- these may vary depending on the
request URL, but the resource that is identified by the relativeURI will be
the same,

- variant handling -- based on the model described above I think this is a
really really bad idea (anyone else?).

Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 7 Mar 2003 16:26:49 -0800

> way the server located the resource.

It uses the request URI to locate an implementation object.  Neither is
the HTTP resource.  The name is always relevant in this process, even 
after
the implementation object is found, because the implementation will use
the name to determine which representation should be returned in 
response
to a GET.  Each representation has its own set of properties.  It is
therefore false to say that two bindings to the same WebDAV resource 
will
have the same properties because WebDAV defines the resource to be the
implementation object (unlike HTTP).

WebDAV doesn't understand server-side content negotiation because it
doesn't deal with negotiated URIs.  The bindings spec has no choice
but to understand it, since that is the primary reason to have bindings
(as opposed to redirects).  In order to make sense of bindings it is
necessary to return to the proper definition of resource and
representations, wherein it never makes sense to say that the binding
attaches to a resource, because the binding is part of what defines
the HTTP resource (the mapping function).

> Using my favorite analogy (the Unix filesystem :-)

The Web is not a distributed filesystem.  Resources are not files.
Why use broken analogies to explain a process which is self-evident
in almost all general-purpose HTTP origin servers?  Just use what
has already been implemented.

....Roy

---

From: "Julian Reschke" <[email-masked]>
Date: Sat, 8 Mar 2003 09:29:21 +0100

Roy,

it's good you're stepping in. We badly need to make progress on

1) the definition of "sameness" for resources (BIND spec vs RFC2616)

2) the relationship between variant handling and WebDAV

Regarding 1): the BIND spec tries to define when two resources identified by
distinct URLs are the same. BIND says that if they are the same they share
the same DAV:resource-id property. In the absence of this WebDAV property,
the only other hint I can think of is that modifications (PUT/PROPPATCH)
applied to one of the URLs will affect the resource identified by the other
URL as well.

- Is this concept compatible with what RFC2616 describes as "A single
resource MAY be identified by many different URIs." (section 9.6)?

If this is the case, I don't really see how selecting a variant based on the
request URL fits in. If I have

/index-en.html and /index-de.html

and model index-en.html and index-de.html as WebDAV bindings to the same
resource and vary the GET content based on the URL the above assumption will
*not* be true (because modifiying the content for /index-en.html will not
affect /index-de.html, and thus both do *not* identify the same resource).

BTW: what will happen if I MOVE /index-de.html to /index-en.html? Will the
resource identified by the URL left behave like the english or the german
variant?

So it seems that we need a stronger definition of "sameness" to be able to
clarify.

Geoff, as RFC3253 relies on the concept of bindings, could you please
attempt to fill in what *you* think an identical DAV:resource-id needs to
indicate?

Regarding 2): that's another interesting issue. RFC2518 says that the
DAV:get* properties must reflect the value of their counterparts returned by
a GET, minus "Accept headers". Accept headers are defined in RFC2616,
section 14.1. As far as I can tell, "accept-language" (section 14.2) does
not fall into this restriction.

I'm not sure what the original intent of this restriction was (does anybody
remember?). Fact is, it breaks the symmetry of PROPFIND and GET/HEAD, which
I find confusing. To define proper variant handling for WebDAV we will have
to

- to clarify how WebDAV DAV:get* properties react to *all* request headers
(may choice would be to say: just like GET and HEAD)

- come up with some theory how properties that vary with the selected
entitiy can be distinguished from those that don't (unless the previous
issue is resolved in a way that says that PROPFIND responses may not vary,
in which case we may need some new marshalling)

- define whether dead properties apply to the resource itself or the
selected variant (with the same caveat).

after
> the name to determine which representation should be returned in  response
> therefore false to say that two bindings to the same WebDAV resource  will

So then what *is* the definition of sameness in RFC2616? Is there any
observable quality of two URLs (i.e., the responses when interacting with
them) through which I can detect they identify the same resource? If there
isn't, does the concept really exist?

> doesn't deal with negotiated URIs.  The bindings spec has no choice

Well, my understanding was WebDAV *does* deal with it (see above).

> (as opposed to redirects).  In order to make sense of bindings it is

I have the feeling that we don't have agreement for why we need the BIND
spec. As far as I understand, server-side content negotiation never played a
role here.

It's interesting that we're getting into a discussion about variant handling
based on open BIND questions. As I always felt that the relation between
variant handling and WebDAV is underspecified, I guess that's a good thing.

> the HTTP resource (the mapping function).

So if the binding is part of what defines the HTTP resource, how can *ever*
to bindings point to the "same" resource?

Julian