[CalendarServer-dev] UIDs as ATTENDEE IDs, please fix that

[Wilfredo Sánchez Vega]

On May 1, 2009, at 8:05 AM, Helge Heß wrote:


> 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.

   Well, I disagree with the assertion that there is 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.

   The ATTENDEE value is a URI, and doesn't have to be a mailto: URI.   
I recognize that most agents have used mailto:, but iMIP is the  
primary transport for iTIP in most agents.  I don't believe that it is  
reasonable for a CalDAV client to continue to assume that email  
addresses will always be used to identify attendees.

   The ATTENDEE value is a primary key on the calendar server for  
identifying a user.  An email address is a delivery address on an  
email server, which may be (and is, in our case) on a separate and  
unrelated server.  It is not tenable to have the primary key in our  
system be controlled by a separate system that we have no visibility  
into.

   Additionally, email addresses are not immutable.  You might be helge at foo.com 
  today and then due hess at foo.com tomorrow.  Again, we have no  
visibility into that, and no way to know these are the same two  
people, and absolutely no way to know that helge at foo.com two days from  
now is actually Joe Helge, who just joined Foo Corp.

> 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.

   LDAP might work if the server was always bound to an LDAP service,  
and even then requires the client to implement another protocol, and  
still then assumes that the client has access to the LDAP server.

   Instead, we provide a REPORT query that can resolve a calendar user  
address (including email, if we think we can uniquely identify a  
principal with it) into a principal URL and additional attributes,  
including full name, email, etc. so that you can do all of this via  
CalDAV.

   For expediency, we also provide email as a parameter, as you note  
to clients, as we do with the full name.  In the future, we may offer  
up a URL to a CardDAV record.

   Both of these (the parameters and the new REPORT) need to be  
standardized for interoperability.

	-wsv