RE: server defined activity URLs

I agree that this is generally useful functionality.

I'll get this written up as an extension, so we can fold it into
the next version of the protocol.

I'd suggest the following variant:

When the MKACTIVITY is applied to one of the collections identified in
the DAV:activity-collection-set OPTIONS response, the server MUST create
a new activity in that collection, and return the location of that new
activity in a Location header.

I'd just return a 201 (Created), and use the presence of the Location
header to indicate that it has been created somewhere other than the
request-URL.  A compliant client won't be trying to create activities
at this location anyway.

Cheers,
Geoff


-----Original Message-----
From: Sohn, Matthias [mailto:matthias.sohn@sap.com]
Sent: Tuesday, March 26, 2002 4:58 AM
To: Ietf-Dav-Versioning@W3. Org
Subject: server defined activity URLs


Hi,

suppose we want to implement a distributed DeltaV server which allows
propagation 
between workspaces residing on different servers. In order to ensure unique
activity names
(needed to ensure activity URL uniqueness if activities are also
distributed) in this scenario 
we would like to have server defined activity URLs.

Would it be DeltaV compliant to achieve that by using the response defined 
in section "10.3.2 301 Moved Permanently" of the HTTP 1.1 spec (rfc2616) ?

   >>REQUEST

     MKACTIVITY /act/test-23 HTTP/1.1
     Host: repo.webdav.org
     Content-Length: 0

instead of

   >>RESPONSE

     HTTP/1.1 201 Created
     Cache-Control: no-cache

we would like to use

   >>RESPONSE

     HTTP/1.1 301 Moved Permanently
     Location: /act/test-23-9C0BC5DA776811D5B3490001021DCD13
     Cache-Control: no-cache

     <HTML body containing href to new URL>

regards
Matthias

Received on Monday, 8 April 2002 08:04:00 UTC