Re: xcap co-operation with dav

ext Julian Reschke wrote:
> Jari Urpalainen schrieb:
>>
>> hi !
>>
>> Sorry for cross-posting. I've updated the i-d: 
>> <http://www.ietf.org/internet-drafts/draft-urpalainen-simple-xcap-webdav-02.txt> 
>> which describes some conventions for XCAP usage with WebDAV. Any 
>> comments ?
>> thanks, jari
>
> Hi Jari,
>
> I currently don't have time to do a real review, but here are some 
> quick comments:
>
>    The owners of documents are principals which are manifested to
>    clients as a WebDAV resource, identified by a URI.  A server that
>    implements both WebDAV and XCAP MUST support the same principal
>    namespace for both WebDAV ACL usage and XCAP user identities (XUI).
>
> There is no requirement that a WebDAV principal actually is 
> represented as a WebDAV resource (only HTTP(s) is required).
>
right, the line between http & dav is pretty vague...
>
>    XCAP recommends an XCAP root URI like "http://xcap.example.com" for a
>    domain "example.com".  It is thus RECOMMENDED that the principal URI
>    is of the form "http://xcap.example.com/principals/joe/self" for a
>    user "joe" (XUI).
>
>       Note: The host and path segments of principal URIs may be
>       different in actual deployments, as path segment "principals" is
>       not part of an XCAP Application Usage.  However, note that an XUI
>       SHOULD still represent a collection.
>
> It's not really clear what the requirement here is... If it's not the 
> path, then are you referring to the host (that is, principal URIs must 
> be on the same server)? Why?
>
I'd rather have this as a real requirement, but it would easily break 
existing deployments if any. The purpose of the note was to clarify that 
it that the "principals" path could overlap with a similar name XCAP AU. 
Having different hosts is definitely allowed, although  acl-processor 
needs to have access to this (and preferably local). But I'll try to 
rephrase.
>
>
> 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.
>
>
>    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 ?
>
>
> Finally, it seems to me that the spec tries to profile RFC3744. That 
> may be the right thing to do, but it would make things easier to 
> understand if it would state that more clearly, and also provide a 
> motivation for it.
>
>
> Best regards, Julian
Right, I would be more than happy to have a similar feature in 
rfc3744bis, which is the proper place for this.

Thanks Julian for your comments.

br, Jari