Cyrus Daboo <cyrus@daboo.name> · Wed, 15 May 2013 14:16:13 -0400

Hi Helge,

--On May 15, 2013 at 10:39:31 AM -0700 Helge Heß <helge_hess@apple.com> 
wrote:

> I don't think it's a good idea even if some servers allow that (I mean
> it's a good idea in pure DAV theory, but it's not a good choice in
> practice ;-). Principals will be often mapped to some kind of
> authentication service (say LDAP) and such rarely provide arbitrary extra
> storage.
>
> My guess is that PROPPATCHing something into the home is probably going
> to work slightly better. But it's still not required and I would expect
> many servers to not support this (such where the home is not a real
> physical entity, but just an entry point into e.g. a DB).
>
> Yet another approach would be to just PUT a non-calendar resource with
> the config into the home. But again, this will only work in a few servers.
>
> One thing which would work universally for the client, is taking another
> URL (pattern) where the client can store config information. Then the
> admin of the backend server could decide where user configuration should
> go. (direct it to the principal, to the home or some other, regular DAV
> store).
>
> Summary: There is no interoperability on this :-/

Agreed. For the record our server does not support PROPPATCH of dead 
properties on a principal resource. With our delegate support we do allow 
PROPPATCH of group-member properties on the delegate resources which are 
children of the principal.

I do think using WebDAV properties for preferences is not the best 
solution. In Mulberry, as a replacement for IMSP and ACAP, I ended using a 
simple WebDAV PUT of a properties document to a "regular" WebDAV server 
(not that our calendar server does not support non-calendar/address data 
puts in a home). The benefit of using a resource rather than properties is 
that conflicts can be detected (etag conditions) - that is important 
because multiple clients are involved. That said, it is still not ideal in 
that it would be nice to be able to do partial updates - but PATCH could 
take care of that.

In any case, I suggest telling the client folks to try PROPPATCH on 
principals, if that fails, try the calendar home, if that fails try the 
default calendar (which is not ideal because it could be deleted), if that 
fails - fail gracefully!

-- 
Cyrus Daboo

_______________________________________________
tc-caldav-l mailing list
tc-caldav-l@lists.calconnect.org
http://lists.calconnect.org/mailman/listinfo/tc-caldav-l

Subject:	Re: [Tc-caldav-l] PROPPATCH on principal resources
Date:	Wed, 15 May 2013 14:16:13 -0400
From:	Cyrus Daboo <cyrus@daboo.name>
To:	Helge Heß <helge_hess@apple.com>, tc-caldav-l Reflector tc-caldav-l <tc-caldav-l@calconnect.org>