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

[Helge Heß]

Hi Wilfredo,

this is a very good reply, I know see much better where you are coming  
from :-)

On 20.05.2009, at 19:32, Wilfredo Sánchez Vega wrote:
> This is false.  When a client transmit email itself, it should  
> inform the server of this (schedule-agent=client) so that the server  
> does not also attempt delivery.

A regular CalDAV client won't set the SCHEDULE-AGENT header, there is  
nothing in the CalDAV spec which requires that. This is a CalDAV- 
Scheduling extension.

I think the interop issues (I see) mostly go away if:

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)

b) the CalDAV scheduling draft enhances the REPORTs, so that email
    addresses can be retrieved together with the iCal entity
    (point c in my mail of 2009-05-17)
    [even CalDAV-sched aware clients will base a lot of infrastructure
     on emails]

> You claim that clients might break due to assumption they have about  
> iMIP.  iMIP clients aren't going to just work with CalDAV; they have  
> to do something more in order to comply with the CalDAV spec.

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)


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

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]


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


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

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.


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

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

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.

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

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


>  What do you propose the server does here?  There is no longer a  
> directory record with wsanchez at mit.edu in it, so I can't locate the  
> ATTENDEE, even though it existed before.  I believe you imply that  
> in this case I can notice this and use my X-ID parameter to locate  
> the user instead.

Yes, I suggest that the server _always_ uses the X-ID parameter to  
locate the user if its present. In fact, I'm very much in favor in  
adding an additional, none X- parameter for that. Like:

   ATTENDEE
     ;SCHEDULE-AGENT=SERVER
     ;SCHEDULE-SERVER-ID=urn:uuid:298383-28382-3823
     :mailto:abc at def

Doesn't look too bad to me :-)

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


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

Sequence:
1. meeting with user B planned by user A client A
2. email reassigned from user A to user C
3. meeting status changed by user B via iMIP

Point is, all that email-deleted, email-changed thing happens super- 
rarely in the real world. And if it happens, there are bigger issues  
than dropped scheduling messages. (obviously emails send to the wrong  
account, which is why very few people reassign emails)


> You want to know which clients fail to preserve the X-ID parameter.   
> The reason this doesn't matter is that doing so doesn't always solve  
> the problem either.  if a client sees this:
>
> 	ATTENDEE;CN="Wilfredo Sanchez";X-ID=1:mailto:wsanchez at mit.edu
>
>  Let's say the client decides to change the email address because it  
> knows my mit.edu address is obsolete, and it has my new one.  It  
> otherwise wants to keep the information intact.  It doesn't know  
> what X-ID, but, being a good citizen, it doesn't monkey with it:
>
> 	ATTENDEE;CN="Wilfredo Sanchez";X-ID=1:mailto:wsanchez at wsanchez.net
>
>  Once again, should the server ignore this change and go with the X- 
> ID, or go with the address provided by the client?

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.


> All of this has to be defined, but it a whole lot simpler if we go  
> back to doing the right thing and conform to the specification.   
> Yes, that means I have to rely on clients doing so as well.

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.

Maybe also consider specifying a SCHEDULE-SERVER-ID and related  
semantics. Though I have no strong feelings about that part.

Thanks,
   Helge
-- 
http://zideone.com/