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=...@def.de:urn:uid:29838484...
should be
ATTENDEE;X-CALENDARSERVER-UID=29838484:mailto:a...@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 he...@foo.com
today and then due h...@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 he...@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
_______________________________________________
calendarserver-dev mailing list
calendarserver-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-dev
