RE: Clarification on MKCOL needed

Make the $0.04 (i.e. I agree with Yaron).

Cheers,
Geoff

> To: "'Slein, Judith A'" <JSlein@crt.xerox.com>,
> 
> This is an old and well known issue that many people mistakenly think is
> solved.
> 
> The server is completely free to return to a PUT or MKCOL with a 200 O.k.
> and throw on a location header which points to the "real name" of the new
> resource while throwing away the client's proposed name. 
> 
> In practice no server I'm aware of does this and no client I'm aware of
> could properly handle this.
> 
> If memory serves this issue is already on the WebDAV open issues list.
> Personally I think we should just adopt current practice which says that you
> must either accept the name or reject the request but that is just my $0.02.
> 
> 			Yaron
> 
> > -----Original Message-----
> > From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> > 
> > I agree with you that this is a problem for all document 
> > management systems.
> > I believe it is the most fundamental mismatch between the 
> > WebDAV operational
> > model and the way document management systems work.  It 
> > affects not only
> > MKCOL, but all methods that result in the creation of new 
> > resources (COPY,
> > MKREF, PUT, MKRESOURCE).
> > 
> > It's also wound up with the requirement that WebDAV resource 
> > names reflect
> > the collection hierarchy, which the server-generated names in document
> > management systems generally do not do.
> > 
> > Document Management Systems will probably be forced to do 
> > aliasing between
> > client names and server names, no matter how costly and 
> > annoying that turns
> > out to be.
> > 
> > 
> > > -----Original Message-----
> > > From: Brian Stiles [mailto:bstiles@starbase.com]
> > > How can a WebDAV server support MKCOL if the repository the 
> > server is
> > > built upon assigns names to newly created collections (as opposed to
> > > allowing clients to specify the name)?  Put another way, how can a
> > > client create a collection on a WebDAV server using MKCOL if the
> > > collection that gets created must be assigned a URI by the server?
> > > For example, suppose that each collection is assigned an ID that is
> > > unique to the database that underlies the WebDAV server and 
> > this ID is
> > > used to identify the collection in a URI (e.g.,
> > > http://foo.com/121/13/4/).  If a client wants to create a new
> > > collection, it must issue a MKCOL request to
> > > http://foo.com/121/13/4/<NEW_NAME>/ but because of the fact that the
> > > server essentially controls the namespace, not the client, 
> > the client
> > > can't know what to send for NEW_NAME.
> > > 
> > > Am I missing some important piece of information here?  I 
> > assume that
> > > document management systems might be likely to encounter 
> > this kind of
> > > problem.  If so, has anyone dealt with it?
> > > 
> > > Although it doesn't seem to be explicitly forbidden, I am assuming
> > > that it is inappropriate for the server to ignore the name in the
> > > request-URI and respond with a Location header that identifies the
> > > name assigned by the server.  Though this seems like a possible
> > > solution, it seems contrary to the intent expressed in the spec.  Or
> > > am I wrong in this assumption?

Received on Tuesday, 21 September 1999 15:08:17 UTC