RE: options

> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> 
> Every statement in the DeltaV protocol is implicitly wrapped
> with the prefix "If the feature of this section is supported, then ...".
> So the request body MUST be DAV:options if any of the DeltaV features
> are supported by the server.

Suppose I invent the Value-Added-Dummy Protocol and have a super feature
that allows clients to send VAD:options XML request bodies in OPTIONS
methods. Would every deltaV-compliant server choke on such client
requests or just ignore the VAD:options request bodies?

//Stefan

> But I agree that it would be more precise to qualify any statement
> about the response body marshalling with the statement "if the request
> succeeds" (since if it does not, you often get a DAV:error node as
> the response body).  I will try to squeeze this into the final 
> editing pass.
> Thanks for noticing that!
> 
> Cheers,
> Geoff
> 
> -----Original Message-----
> From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
> Sent: Thursday, October 04, 2001 6:15 AM
> To: ietf-dav-versioning@w3.org
> Subject: DAV:options
> 
> 
> Sorry for the late comment on the spec:
> 
> In x.x Additional OPTIONS Semantics
> 
>   Additional Marshalling:
>   If an XML request body is included, it MUST be a DAV:options 
> XML element.
> 
> Should be:
> 
>   If an XML request body is included, and the document element is
> DAV:options
>   and the server supports the xxxx feature, the server MUST process a
> possible
>   DAV:xxx-set child element of DAV:options.
>   If the request is successful, the response...
> 
> Not every OPTIONS XML request body to a HTTP server must include
> DAV:options, right?
> 
> //Stefan
> 
> 
> 
> 
>

Received on Thursday, 4 October 2001 09:14:10 UTC