Re: [calsify] RFC7986 and EMAIL parameter

[Cyrus Daboo <[e-mail]>]

Hi Michael,

--On Tue, 16 Feb 2021 23:46:31 -0500 Michael Douglass 
<[e-mail]> wrote:

Some background first: when we were working on CalendarServer and deploying 
it within Apple, we initially used email addresses as the ORGNAIZER/ATTENDEE 
calendar user address value. However, we quickly ran into a problem with 
that: it turns out that there are frequent email address (and name) changes 
that happen for individuals for a variety of reasons, and we needed a way to 
change the mailto: values. Doing that with scheduling messages is 
problematic because it requires rewriting/resending invites to all 
particpants. With recurring messages, we probably would not want to re-write 
past instances, so that would require "splitting" the recurrence.

In the end we decided on a different solution: internally, the server would 
use a `urn:uuid` URI for the calendar user address values. Those URIs were 
the stable directory GUID for each user, and would not change even if other 
properties of the user record did (email, name, etc). So CalendarServer 
would return urn:uuid values in any iCalendar data transmitted over CalDAV. 
But when sending scheduling messages externally (via iMIP and iSchedule, 
when that was a thing) we would rewrite the ORGANIZER and ATTENDEE property 
values to the current value of the corresponding user's email address URI. 
Similarly, for scheduling messages being delivered from an outside source 
into the server, we would rewrite the mailto URIs to urn:uuid ones.

There were some client-side implications to this: the client does an 
attendee auto-complete when an organizer is adding attendees to an event. It 
does that using the CalDAV principal search, querying on name, email etc, 
and it extracts one of several prossible calendar user addresses for the 
attendee and inserts that into the iCalendar object sent to the server. The 
server always rewrites incoming (PUT) iCalendar data to "normalize" 
ORGANIZER and ATTENDEE property values to the urn:uuid form.

The problem with this on the client side, was that they wanted to be able to 
relate calendar particpants to address book entries, so that they could show 
additional details about the attendee (i.e., show a telephone number, or IM 
contact info etc). However, the urn:uuid values are not in any contacts 
records (yes we - Apple/CalConnect - had lots of dicussions about the need 
for a separate calendar user address field in contact databases but there 
was never consensus on how best to do that, or even whether users would 
grasp the purpose). So, to allow the client to match urn:uuid values to 
local contact data, we added the EMAIL parameter. The server always rewrites 
the EMAIL parameter to the most recent value for incoming (PUT)/outgoing 
(GET) events sent over CalDAV, so there is a strong liklihood it will match 
a contact (or match a record in the directory service the AddressBook.app 
can use). Also, in the case no contact could be matched, the EMAIL value 
could be used as an alternative, out-of-band, way to contact the particpant 
over email.

> So
>
> question 1:
>
> Is it the case that the value - the calendar address is still the
> identifier for the attendee?

Yes, the calendar user address is always the "key" for identifying/matching 
ORGANIZER and ATTENDEE properties across iCalendar objects, be they distinct 
events or recurrence instances.

> Question 2:
>
> is it legal to send a REPLY back with a different EMAIL value - e.g.
> attendee decides they want to use a different email address?

The EMAIL parameter value was never intended to be an iMIP address used for 
scheduling. The calendar user address value of the relevent iCalendar 
property would always be the scheduling address. We handled that by always 
rewriting iCalendar data on the way into, and out of, our external 
scheduling system.

> Question 3:
>
> Does "Recipients can also use this value as an alternative means of
> contacting the calendar user via email." include sending iMip messages?

As per above, no, it was never intended that EMAIL be used for iMIP. It is 
important to note, that some calendar systems allow users to "sign-up" using 
a 3rd party email address as their "identifier", but generate their own 
mailto calendar user address for iMIP (usually with a domain set to the 
calendar server host and an "opaque" identifier for thew local part). In 
such a case there could be two email addresses on a property: one in the 
EMAIL paramater (the 3rd party address that could be matched to a contact 
record); and the other the calendar user address value in the property.

> Question 4: (already past a 'couple')
>
> 5546 says:
>
>     When used to provide a delegation response,
>     the "Delegator" SHOULD include the calendar address of the "Delegate"
>     on the "DELEGATED-TO" property parameter of the "Delegator's"
>     "ATTENDEE" property.  The "Delegate" SHOULD include the calendar
>     address of the "Delegator" on the "DELEGATED-FROM" property parameter
>     of the "Delegate's" "ATTENDEE" property.
>
> So that implies that the DELEGATED-TO value might also be a non mailto URI?
> 7986 says nothing about these parameters

Those parameters typically reference other ATTENDEE properties (via the 
calendar user address value) and those other properties can have an EMAIL 
parameter that can be used with the delegate.

> I assume that we could have something like:
>
> ATTENDEE;CN=Michael
> Douglass;PARTSTAT=ACCEPTED;ROLE=CHAIR;EMAIL=[e-mail] <mailto:
> [e-mail]>:/sadlksdfkkljklkjjklljkkjjLKJLKJjLKjJKLKLjJKLLkjKj
> LkjLKJ/principal/

I think the EMAIL parameter value is wrong (at the very least it is missing 
some DQUOTEs). It should just be the address spec, not the full address. I 
think that is my fault as I know see that 7986 did not properly define the 
parameter value. It just said "email address", but shouyld have references 
RFC5322 3.4.1 for the addr-spec definition.

> ATTENDEE;CN=Another Michael Douglass;PARTSTAT=ACCEPTED;DELEGATED-TO="/sadlk
> sdfkkljklkjjklljkkjjLKJLKJjLKjJKLKLjJKLLkjKjLkjLKJ/principal/";EMAIL=mikead
> [e-mail] <mailto:[e-mail]>:/aMzkzNTI4MzkzNTI4MzkzNQ
> PuXCcDTdG5iXfOhcljjCSqMYrUXDcs6f1z7CyXejTR/principal/

Same issue with EMAIL parameter value. However, the concept of relating 
properties via the DELEGATED-* parameters is fine.

BTW: I am not sure the calendar user address values in your example are 
legal. As per RFC 3986, there should be a "scheme:" prefix present.

-- 
Cyrus Daboo