On 06.05.2009, at 18:52, Wilfredo Sánchez Vega wrote:
Well, I disagree with the assertion that there is no good reason.
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) 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? BTW1: using properties for lastname/firstname etc is rather useless, since properties are not covered by etags, hence uncachable. 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)
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. Thanks, Helge -- Helge Hess http://helgehess.eu/