Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Server should normalize CUAs to a safely persistable form #185
Calendar user addresses come in many forms, and not all are "safely persistable". For example:
This is all fine until we change the server host name or port, then the CUA is no longer valid.
The server should normalize these addresses into a form that is unlikely to break if the server is reconfigured.
9/28/07 8:50 AM Cyrus Daboo:
Email addresses are available as calendar user addresses when a user has been assigned an email address in the directory. The client gets to pick the most appropriate calendar user address from all of the ones returned from the directory - and I believe iCal does currently pick the mailto over the http ones.
However, there are groups, resources and locations as well. Those are not assigned an email address in the directory because they do not have a mail service enabled. For those we currently have to use an http URI as the calendar user address (though we do also support a "urn:uuid" URI which does not encode server address, port etc).
Insisting that the directory assign email addresses to locations, resources just so they can take part in scheduling seems wrong - particularly as the email admin will likely not want to support mail delivery for those addresses.
9/28/07 10:17 AM Wilfredo Sanchez:
We probably should continue moving towards GUID-based identifiers everywhere, but the problem here is that users should never have to enter such a thing, and we (and the protocol) allow the client to choose which address scheme to use. Fixing that will require that the server rewrite events on PUT to normalize the addresses. email addresses are fragile as well, so I do think the urn:uuid: form we use on the bridge is safest. The question is whether a client will show these (ugly) URIs to the user and how it might reverse-map them to something meaningful info instead.
9/28/07 10:19 AM Wilfredo Sanchez:
This also means we'll end up always requiring the client to GET-after-PUT (as the bridge does) because we won't be storing byte-for-byte the same data the client sent. I'm OK with that, but Cyrus and the CalConnect folks are gonna have to come to grips with weak etags.
9/28/07 11:52 AM Cyrus Daboo:
I disagree that the server has to re-write mailto addresses to urns. I think that is taking "security" too far. First off, a calendar user address is not an authorization token - so having it re-used by a different user will not expose old data to the new user.
Really the worst that can happen is that existing invites for recurring meetings get sent to the new user event though they are different from the original user. But this is no worse than what happens with email. If I have an old email message from you in my Inbox and I reply to it, but you had left and someone else "inherited" your email address, then that other person will get an email I meant to go to you.
The one thing we do have the ability to do on the calendar server is to send out "cancellation" notices for all the old users pending invites and that way at least inform the organizer that that address is no longer valid (though we would need some extra pieces of protocol to make that work - e.g. for iCal to display the iCalendar COMMENT property).
9/28/07 1:42 PM Wilfredo Sanchez:
This isn't s security measure; it's making sure that the data we persist makes sense even if you reconfigure the server. If you use http:// URLs, then changing the server host name or port invalidates these addresses. If you use email addresses changing the mail server name or email account info (which are completely unrelated systems) break things. Both are pretty dumb. Users are most reliably identified by GUIDs.
The worst that can happen is that iCal doesn't let you edit your own events because it longer thinks you are the owner.
Sending cancellation notices is an altogether unrelated issue.
I don't know of any valid reason not to canonicalize addresses to a preferred form.
9/30/07 5:42 PM Cyrus Daboo:
I still disagree that the server should do this behind the back of the client. After all if the client has no knowledge of the canonicalised form then we are back to the non-editable event problem.
I also disagree that users are best identified by GUIDs. Email has used emailed addresses for decades and the problems with that are known and dealt with in trivial ways (e.g. forwarding from the old account to the new one, the client being able to recognize multiple addresses as belonging to a user etc). What's more GUIDs are not easily resolvable to servers - this is important when we do cross-domain scheduling. Users will have to be identified by a URI scheme that will allow easy mapping from the URI to a server hostname/domain so that remote scheduling can work. urn:uuid is not going to work form that.
Now the question is whether an email address is sufficient or whether we need a new URI scheme for calendar user addresses. Arguably an email address will suffice for 90% of people once we get to the state where sites, ISPs etc offer calendaring in addition to email. A new URI scheme or different identifier for calendar user address gets problematic when you realize you need to pass those around between users etc. Whilst there is a spec extending vcard and LDAP with attributes for calendar user address, those are not widely supported. At the very least we would need those and need UIs such as AddressBook to support a new "calendar address" field in the same manner it does email.
Of course these are issues that go beyond what we are doing here, and there has been a fair bit of discussion about this in Calconnect and that is picking now that we are actively working on server-to-server scheduling, where calendar user addresses, discoverability etc are important.
10/1/07 12:07 PM Wilfredo Sanchez:
... "After all if the client has no knowledge of the canonicalised form then we are back to the non-editable event problem." ...
The same is true if another client comes in and writes an event down using a different CUA than the first client used. The client knows about the canonicalised form is if asks the server for the CUA set, which is should do, and iCal does.
... I also disagree that users are best identified by GUIDs. Email has used emailed addresses ...
This isn't email. It's calendaring. From the server's point of view GUIDs are 100% reliable, and email addresses are usually reliable. That sounds a lot to me like GUIDs are better. 90% is worse than 100%.
... What's more GUIDs are not easily resolvable to servers ...
Neither are email addresses, and let's not pretend that they are, because there is no requirement than email addresses are in a domain with any relation to the calendar server. Not the same service, not even necessarily related.
This is a valid problem, but email addresses do not solve it, so let's not dive into a rathole and confuse these two separate issues here.
... once we get to the state where sites, ISPs etc offer calendaring in addition to email ...
Seriously? You think we should depend on ISPs to get with the program before our stuff should work reliably?
10/2/07 8:22 AM Cyrus Daboo:
Email addresses are easily resolved to email servers using MX records. How to resolve a calendar user address to a calendar server is not defined right now, but it will likely use a similar DNS-based mechanism. As such it will be important to have a domain-based URI scheme used for the calendar user address.
Yahoo bought Zimbra. Zimbra has Comcast as a customer (and they are one of the biggest ISPs around). Zimbra supports CalDAV (and I believe scheduling too). So this is a very real possibility.