[CalendarServer-users] calendar user address

[Mark Cockfield]

Hey Cyrus,

Works like a charm...much nicer than the alternative. Is it reasonable to
assume that there is no significance to the order the addresses are defined
in the accounts.xml file, and in the calendar-user-address-set PROPFIND
response?

It is becoming apparent that even the thinnest of clients needs to be able
to persist configuration, and that the property queries at startup are more
to discover changes in configuration than to discover the essence of their
being.

Thanks for the help.

Regards,

Mark

On 11/25/08 11:55 AM, "Cyrus Daboo" <cdaboo at apple.com> wrote:

> Hi Mark,
> 
> --On November 25, 2008 12:41:18 AM -0500 Mark Cockfield
> <mark.cockfield at gmail.com> wrote:
> 
>> The norm seems to be to use an email address, how do people handle the
>> case where a calendar user's email address changes? It seems to me that
>> every calendar object in the repository where the user is an organizer or
>> an attendee would have to be updated. If I understand the specs correctly
>> you could use a urn scheme except that iMIP requires a mailto.
> 
> Typically in an organization when a user's email address changes what often
> happens is that they end up with two addresses: the new one and the old
> one, with the new one being the "preferred" one. This is to ensure that for
> some period of time the old email address will continue to work (e.g. when
> replying to email addresses composed with the old address).
> 
> The calendar server does support multiple calendar user addresses and so,
> in the above scenario, no changes would be needed if the old and new email
> addresses are setup properly.
> 
> That said, there are situations where maintaining the old address is not
> feasible, and in that case something will need to be done. We have already
> discussed the idea of have the server re-write calendar data on the way
> into and out of the calendar store. We would change all mailto addresses to
> urn:uuid on the way in (client PUT), and change them back to the (current)
> mailto on the way out (client GET). That way the client always sees the
> most up to date address. There are several problems with this - in
> particular the need to force all clients to refresh their cached data when
> an address does change - that will require some clever ETag invalidation
> process.
> 
> For now though, the best option is to maintain the old and new email
> addresses.