Re: xcap co-operation with dav

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).


    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?



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.


    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????


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

Received on Friday, 9 March 2007 20:49:11 UTC