Subject: Trailing "/" in BIND Requests

From: "Slein, Judith A" <[email-masked]>
Date: Wed, 15 Sep 1999 14:53:13 -0400

Both Yaron and Jim Amsden our attempts to enforce consistency between the
Request-URI and the Destination header in BIND requests are not appropriate.
We wanted to say that either both must end in a "/" or neither may end in a
"/".  

But in reality a trailing "/" is not a reliable indicator of the type of
resource being addressed, so we should allow servers to process BIND
requests even if the Request-URI ends in "/" and the Destination header does
not, or vice versa.

We agree with these comments and will remove the constraints from the
description of the BIND method and the related examples.

Yaron also objected to our saying that the Request-URI cannot just consist
of "/".  That is, we currently say that you cannot use BIND to create a
binding between the root and some resource.  We say this because we define a
binding to be a relation between a URI segment in its parent collection and
some resource.  That is, it's the triple (segment, collection, resource).
Here there is no segment, and there is no parent collection.  So you can't
make sense of creating a binding for "/". 

--Judy

Judith A. Slein
Xerox Corporation
[email-masked]
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580

---

From: [email-masked]
Date: Thu, 16 Sep 1999 12:35:08 -0400

From: [email-masked]

   <jc/> I think Yaron's point is that he believes / should be able to refer to
   any resource.  Right now it's stuck with whatever it started with.  Or
   at least it appears that it stuck.

   <gmc/> Fair enough.  We could certainly overload "BIND" and/or "MOVE"
   to make a BIND/MOVE to "/" be a special case that doesn't affect bindings,
   but rather modifies the current mapping of "/".

<jc/>Sounds fair.  There's nothing in the syntax of the protocol to suggest
that it can't be done or that there's anything special about it.  Obviously
we can't lock the "parent" of  / if we wanted to lock a whole tree, but if
we lock  / itself, the URI protection feature will have the same effect.
It's only our data model... and perhaps some implementations that might have
to twist themselves a bit to handle this.  Can any server implementers
comment on the difficulty of this?

Note: changing the root is sort of an academic case.  Unless you are going
cross server, the new / will actually be "deleted" in the delete phase before
it becomes the new resource.  At least in the model.

Next question...  do we want to make replacement of the / resource a MUST?

Next question...
    Folks have talked about mixed webdav/non-webdav servers.  Do we have
    a similar situation at the interfaces between the webdav and non-webdav
    portion of a site?  (Honest question. I don't have a clue how these mixed
    servers work.)