[CalendarServer-dev] UIDs as ATTENDEE IDs, please fix that
Helge Heß
me at helgehess.eu
Fri May 1 08:05:54 PDT 2009
Hi,
CalServer switched to use URNs/UIDs as ATTENDEE identifies. I think
thats a really BIG mistake, I feel very strongly about it ;-) and
would like to see that behaviour modified.
Currently:
ATTENDEE;X-CALENDARSERVER-EMAIL=abc at def.de:urn:uid:29838484...
should be
ATTENDEE;X-CALENDARSERVER-UID=29838484:mailto:abc at def.de
or even
ATTENDEE;X-CALENDARSERVER-UID=29838484:tel:+49-12234-233
Why? There are two big reasons:
a) Interoperability. I would claim that all iCalendar clients use
mailto ids today. Plus plenty of other iCalendar infrastructure.
Changing this will result in interop issues and breaks a lot of stuff
for (IMO) no good reason.
b) The URN is completely opaque/proprietary to the client. It can't
possibly resolve a URN to a contact database or other things which
relate to attendees. This results in bad user experience and cross app
integration at multiple levels.
Note that my suggestion still includes a server specific UID which can
be used for a stable resolution - as long as clients preserve it. And
if not, its still sufficient for the far majority of real world
deployments (reassigning email addresses is a no go, don't understand
why people even consider that :-).
Cyrus claims that this is not viable because clients throw away X-
attributes. Does iCal do that? I think Kontact, Evo, Moz are all
preserving such (we certainly do).
Note: I'm fine with emitting URNs for stuff which can't possibly be
resolved. Resources or locations _might_ be in that category, though I
would still prefer an LDAP URL (+ UID X attr) if they are backed by
something like OD. This still gives the client a way to learn about
the ATTENDEE.
Thanks a lot,
Helge
--
Helge Hess
http://helgehess.eu/
More information about the calendarserver-dev
mailing list