ext Julian Reschke wrote:
> Jari Urpalainen schrieb:
>>
>> hi !
>>
>> Sorry for cross-posting. I've updated the i-d:
>> <http://www.ietf.org/internet-d
rafts/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 "htt
p://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
_______________________________________________
Simple mailing list
Simple ietf.org
https:/
/www1.ietf.org/mailman/listinfo/simple
|