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

[Helge Heß]

On 26.06.2009, at 21:22, Wilfredo Sánchez Vega wrote:
>> a) the default of SCHEDULE-AGENT is changed from SERVER to CLIENT,
>>  this will make iCal server leave the ATTENDEE intact for
>>  regular CalDAV clients (if I understood you right)
>  This removes a very useful feature of scheduling-aware servers,  
> which is that a non-scheduling-aware client can still do simple  
> things like accept a meeting (by changing PARTSTAT) and all the  
> right scheduling magic still happens, because the server takes care  
> of it.

Well, yes, but there are no such clients. All clients I know of are  
(iMIP) scheduling aware. Which is my core point I guess.

Maybe we should be more specific about what clients we are talking:
- iCal.app  (no plugin API at all, completely proprietrary)
- Evolution (storage API)
- Kontact   (storage API)
- Mozilla   (no real 'storage' API, all done at client level?)
- Outlook   (storage API, iMIP like scheduling API)
any other? emClient? APIs?

>> Most of the existing CalDAV (*not* CalDAV scheduling) clients don't  
>> need to do anything special to support CalDAV.
>> Kontact, Evolution and Lightning are all based on an iCalendar  
>> internally. To support CalDAV, they 'just' need to replace the  
>> storage layer. Outlook is somewhat similiar, while the storage  
>> layer is pluggable, the whole scheduling part is not pluggable but  
>> handled in internal code (it still can be done, but its major work).
>>
>> They do need to do a lot more to become CalDAV scheduling clients.  
>> In fact most plugin architectures do not allow an easy replacement  
>> of the scheduling handling. (which is why I don't see this  
>> happening soon)
>
>  I guess I'm choosing to focus my priorities on scheduling-aware  
> clients, and those that are not can come along for the ride as best  
> as they can.

*All* existing clients _are_ (iMIP) scheduling aware. Its just that  
the scheduling isn't 'pluggable'.
In fact I don't know a single client which has pluggable scheduling  
(or no scheduling!). [we can/could explore some hacks in Outlook, but  
after all users are used to emails]

Its a bit like punishing standard focused clients (iMIP) for doing  
standards.


> I'm not sure I believe that they need a lot more to become  
> scheduling clients, but I can see how software that make assumptions  
> in their infrastructure will have challenges when new infrastructure  
> comes into play.

Yes. And standards which introduce new infrastructure w/o (seriously)  
considering backwards compatibility are usually not particulary  
successful.
But yeah, the iPhone will change everything ;-) [I'm actually serious  
on that one]


>>> The ATTENDEE property value is a delivery address.
>> When iCal is used in conjunction with iTIP, yes. If its used as a  
>> storage format, the ATTENDEE line represents a contact. And  
>> calendaring software rarely lives on its own, but usually  
>> integrates with contact management.
>   Unless the client sets SCHEDULE-AGENT=CLIENT, iTIP is always in  
> play.

Sure. My point was that the ATTENDEE is usually way more than an  
address for iTIP.

>  Yes.  We've decided to change the name of the X-APPLE-EMAIL  
> parameter to EMAIL and plan to register it after the iCalendar spec  
> update goes in.  (We're making the change prior to registration so  
> we don't have to figure out how to migrate from one to the other  
> later; I'm hard-pressed to think of why anyone might propose an  
> EMAIL parameter that isn't an email address.)

Sounds OK. Not sure I can parse the latter. But yes, there are not  
only SMTP email addresses. So if EMAIL is a URL/URN, it would be  
helpful. Not sure.


>> Thats the email stability issue. That an email address is  
>> reassigned is obviously as an edge case as it can get (one in a  
>> million?). That an email address is not working anymore isn't a big  
>> issue, its still a valid identifier.
>   Whoah.  That is not nearly the edge case you think it is.  At MIT  
> I recall that it happened fairly regularly while I was around, in  
> fact.

MIT isn't the center of the world either, its just a minor user in the  
overall scope :-) Much less than 0.001% of the users?
I'm not saying that some people won't do it, but they need to be aware  
of much more severe issues than just having wrongly routed meeting  
invitations ...


>> Also note that UUIDs also have their own 'stability' issues. Eg if  
>> a server is reinitialized, UUIDs become meaningless, while email  
>> addresses will still work.
>   Sure.  If you mis-configure or delete data on your server, bad  
> things happen.

Si, and emails as IDs are much more reliable in such scenarios (and  
others, eg migrations). But OK.


>> [Another thing which will (often!) happen in the real world is that  
>> a CalDAV server sends out iMIP messages but the replies will bypass  
>> the CalDAV server. Hence the client needs to remap the iMIP  
>> attendee info to the CalDAV attendee.]
>   On our server, the replies come back to the server.  The only case  
> where it does not is SCHEDULE-AGENT=CLIENT where the client does the  
> iMIP scheduling.

IMHO thats a gross misconception. Email sends and reception are highly  
dependend on the actual email setup and configuration. Just because  
iCal server is used as a calendaring server doesn't imply that its  
used as the primary email server nor that the primary will route back  
emails to it. In fact if it isn't the primary, its quite unlikely that  
the back-channel is setup properly (real world ignorant admin thing ;-)
I'm pretty sure that the iMIP back channel is b0rked for a very large  
part of the deployments. Replies will arrive in the clients via eMail,  
but w/o the iCal server getting involved.
(I asked the crystal ball, its going to be that way, trust it!)


>> Anyways, all that is nitpicking, it does not bring us anywhere.
>   Well, it may clarify some requirements.

I guess you need to decide how well you plan to support 'the' other  
clients. For ZideOne, we are probably going to support anything you  
come up with. Other clients will be constrained by resources, politics  
and sanity ;-)
Making it easier for them (by considering their setup), can make the  
relevant standards and servers more successful (IMHO).
Eg Kontact is quite popular in Germany, and it really excels at  
standards. I know no other client which has an iCalendar  
implementation as complete.

At this time even just plain CalDAV is mostly an Apple client thing,  
many servers don't really implement CalDAV, they only do the very  
specific subset required for iCal.app. Eg I was kinda shocked that  
Zimbra doesn't even support GET on event URLs! (probably because  
iCal.app happens to do always use REPORTs to fetch the data ...) And I  
really don't like that situation.
Pushing clients to rework their scheduling does not really help the  
matter ...


>> [reassigned email]
>>> Here's a simpler case: the server supports server-side iMIP (and  
>>> hey, by coincidence, ours does).  Should we send an iMIP message  
>>> to wsanchez at mit.edu as we normally do for which ATTENDEEs we don't  
>>> provide CalDAV delivery, or stick with the X-ID, or emit an error?
>> Don't know, very edgy edge case. Fact is, that the whole iMIP part  
>> breaks in this case anyways. Other iMIP clients will still have the  
>> old iMIP address and will deliver messages incorrectly. Which makes  
>> this one a non-point actually.
>   It's "very edgy" because you aren't writing the server.  For me,  
> it's a case I have to deal with.

Can't parse your response. The core issue is that other iMIP client  
will have the old address and you can't possibly deal with this,  
whether you write a server or not :-) If you allow iMIP, you need to  
live with its issues (eg reassigned emails). And you have to allow  
iMIP. Which significantly reduces the advantages of UUIDs.


>> As my conclusion so far, consider my points a) and b) at the top of  
>> the email. I have the impression that this would be an acceptable  
>> compromise?
>> A client which is sched-aware could use b) to do the addressbook  
>> integration stuff.
>   I'm not inclined to push for (a) as I mentioned above, but I agree  
> about (b).

I think CalConnect XV decided that (a) won't happen. IMHO its a  
mistake because it badly breaks the standards layering, but well.


>> Anyways, iCal server does not honour SCHEDULE-AGENT=CLIENT, it  
>> always replaces the ATTENDEE with the UUID.
>   That should be fixed now.

Nice. It doesn't really solve the issue that existing clients are  
doing iMIP, hence SCHEDULE-AGENT=CLIENT per default. But it at least  
makes it possible for CalDAV-Sched aware connectors to always inject  
that.

Greets,
   Helge