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;[email protected]:urn:uid:98128912
over
ATTENDEE;X-CALSERVER-UID=98128912:mailto:[email protected]
or
ATTENDEE;DIR=urn:uid:98128912:mailto:[email protected]
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/
_______________________________________________
calendarserver-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-dev
