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@def.de:urn:uid:98128912
over
ATTENDEE;X-CALSERVER-UID=98128912:mailto:abc@def.de or ATTENDEE;DIR=urn:uid:98128912:mailto:abc@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/ex...
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/