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

[Helge Heß]

On 16.05.2009, at 00:45, Wilfredo Sánchez Vega wrote:
> On May 6, 2009, at 10:10 AM, Helge Heß wrote:
>> Please elaborate. Whats the advantage of
>>
>> ATTENDEE;X-EMAIL=abc at def.de:urn:uid:98128912
>>
>> over
>>
>> ATTENDEE;X-CALSERVER-UID=98128912:mailto:abc at def.de
>> or
>> ATTENDEE;DIR=urn:uid:98128912:mailto:abc at 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)
>
>  The advantage is that the primary value of the property corresponds  
> to the primary key on my server, and this is unlikely to break.

The likeliness that it will break is quite high, obviously. While some  
clients might conform with the iCal RFC and support arbitrary ATTENDEE  
URLs, only emails are widely deployed and tested.

Obviously iMIP is the only kind-of-standard actually deployed for  
scheduling, and the UUIDs completely fail with that. And that won't  
change anytime soon, given that 80% of the deployed groupware systems  
(Domino/Exchange) won't support CalDAV scheduling any time soon, so  
iMIP is crucial at least for 5+ years.

And the most important thing is still, that the pkey is completely  
opaque to the client. Hence, it can't possibly integrate attendees  
with existing contact management systems. And thats just a no-go.

> I'm not convinced that parking a GUID in DIR is a valid use of DIR,  
> nor that DIR is any safer than an X-parameter.

I guess I tend to agree. DIR is standardized though, less software is  
allowed to drop it. (formally, in practice software which drops either  
is buggy ...)

> I'm not inclined to trust all clients to do the right thing  
> according to the spec.  This apparently includes not assuming that  
> the value is an email address, per the spec, but I'm willing to live  
> with that if it keeps my primary keys intact.

Well, IMHO its a very weird balancing of things.

Situation a) UUID attendees
- clients might break
- server definitely breaks if clients break

Situation b) UUID in X-
- client might loose X- (though, thats a theory, no specifics!)
- server still does NOT break in 99% of the cases, since it
   fallbacks to emails

So yes, you might loose a distinct primary key. You must be prepared  
to that anyways, since a client is also free to transmit emails or  
whatever it wants at any time.


I fail to comprehend your position given that:
a) you fail to name clients which would actually loose your X-
    property
b) clients which might loose your X- property, would still work
    very well, given that you must deal with email matching anyways


>> 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?
>   report_DAV__principal_property_search here:
>  http://trac.calendarserver.org/browser/CalendarServer/trunk/twistedcaldav/extensions.py
>
>  Though that may be reorganized in a bit.  I'm guessing Cyrus will  
> write up a spec for that in a bit as well.

Oh well. Thats really one of the few aspects which already works  
reasonably well in the real world. Why add even more API/standards for  
that.


So far, I still miss a good reason. That a server wants to embed its  
own ID is perfectly viable - and perfectly possible via X-.
But breaking working stuff? Implemented in iMIP and many clients? That  
just doesn't seem to be viable.

Clients won't follow you on the UID thing, thats pretty much for sure.  
It will be a solution which can only work well Apple<->Apple.
The ATTENDEE id you came up with is completely proprietary and  
unresolvable. No addressbook integration possible (w/o Apple specific  
hacks).

All that is _very_ disappointing.

Sorry,
   Helge
-- 
Helge Hess
http://helgehess.eu/