- From: Julian Reschke <julian.reschke@greenbytes.de>
- Date: Thu, 4 Jul 2002 17:43:01 +0200
- To: "'Deltav WG'" <ietf-dav-versioning@w3.org>
Hi, I was just trying to implement 5.5 in our server and came across the following issue: - the request body is optional, so I check for the presence of a XML-wellformed request body. If there is none - fine. - if there is an XML request body, 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. In the long run, I'd like to see this removed from the protocol, and possibly changed into a live property. Julian > -----Original Message----- > From: ietf-dav-versioning-request@w3.org > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Julian Reschke > Sent: Thursday, July 04, 2002 4:24 PM > To: 'Deltav WG' > Subject: Additional OPTIONS semantics for version-history feature > > > > Hi, > > 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? > > Assuming that there is a use case for this feature -- will a future RFC > define an additional live property for this as well? > > > [1] <http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.5.5> > >
Received on Thursday, 4 July 2002 11:43:24 UTC