[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