W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > July to September 2002

RE: Additional OPTIONS semantics for version-history feature

From: Clemm, Geoff <gclemm@rational.com>
Date: Sun, 7 Jul 2002 08:58:37 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B1075FD3E7@SUS-MA1IT01>
To: "'Deltav WG'" <ietf-dav-versioning@w3.org>

   From: Julian Reschke [mailto:julian.reschke@greenbytes.de]

   I'm looking at the description for the additional OPTIONS semantics
   for the version-history feature ([1]), but I don't really
   understand what problem this feature is supposed to solve. Given a
   specific resource on a Delta-V server, I can find one (or more)
   collections that may contain version histories on this server. What
   is a client supposed to do with this information?

The main use case for DAV:version-history-collection-set is when you
have deleted the last VCR for a version history, and now you want to
retrieve the content of a version from that version history.  You can
browse for that version history in the
DAV:version-history-collection-set.  If your server supports baselines
or version-controlled collections, it is likely to be much more
effective to search for that version history in the baseline histories
or collection histories, so I agree that the case for
DAV:version-history-collection-set is not all that compelling.

   Assuming that there is a use case for this feature -- will a future
   RFC define an additional live property for this as well?

We certainly could.  Would anyone object to doing so?

   From: Julian Reschke [mailto:julian.reschke@greenbytes.de]

   ...  if there is an XML request body for OPTIONS, the protocol
   *requires* that it has a certain document element.

   This basically means that RFC3253 has occupied the format for *any*
   OPTIONS request body -- no other HTTP-extending protocol can go out
   and specify similar requirements without being in conflict with
   RFC3253. In particular, RFC3253 is in conflict with a potential
   HTTP revision that specifies request bodies for OPTIONS (!).

   So, at a minimum, the protocol MUST allow to ignore the request
   body if the document element is not DAV:options.

I agree.

   In the long run, I'd like to see this removed from the protocol,
   and possibly changed into a live property.

Given that the ACL spec has decisively moved towards marshalling this
kind of information as a property, and not as an OPTIONS request, the
cleanest thing to do would be to update 3253 to also not use OPTIONS
to marshall this information.  This would then address the OPTIONS
request body issue as well.  I'll start a separate thread on this, to
maximize the chance that folks will notice and respond to this

Received on Sunday, 7 July 2002 08:59:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:48 UTC