[CalendarServer-dev] UIDs as ATTENDEE IDs, please fix that
me at helgehess.eu
Fri May 15 16:31:36 PDT 2009
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
>> ATTENDEE;X-CALSERVER-UID=98128912:mailto:abc at def.de
>> 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-
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:
> 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
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
All that is _very_ disappointing.
More information about the calendarserver-dev