Subject: [Simple] Re: Belated review of draft-urpalainen-simple-xcap-webdav

From: Jari Urpalainen <[email-masked]>
Date: Tue, 21 Nov 2006 09:06:31 +0200

Thanks Lisa for your comments, more inline. And sorry for cross-posting 
but this might interest both groups.

ext Lisa Dusseault wrote:
>
> Hi Jari,
>
> I finally got around to reviewing this draft, version -01.  The basic 
> model I completely agree with, it's the easiest one and quite useful.
great.
>
> Some comments:
>
>     - Is it necessary to say that the ETag used with XCAP operations 
> is the exact same as the one used in WebDAV operations?  This allows a 
> client to use both XCAP and WebDAV without repeating ETag queries or 
> worrying about keeping two sets of ETags.  This may be obvious already 
> since both WebDAV and XCAP only use HTTP ETags.
imo, (and being an implementer) yes they must not be separate. And even 
implementation on top of Apache is simple (though it does response with 
weak ETags, but it is easy to patch it once you do have source code ;-) )
>
>     - Section 4.6: I'm not 100% sure that existing software out there 
> will all work with a WebDAV Principals namespace of the form 
> "http://principals.example.com/".  More typically you see principal 
> namespaces inside the same domain name as the server that hosts the 
> content.  So you might see "http://example.com/principals" or 
> "http://example.com/servlet/acl/principals".  I do not know if these 
> forms have any disadvantages over the form you suggest but in ACL 
> deployment so far they're more likely to be seen.  I agree that 
> principal namespaces on different domains is probably OK, but we might 
> want to think for a moment about whether it would be OK for a server 
> with content at "example.com" could have its principals at a 
> completely different DNS tree, e.g. "identities.example.ru".
ok, I just not wanted to mess up with xcap conventions, i.e. principal 
entities would not interfere with an xcap application usage.  If 
<http://example.com/principals> is better inline with current 
deployments I'm fine with that as well (virtual hosting is easy imo 
and/or reverse proxy configurations do help here anyway). Anyhow, this 
is only a recommendation and just to try to help the provisioning 
nightmare... And of course this should be (or have been) in rfc3744, 
imo, i.e. some conventions, though not being mandatory are typically 
useful for implementations.
>
>     - You might want to add that the location for principals can be 
> discovered by doing an OPTIONS request and asking for the principals 
> namespace.  Is there an alternative (XCAP) way of discovering the 
> location?
>
XCAP hasn't anything for this (just capability au). Are you proposing 
adding some mime type for OPTIONS * ?  Certainly it would help 
provisioning...
>     - In section 4.6, you say "The user "joe" is thus an XCAP user 
> identity (XUI)".  This is descriptive, not normative.  Would it be 
> better to turn this into a normative requirement?  E.g.
>     "A server that implements both WebDAV and XCAP MUST support the 
> same principal namespace for both WebDAV ACL usage and XCAP user 
> identities (XUI).  That is, every valid WebDAV principal MUST also be 
> a XUI, and vice versa."
right, I agree.
>
>     - You might add a property to a principal, such that an 
> application that knows "who am I" (it has discovered its principal 
> identity as currently authenticated) can discover where its XCAP 
> application "home directories" are.  For example, this could be a 
> multi-valued property valid on a Principal Resource, e.g.
>     <DAV:prop>
>         <XCAP:xcap-home-directories xmlns:XCAP="some XCAP namespace">
>             
> <DAV:href>http://example.com/com.example.anAUID/joe/</DAV:href>
>             <DAV:href>http://example.com/resource-lists/joe/</DAV:href>
>         </XCAP:xcap-home-directories>
>     </DAV:prop>
>
>     Even more generally, this property could identify the user's XCAP 
> documents of all kinds directly.
right, again sounds reasonable to have xcap home directory principal 
property, the xcap capability extension lists available AUs. This seems 
to add some content to this i-d, btw ;-).
>
>     - You might want to note that XCAP applications can add their own 
> privileges to the set of base WebDAV privileges.  For example, let's 
> say we had an XCAP application defined for conferencing.  Part of the 
> conference application has conference room setup -- what server it's 
> on, what bandwidth reserved.  But another part of the conference 
> application is for moderation: who can provide input without 
> moderation, who is on the "moderate their input" lists, and who is 
> entirely blocked.  For this application, we might want to define a 
> special XCAP conferencing "moderator" privilege that could do some set 
> of functions but not as much as the administrator who can edit the 
> entire XCAP document.  The XCAP server would of course apply the 
> custom privilege and would allow or disallow PUT and DELETE to XCAP 
> node selector URLs, based on the privilege and the principal.
>     <DAV:grant>
>         <DAV:privilege><XCON:moderate xmlns:XCON="Some conferencing 
> namespace"/>
>         </DAV:privilege>
>     </DAV:grant>
>
right. rfc3744 is extensible (and the basic model/idea is very 
reasonable, imo).
>     - Section 5, error handling:  Since this document says that a 
> client is not to send WebDAV requests to XML node selector URLs, I 
> think the best response to seeing such a request would be in the 
> 400-series -- possibly 403 Forbidden.  To make it clear what exactly 
> is forbidden, you can define an XML error code for return in the error 
> body, e.g.
>     <DAV:error>
>         <xcap:webdav-request-to-node-selector/>
>     </DAV:error>
>
agreed, some deterministic (and documented) responses are definitely better.
>
> You can send these comments to a WG or discussion list if you like.
> Thanks,
> Lisa
>
Thank you,
Jari

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 21 Nov 2006 08:18:13 -0800

Sorry, I got confused -- the ability to discover where principal  
resources can be found is an existing feature in ACL but it isn't  
done via OPTIONS, it's done via PROPFIND of a property called  
'principal-collection-set'.

http://rfc.net/rfc3744.html#s5.8.

Lisa

On Nov 20, 2006, at 11:06 PM, Jari Urpalainen wrote:

>>
>>     - You might want to add that the location for principals can  
>> be discovered by doing an OPTIONS request and asking for the  
>> principals namespace.  Is there an alternative (XCAP) way of  
>> discovering the location?
>>
> XCAP hasn't anything for this (just capability au). Are you  
> proposing adding some mime type for OPTIONS * ?  Certainly it would  
> help provisioning...