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@mit.edu Per your suggestion, I look up wsanchez@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@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@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@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@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@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@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@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