Re: Trailing "/" in BIND Requests

   From: ccjason@us.ibm.com

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

Received on Thursday, 16 September 1999 12:28:54 UTC