These fixes are OK as work-arounds in a pinch, but Evolutions is violating the CardDAV specification, so the real fixes need to go there.
See here: http://ietfreport.isoc.org/idref/draft-ietf-vcarddav-carddav/ Section 6.2.2 says that clients MUST get a CARDDAV:supported-address-data precondition error if they attempt to create an address object resource not advertised by the server in the CARDDAV:supported-address-data property. In our case, we only advertise support for text/vcard version 3.0. And Section 5.1 says: vCard components in an address book collection MUST have a UID property value that MUST be unique in the scope of the address book collection in which it is contained. I think fixing bugs in Evolution would be more appropriate than working around these bugs in the server. -wsv
_______________________________________________ calendarserver-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-dev
