Message-ID: <65B141FB11CCD211825700A0C9D609BC01879982@chef.lex.rational.com> From: "Vasta, John" <jvasta@Rational.Com> To: ietf-dav-versioning@w3.org Date: Wed, 23 Feb 2000 12:42:17 -0500 Subject: RE: Enumerating repositories and worksp <john> But you can discover all activities, configurations, and versioned resources in a given repository; there are special collections defined for them, and a server is allowed to restrict those resources to be contained in those collections. </john> <tim> There are?! Why? </tim> There are, in the form of the DAV:versioned-resources, DAV:activities, and DAV:configurations properties of repositories (section 10.8). And the reason is so that it is possible to implement the protocol for systems which constrain resources to exist in repositories. For such systems, you must specify a repository when you create a resource; that is done by forming the resource URL using one of these special collections. <john> If a client cannot discover what the repositories are, how can it specify the location of any of the resources which are in those constrained areas? </john> <tim> Agreed. We should either specify eveything, then the client is 'routed' to the right place to do their stuff, or we specify nothing and anarchy applies (i.e., all resources are equal and clients decide where things will be stored). </tim> I think you can have it both ways, if there was a way to discover whether a server has constraints or not. The spec is almost there; we just need a way to discover whether the server has repositories, and where it insists workspaces be located. If there were two properties defined somewhere (e.g. DAV:repositories-root and DAV:workspaces-root), then if either of those properties are defined, a client uses their values to form URLs to repositories (and therefore activities, configurations, and versioned resources) or workspaces respectively. If a property is not defined, then clients are free to use any URL they please, for the corresponding type of resource. John