On May 6, 2009, at 10:10 AM, Helge Heß wrote:
Please elaborate. Whats the advantage of
ATTENDEE;X-EMAIL=abc@def.de:urn:uid:98128912
over
ATTENDEE;X-CALSERVER-UID=98128912:mailto:abc@def.de or ATTENDEE;DIR=urn:uid:98128912:mailto:abc@def.de
Thats the core of my claim of 'no good reason'. Your requirements can be met w/o breaking anything existing. (if this does break with some client, please tell us which)
The advantage is that the primary value of the property corresponds to the primary key on my server, and this is unlikely to break. I'm not convinced that parking a GUID in DIR is a valid use of DIR, nor that DIR is any safer than an X-parameter. I'm not inclined to trust all clients to do the right thing according to the spec. This apparently includes not assuming that the value is an email address, per the spec, but I'm willing to live with that if it keeps my primary keys intact.
Further, as I said, there is no way for a client to resolve a UID to some contact record. You talk about a REPORT to resolve UIDs, I suppose this might be OK. Whats this REPORT?
report_DAV__principal_property_search here: http://trac.calendarserver.org/browser/CalendarServer/trunk/twistedcaldav/ex... Though that may be reorganized in a bit. I'm guessing Cyrus will write up a spec for that in a bit as well.
BTW1: using properties for lastname/firstname etc is rather useless, since properties are not covered by etags, hence uncachable.
It's useless for caching, perhaps. That doesn't make it useless, though it might make it worthless to you. WebDAV has its flaws as regards properties and caching.
BTW2: a vCard URL would be nice. (doesn't even have to be CardDAV, plain URL pointing to a vCard would be fine, similiar to FBURL)
Agreed.
Both of these (the parameters and the new REPORT) need to be standardized for interoperability.
Well, yes, I also thought that we might want to standardize a UID parameter to avoid an X-CALSERVER-UID. But then, this is basically what DIR already provides.