Re: xcap co-operation with dav

Jari Urpalainen schrieb:
>> 4.6.  Other WebDAV methods
>>
>>    With any other WebDAV methods when accessing XCAP resources, the
>>    request URI may not contain an XCAP node selector.
>>
>> I'm not sure what this is saying... Clients MUST NOT attempt WebDAV 
>> verbs on XCAP nodes? Why? If the server can't execute them, it should 
>> fail the request.
> Right, the purpose is to fail the request, I'll rephrase. The reason to 
> drop DAV stuff from XCAP components is very pragmatic, it is _very_ 
> complex and there are several error cases which are not at all that 
> clear. So the specification/implementation complexity is way too 
> complex, imo. So I am looking for a real no-brainer use-case here.

I think this is overspecification. For instance, a JSR-170 (JCR) based 
store could probably support many WebDAV methods on XCAP nodes. There's 
no point in forbidding this. Clients can easily discover what's allowed 
(Allow header, DAV:supported-*-set...).

So I would recommend to either not to say anything at all, or to mention 
that some servers may not support WebDAV methods on child nodes.

>>    If WebDAV methods (other than GET, PUT or DELETE) are used with
>>    request URIs which contain an otherwise valid XCAP node selector the
>>    server SHOULD respond with 403 (Not Authorized).  The corresponding
>>    precondition error element is defined formally by the RELAX NG Schema
>>    [5] given in Section 7.1.
>>
>> 401 Not Authorized or 403 Forbidden????
> This was already a discussion item in the previous version. Personally I 
> don't care what's the error number, unless there's a recommendation 
> (once again a MUST requirement would be nice, but it seems too hard from 
> implementation point of view...). So what's your proposal ?

I think 403 is fine, but it should have the right reason string in the 
spec ("Forbidden", not "Not Authorized").

> ...

Best regards, Julian

Received on Monday, 12 March 2007 09:55:28 UTC