Subject: xcap co-operation with dav

From: Jari Urpalainen <[email-masked]>
Date: Thu, 08 Mar 2007 15:32:14 +0200

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

---

From: Julian Reschke <[email-masked]>
Date: Fri, 09 Mar 2007 21:49:04 +0100

> which describes some conventions for XCAP usage with WebDAV. Any comments ?

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

---

From: Jari Urpalainen <[email-masked]>
Date: Mon, 12 Mar 2007 09:59:42 +0200

ext Julian Reschke wrote:
> I currently don't have time to do a real review, but here are some 
> quick comments:
>
> 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...
> 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.
> verbs on XCAP nodes? Why? If the server can't execute them, it should 
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.
> 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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 12 Mar 2007 10:55:17 +0100

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

> 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