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

[Wilfredo Sánchez Vega]

On May 15, 2009, at 4:31 PM, Helge Heß wrote:

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

   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.  In this case, I don't care about the  
property value, because the client is dealing with it, and the server  
should not modify it.  This isn't what we are talking about here,  
though.

> I fail to comprehend your position given that:
> a) you fail to name clients which would actually loose your X-
>   property

   I don't mention this because it doesn't matter which clients do it  
or not; your proposed changed don't solve the problem.

> b) clients which might loose your X- property, would still work
>   very well, given that you must deal with email matching anyways

   I'll get to that below.

   Email addresses are obviously important to iMIP, and iMIP isn't  
going away any time soon.  No dispute there.  I don't claim that UUIDs  
work for iMIP, but I'm not implementing an iMIP server; I'm  
implementing a CalDAV server.

   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.   
That should include dealing with whatever URI is in the ATTENDEE  
property.

   The ATTENDEE property value is a delivery address.  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.

   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 important thing is that this data is advisory, and not the  
authoritative delivery address, which remains the value of the property.

   For example:

   You send the server a meeting with:

	ATTENDEE;CN="Wilfredo Sanchez":mailto:wsanchez at mit.edu

   Per your suggestion, I look up wsanchez at mit.edu in my directory  
system and find the record with ID 1, so I tack on my ID:

	ATTENDEE;CN="Wilfredo Sanchez";X-ID=1:mailto:wsanchez at mit.edu

   Now, MIT tells me I can't keep my email address after more than a  
decade past graduation, so I get my directory record updated to wsanchez at wsanchez.net 
.  Then you update the meeting my changing the time to the next day.

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

   That's pretty good, as it clearly works well enough in this case.

   So what if the in the same day that I lost my mit.edu email, it was  
given to someone else.  So now in the directory, we have a new record  
with ID 2 and my old email address, as well as the old record with ID  
1 and my new email address.  Should we:

	1) use the X-ID because we know better
	2) use the mit.edu email address because that's what the client asked  
for
	3) raise an error to the client and hope that it can tell the user  
something useful

   #1 is the one that works, though still in violation of the spec.   
Note that this situation may seem contrived, and it is, but it is  
something we have to deal with.  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?

   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?

   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.

	-wsv