RE: Additional OPTIONS semantics for version-history feature

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: [email protected]
> [mailto:[email protected]]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>
>
>