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

[Wilfredo Sánchez Vega]

On May 25, 2009, at 4:46 AM, Helge Heß 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.

> 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.

   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.

>> 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.

> BTW: using CALURI to store the UUID in a vCard is IMHO as  
> questionable as using DIR in ATTENDEEs for that purpose :-) [and has  
> the same id resolution issues attached]

   Agreed.

>> It tells the server who needs to be notified of changes to a  
>> meeting.  Your proposal to add an X-parameter (or DIR) with the  
>> authoritative delivery address does not comply with the spec, which  
>> requires that we use the value of the property.
>
> Fair enough, though only relevant for CalDAV-Sched clients.

   …if they set SCHEDULE-AGENT=CLIENT.

>> The only interesting argument I'm hearing against using a URN is  
>> that the client can't resolve that to something useful.  This is  
>> why our server is diligent about filling in the CN param regardless  
>> of whether it is provided, as well as added an X-param with the  
>> email address that you think is the best way to identify a user (we  
>> provide it so you can send email to the user, but you may use it as  
>> you wish).
>
> The X-APPLE-EMAIL thing does not help much (well, it does help me in  
> Outlook ...). My whole point is about not breaking existing things.  
> The X- thing just makes it slightly easier. Maybe spec an EMAIL  
> attribute then, similiar to DIR and CN?

   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.)

> I would also like to point out that I do NOT think that the email is  
> the best person/group/resource identifier per-se, its just the only  
> one which is reasonable interoperable.

   Understood.

>> Now, MIT tells me I can't keep my email address after more than a  
>> decade past graduation
>
> 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.

> Note that the server might still rewrite the email to its new email  
> based on the UUID. (iCal contains the pkey, but the directory  
> updated the email. Hence, on the next GET, the server might deliver  
> a new email).

   This is correct.

> 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.

> [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.

> Anyways, all that is nitpicking, it does not bring us anywhere.

   Well, it may clarify some requirements.

>> This is clearly a violation of the spec, and is not what the client  
>> asked me to do.  The client is asking me to use wsanchez at mit.edu as  
>> an attendee.  Let's say that following the spec is not all that  
>> important, because we are very smart and know better, so I notice  
>> that the email address is not in the directory, but my ID in there,  
>> so I delivery it to the new record, and perhaps I even update the  
>> property value to have the new email address.  Is this what you  
>> suggest?
>
> Yes, thats the additional smartness thing you might want to do. I  
> don't really suggest it though, I suggest to use email addresses,  
> always. Maybe give the user a chance to resolve it, if it can't be  
> found in the directory anymore.

   I don't consider that viable.  For one thing there is no way to ask  
the user to do anything except via the protocol.  There is no way in  
the protocol to specify that a client should ask for conflict  
resolution from the user, and I imagine that doing so property is more  
than a little bit of work.  Even assuming that, it requires that the  
server wait for a reply from the user, which could never come, before  
it continues with event processing.

> [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.

> Why would it ignore the change? It can perfectly detect that the  
> client *wants* to change the email.
> How thats implemented in the server, is the servers choice. It could  
> attempt to update the directory (often inappropriate, might depend  
> on the server type). I guess I would rather have an email address  
> field kept with the ID. NULL means, derive from directory, set  
> means, use what the client did provide.
> Another option would be to switch from SCHEDULE-AGENT=SERVER to  
> CLIENT. Or emit an error which tells the client its need to switch  
> to perform the change.

   Or I can expect clients to abide by the protocol spec and do what  
I'm doing now.

> 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).

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


   That should be fixed now.

	-wsv