UIDs as ATTENDEE IDs, please fix that
Hi, CalServer switched to use URNs/UIDs as ATTENDEE identifies. I think thats a really BIG mistake, I feel very strongly about it ;-) and would like to see that behaviour modified. Currently: ATTENDEE;X-CALENDARSERVER-EMAIL=abc@def.de:urn:uid:29838484... should be ATTENDEE;X-CALENDARSERVER-UID=29838484:mailto:abc@def.de or even ATTENDEE;X-CALENDARSERVER-UID=29838484:tel:+49-12234-233 Why? There are two big reasons: a) Interoperability. I would claim that all iCalendar clients use mailto ids today. Plus plenty of other iCalendar infrastructure. Changing this will result in interop issues and breaks a lot of stuff for (IMO) no good reason. b) The URN is completely opaque/proprietary to the client. It can't possibly resolve a URN to a contact database or other things which relate to attendees. This results in bad user experience and cross app integration at multiple levels. Note that my suggestion still includes a server specific UID which can be used for a stable resolution - as long as clients preserve it. And if not, its still sufficient for the far majority of real world deployments (reassigning email addresses is a no go, don't understand why people even consider that :-). Cyrus claims that this is not viable because clients throw away X- attributes. Does iCal do that? I think Kontact, Evo, Moz are all preserving such (we certainly do). Note: I'm fine with emitting URNs for stuff which can't possibly be resolved. Resources or locations _might_ be in that category, though I would still prefer an LDAP URL (+ UID X attr) if they are backed by something like OD. This still gives the client a way to learn about the ATTENDEE. Thanks a lot, Helge -- Helge Hess http://helgehess.eu/
On May 1, 2009, at 8:05 AM, Helge Heß wrote:
CalServer switched to use URNs/UIDs as ATTENDEE identifies. I think thats a really BIG mistake, I feel very strongly about it ;-) and would like to see that behaviour modified.
Currently: ATTENDEE;X-CALENDARSERVER-EMAIL=abc@def.de:urn:uid:29838484...
should be ATTENDEE;X-CALENDARSERVER-UID=29838484:mailto:abc@def.de or even ATTENDEE;X-CALENDARSERVER-UID=29838484:tel:+49-12234-233
Why? There are two big reasons:
a) Interoperability. I would claim that all iCalendar clients use mailto ids today. Plus plenty of other iCalendar infrastructure. Changing this will result in interop issues and breaks a lot of stuff for (IMO) no good reason.
Well, I disagree with the assertion that there is no good reason.
b) The URN is completely opaque/proprietary to the client. It can't possibly resolve a URN to a contact database or other things which relate to attendees. This results in bad user experience and cross app integration at multiple levels.
The ATTENDEE value is a URI, and doesn't have to be a mailto: URI. I recognize that most agents have used mailto:, but iMIP is the primary transport for iTIP in most agents. I don't believe that it is reasonable for a CalDAV client to continue to assume that email addresses will always be used to identify attendees. The ATTENDEE value is a primary key on the calendar server for identifying a user. An email address is a delivery address on an email server, which may be (and is, in our case) on a separate and unrelated server. It is not tenable to have the primary key in our system be controlled by a separate system that we have no visibility into. Additionally, email addresses are not immutable. You might be helge@foo.com today and then due hess@foo.com tomorrow. Again, we have no visibility into that, and no way to know these are the same two people, and absolutely no way to know that helge@foo.com two days from now is actually Joe Helge, who just joined Foo Corp.
Note that my suggestion still includes a server specific UID which can be used for a stable resolution - as long as clients preserve it. And if not, its still sufficient for the far majority of real world deployments (reassigning email addresses is a no go, don't understand why people even consider that :-).
Cyrus claims that this is not viable because clients throw away X- attributes. Does iCal do that? I think Kontact, Evo, Moz are all preserving such (we certainly do).
Note: I'm fine with emitting URNs for stuff which can't possibly be resolved. Resources or locations _might_ be in that category, though I would still prefer an LDAP URL (+ UID X attr) if they are backed by something like OD. This still gives the client a way to learn about the ATTENDEE.
LDAP might work if the server was always bound to an LDAP service, and even then requires the client to implement another protocol, and still then assumes that the client has access to the LDAP server. Instead, we provide a REPORT query that can resolve a calendar user address (including email, if we think we can uniquely identify a principal with it) into a principal URL and additional attributes, including full name, email, etc. so that you can do all of this via CalDAV. For expediency, we also provide email as a parameter, as you note to clients, as we do with the full name. In the future, we may offer up a URL to a CardDAV record. Both of these (the parameters and the new REPORT) need to be standardized for interoperability. -wsv
On 06.05.2009, at 18:52, Wilfredo Sánchez Vega wrote:
Well, I disagree with the assertion that there is no good reason.
Please elaborate. Whats the advantage of ATTENDEE;X-EMAIL=abc@def.de:urn:uid:98128912 over ATTENDEE;X-CALSERVER-UID=98128912:mailto:abc@def.de or ATTENDEE;DIR=urn:uid:98128912:mailto:abc@def.de Thats the core of my claim of 'no good reason'. Your requirements can be met w/o breaking anything existing. (if this does break with some client, please tell us which) Further, as I said, there is no way for a client to resolve a UID to some contact record. You talk about a REPORT to resolve UIDs, I suppose this might be OK. Whats this REPORT? BTW1: using properties for lastname/firstname etc is rather useless, since properties are not covered by etags, hence uncachable. BTW2: a vCard URL would be nice. (doesn't even have to be CardDAV, plain URL pointing to a vCard would be fine, similiar to FBURL)
Both of these (the parameters and the new REPORT) need to be standardized for interoperability.
Well, yes, I also thought that we might want to standardize a UID parameter to avoid an X-CALSERVER-UID. But then, this is basically what DIR already provides. Thanks, Helge -- Helge Hess http://helgehess.eu/
On May 6, 2009, at 10:10 AM, Helge Heß wrote:
Please elaborate. Whats the advantage of
ATTENDEE;X-EMAIL=abc@def.de:urn:uid:98128912
over
ATTENDEE;X-CALSERVER-UID=98128912:mailto:abc@def.de or ATTENDEE;DIR=urn:uid:98128912:mailto:abc@def.de
Thats the core of my claim of 'no good reason'. Your requirements can be met w/o breaking anything existing. (if this does break with some client, please tell us which)
The advantage is that the primary value of the property corresponds to the primary key on my server, and this is unlikely to break. I'm not convinced that parking a GUID in DIR is a valid use of DIR, nor that DIR is any safer than an X-parameter. I'm not inclined to trust all clients to do the right thing according to the spec. This apparently includes not assuming that the value is an email address, per the spec, but I'm willing to live with that if it keeps my primary keys intact.
Further, as I said, there is no way for a client to resolve a UID to some contact record. You talk about a REPORT to resolve UIDs, I suppose this might be OK. Whats this REPORT?
report_DAV__principal_property_search here: http://trac.calendarserver.org/browser/CalendarServer/trunk/twistedcaldav/ex... Though that may be reorganized in a bit. I'm guessing Cyrus will write up a spec for that in a bit as well.
BTW1: using properties for lastname/firstname etc is rather useless, since properties are not covered by etags, hence uncachable.
It's useless for caching, perhaps. That doesn't make it useless, though it might make it worthless to you. WebDAV has its flaws as regards properties and caching.
BTW2: a vCard URL would be nice. (doesn't even have to be CardDAV, plain URL pointing to a vCard would be fine, similiar to FBURL)
Agreed.
Both of these (the parameters and the new REPORT) need to be standardized for interoperability.
Well, yes, I also thought that we might want to standardize a UID parameter to avoid an X-CALSERVER-UID. But then, this is basically what DIR already provides.
On 16.05.2009, at 00:45, Wilfredo Sánchez Vega wrote:
On May 6, 2009, at 10:10 AM, Helge Heß wrote:
Please elaborate. Whats the advantage of
ATTENDEE;X-EMAIL=abc@def.de:urn:uid:98128912
over
ATTENDEE;X-CALSERVER-UID=98128912:mailto:abc@def.de or ATTENDEE;DIR=urn:uid:98128912:mailto:abc@def.de
Thats the core of my claim of 'no good reason'. Your requirements can be met w/o breaking anything existing. (if this does break with some client, please tell us which)
The advantage is that the primary value of the property corresponds to the primary key on my server, and this is unlikely to break.
The likeliness that it will break is quite high, obviously. While some clients might conform with the iCal RFC and support arbitrary ATTENDEE URLs, only emails are widely deployed and tested. Obviously iMIP is the only kind-of-standard actually deployed for scheduling, and the UUIDs completely fail with that. And that won't change anytime soon, given that 80% of the deployed groupware systems (Domino/Exchange) won't support CalDAV scheduling any time soon, so iMIP is crucial at least for 5+ years. And the most important thing is still, that the pkey is completely opaque to the client. Hence, it can't possibly integrate attendees with existing contact management systems. And thats just a no-go.
I'm not convinced that parking a GUID in DIR is a valid use of DIR, nor that DIR is any safer than an X-parameter.
I guess I tend to agree. DIR is standardized though, less software is allowed to drop it. (formally, in practice software which drops either is buggy ...)
I'm not inclined to trust all clients to do the right thing according to the spec. This apparently includes not assuming that the value is an email address, per the spec, but I'm willing to live with that if it keeps my primary keys intact.
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. I fail to comprehend your position given that: a) you fail to name clients which would actually loose your X- property b) clients which might loose your X- property, would still work very well, given that you must deal with email matching anyways
Further, as I said, there is no way for a client to resolve a UID to some contact record. You talk about a REPORT to resolve UIDs, I suppose this might be OK. Whats this REPORT? report_DAV__principal_property_search here: http://trac.calendarserver.org/browser/CalendarServer/trunk/twistedcaldav/ex...
Though that may be reorganized in a bit. I'm guessing Cyrus will write up a spec for that in a bit as well.
Oh well. Thats really one of the few aspects which already works reasonably well in the real world. Why add even more API/standards for that. So far, I still miss a good reason. That a server wants to embed its own ID is perfectly viable - and perfectly possible via X-. But breaking working stuff? Implemented in iMIP and many clients? That just doesn't seem to be viable. Clients won't follow you on the UID thing, thats pretty much for sure. It will be a solution which can only work well Apple<->Apple. The ATTENDEE id you came up with is completely proprietary and unresolvable. No addressbook integration possible (w/o Apple specific hacks). All that is _very_ disappointing. Sorry, Helge -- Helge Hess http://helgehess.eu/
OK, rereading the thread it sounds like you refuse to fix it. I guess there is little we can do about it besides filing bug reports listing Lightning, Evolution, Kontact, ... interoperability issues :-) So lets focus on how a client can resolve the 'Apple way' GUIDs and how all that works internally. a) if a client PUTs a message with attendees like that: ATTENDEE:mailto:abc@def.de CalServer will lookup the mailto in its directory and replace it with: ATTENDEE;X-CALENDAR-SERVER-EMAIL=abc@def.de:urn:uuid:29382.. The server will do this instantly and the client needs to do a GET after each PUT. a1) Question: what happens if the mailto is not in the local directory, but points to an external participant? (eg comes from a CardDAV server) a2) Can you return modified content in the PUT response, with a 200 OK instead of requiring a reGET? (not sure whether that would be OK will HTTP) b) if a client PUTs a message with an attendee and a GUID like that: ATTENDEE:urn:uuid:98283... The UUID is not a CalServer one, its created by the client (or some other server). What will happen with that, stored as-is? c) you mention that there will be an Apple specific REPORT to retrieve information about GUID attendees. To avoid additional HTTP IO, can we have it that way: <?xml version="1.0"?> <C:calendar-multiget xmlns="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav" xmlns:A="http://calendarserver.org/ns/"> <prop> <getetag/><getcontenttype/> <C:calendar-data/> <A:attendee-info> <A:uuid/> <D:principal-URL/> <D:displayname/> <D:email/> </A:attendee-info> </prop> </C:calendar-multiget> Or something similiar. Core point is, that the required info can be retrieved in one step (simple GETs become useless ...) Thanks, Helge ... still hoping that there will be an option to make the server do it the X-APPLE-UUID way. -- http://zideone.com/
Sorry I'm so slow to reply to these, because this is a good conversation to have, and you are making me think about this harder, which is good. But a bunch of things are landing at the same time here, including a conference next week that I have to be ready for. :-) Anyone at Apple WWDC who want to have this conversation in person, come find me at the IT Lab after the Calendaring Talk on Tuesday. Anyoen at CalConnect this week, I'll be at the Roundtable, time permitting. -wsv
On 02.06.2009, at 10:32, Wilfredo Sánchez Vega wrote:
But a bunch of things are landing at the same time here, including a conference next week that I have to be ready for. :-)
;-)
Anyone at Apple WWDC who want to have this conversation in person, come find me at the IT Lab after the Calendaring Talk on Tuesday. Anyoen at CalConnect this week, I'll be at the Roundtable, time permitting.
I'm leaving on Sunday and won't be at the WWDC, but I'm at the Roundtable. Anyways, iCal server does not honour SCHEDULE-AGENT=CLIENT, it always replaces the ATTENDEE with the UUID. There also seems to be agreement that SCHEDULE-AGENT=SERVER will stay the default. (which I dislike, but can't do anything about :-) Thanks, Helge -- Helge Hess http://helgehess.eu/
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
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@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@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@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@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@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?
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/
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@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@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
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@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
Hi, stupid question: what is supposed to happen if the clients write an iCal file with a UID to the server? Eg: ATTENDEE;EMAIL="hh@zideone.com":urn:uid:299282-29393... Will the server reject that? Will it rewrite the ATTENDEE URN-UID based on the EMAIL? Will it preserve the UID? Thanks, Helge -- Helge Hess http://zideone.com/
Hi Helge, --On July 1, 2009 1:25:43 PM +0200 Helge Heß <me@helgehess.eu> wrote:
stupid question: what is supposed to happen if the clients write an iCal file with a UID to the server? Eg:
ATTENDEE;EMAIL="hh@zideone.com":urn:uid:299282-29393...
Will the server reject that? Will it rewrite the ATTENDEE URN-UID based on the EMAIL? Will it preserve the UID?
If the uuid value is recognized as a valid user on the server it will re-write the CN= and EMAIL= parameters to match values appropriate for that principal. If the uuid is not recognized the server will not change the property at all. -- Cyrus Daboo
participants (3)
-
Cyrus Daboo
-
Helge Heß
-
Wilfredo Sánchez Vega