RE: bind draft issues

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

Some more comments:

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

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?

> WebDAV doesn't understand server-side content negotiation because it
> doesn't deal with negotiated URIs.  The bindings spec has no choice

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

> 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

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.

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

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


Julian


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

Received on Saturday, 8 March 2003 03:29:35 UTC