Subject: [calsify] RFC7986 and EMAIL parameter

From: Michael Douglass <[email-masked]>
Date: Tue, 16 Feb 2021 23:46:31 -0500

I wonder if Cyrus could help clarify a couple of issues.

The text says:

  Description:  This property parameter MAY be specified on "ORGANIZER"
       or "ATTENDEE" properties.  This property can be used in situations
       where the calendar user address value of the "ORGANIZER" and
       "ATTENDEE" properties is not likely to be an identifier that
       recipients of scheduling messages could use to match the calendar
       user with, for example, an address book entry.  The value of this
       property is an email address that can easily be matched by
       recipients.  Recipients can also use this value as an alternative
       means of contacting the calendar user via email.  If a recipient's
       calendar user agent allows the recipient to save contact
       information based on the "ORGANIZER" or "ATTENDEE" properties,
       those calendar user agents SHOULD use any "EMAIL" property
       parameter value for the email address of the contact over any
       mailto: calendar user address specified as the value of the
       property.  Calendar user agents SHOULD NOT include an "EMAIL"
       property parameter when its value matches the calendar user
       address specified as the value of the property.

So

question 1:

Is it the case that the value - the calendar address is still the 
identifier for the attendee?

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?

Question 3:

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

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

I assume that we could have something like:

ATTENDEE;CN=Michael 
Douglass;PARTSTAT=ACCEPTED;ROLE=CHAIR;EMAIL=[email-masked] 
<mailto:[email-masked]>:/sadlksdfkkljklkjjklljkkjjLKJLKJjLKjJKLKLjJKLLkjKjLkjLKJ/principal/

ATTENDEE;CN=Another Michael 
Douglass;PARTSTAT=ACCEPTED;DELEGATED-TO="/sadlksdfkkljklkjjklljkkjjLKJLKJjLKjJKLKLjJKLLkjKjLkjLKJ/principal/";EMAIL=[email-masked] 
<mailto:[email-masked]>:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOhcljjCSqMYrUXDcs6f1z7CyXejTR/principal/

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 17 Feb 2021 10:22:57 -0500

Hi Michael,

--On Tue, 16 Feb 2021 23:46:31 -0500 Michael Douglass 
<[email-masked]> 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.

> 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.

> 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.

> 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.

> 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.

> Douglass;PARTSTAT=ACCEPTED;ROLE=CHAIR;EMAIL=[email-masked] <mailto:
> [email-masked]>:/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
> [email-masked] <mailto:[email-masked]>:/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

---

From: Michael Douglass <[email-masked]>
Date: Wed, 17 Feb 2021 11:04:41 -0500

Thanks Cyrus.

See below

On 2/17/21 10:22, Cyrus Daboo 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.
>
> 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:
>>
> 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:
>>
> 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:
>>
> 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.
>
I think I meant only if the value is not a mailto:. I assume in the 
absence of any other indication (e.g. a valid email) this might be a 
fallback?

> 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.
>
>> <mailto:
> 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.
>
>> Douglass;PARTSTAT=ACCEPTED;DELEGATED-TO="/sadlk
>> [email-masked] 
>> <mailto:[email-masked]>:/aMzkzNTI4MzkzNTI4MzkzNQ
> 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.

One of those was generated by Apple. I created an event yesterday which 
in full is

BEGIN:VCALENDAR
PRODID:-//CALENDARSERVER.ORG//NONSGML Version 1//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
DTEND;TZID=America/New_York:20210219T100000
DTSTART;TZID=America/New_York:20210219T090000
ORGANIZER;CN=Michael Douglass;EMAIL=[email-masked]:mailto:2_GM4T
  GNJSHAZTSMZVGI4DGOJTGW7UOVQIXU6S7IXFKVSLJVS4VP4YX5J2UCRWN6KC2YMIGY25PWAA
  [email-masked]
UID:E5C6F579-5003-4755-B29D-572E0FF147B1
DTSTAMP:20210217T051817Z
SEQUENCE:1
SUMMARY:Testing email param
LAST-MODIFIED:20210217T051817Z
CREATED:20210217T051744Z
ATTENDEE;CUTYPE=INDIVIDUAL;EMAIL=[email-masked];RSVP=TRUE;PARTSTA
  T=NEEDS-ACTION:mailto:[email-masked]
ATTENDEE;CN=Ken Murchison;CUTYPE=INDIVIDUAL;EMAIL=[email-masked];RSVP
  =TRUE;PARTSTAT=NEEDS-ACTION:mailto:[email-masked]
ATTENDEE;CN=Michael Douglass;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED;ROLE=CHA
  IR;EMAIL=[email-masked]:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOh
  cljjCSqMYrUXDcs6f1z7CyXejTR/principal/
END:VEVENT

I believe a URI doesn't require a scheme - a simple path is sufficient

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 17 Feb 2021 11:24:30 -0500

Hi Michael,

--On Wed, 17 Feb 2021 11:04:41 -0500 Michael Douglass 
<[email-masked]> wrote:

> Thanks Cyrus.
>
> See below
>
>> 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.
>>
> I think I meant only if the value is not a mailto:. I assume in the absence
> of any other indication (e.g. a valid email) this might be a fallback?

Of course you can send an iMIP message to any email address and hope it gets 
to the right place! I think the poiunt here is that it should never have to 
be used as a fallback. The ORGANIZER or ATTENDEE property values should be 
mailto's if the intent is to use iMIP. You pasted an example iCalendar 
message below which illustrates the point. The EMAIL parameter has a gmail 
domain, whilst the CUA value is me.com. Sending an iMIP to the EMAIL address 
would result in the scheduling message being intercepted and stored on the 
Google calendar, and not the iCloud calendar.

> One of those was generated by Apple. I created an event yesterday which in
> full is
>
> BEGIN:VCALENDAR

Well that may well be a bug!

> I believe a URI doesn't require a scheme - a simple path is sufficient

I think the syntax and associated text in 
https://www.rfc-editor.org/rfc/rfc3986#section-3 make it pretty clear a 
scheme is required.

-- 
Cyrus Daboo

---

From: Mike Douglass <[email-masked]>
Date: Wed, 17 Feb 2021 11:56:49 -0500

Sent from my iPhone

> On Feb 17, 2021, at 11:24, Cyrus Daboo <[email-masked]> wrote:
> 
> Hi Michael,
> 
> --On Wed, 17 Feb 2021 11:04:41 -0500 Michael Douglass <[email-masked]> wrote:
> 
> 
>> Thanks Cyrus.
>> 
>> See below
>> 
> Of course you can send an iMIP message to any email address and hope it gets to the right place! I think the poiunt here is that it should never have to be used as a fallback. The ORGANIZER or ATTENDEE property values should be mailto's if the intent is to use iMIP. You pasted an example iCalendar message below which illustrates the point. The EMAIL parameter has a gmail domain, whilst the CUA value is me.com. Sending an iMIP to the EMAIL address would result in the scheduling message being intercepted and stored on the Google calendar, and not the iCloud calendar.
> 
> I think the syntax and associated text in https://www.rfc-editor.org/rfc/rfc3986#section-3 make it pretty clear a scheme is required.

So it does - bug then. However it may be Thunderbird - it’s very hard (at least I don’t know of a way) to get apple calendar to export a single email so I sent it and saved the attachment.

I’d need to check further

---

From: "Neil Jenkins" <[email-masked]>
Date: Fri, 19 Feb 2021 14:06:57 +1100

Thanks for the background Cyrus. So just to confirm, the CUA is:
 * The target for sending iTIP messages. This may be a mailto URI for iMIP, but may also be some other UI (which is essentially an opaque string to clients) if you have some internal mechanism for delivering the messages.
 * A kind of UID that's consistent for the same participant across different events.
Is that right? Presuming so, then going back to the discussion of translation between iCalendar and JSCalendar, I think this maps very cleanly with the current spec:
 * The CUA maps to the sendTo property <https://tools.ietf.org/html/draft-ietf-calext-jscalendar-32#page-36> of the Participant. There would be a single value in the sendTo map: if it's a `mailto:` URI the value would be under the key `imip`, otherwise it would be under the key `other`.
 * The EMAIL parameter value maps to the email <https://tools.ietf.org/html/draft-ietf-calext-jscalendar-32#page-36> property of the Participant. Just as Cyrus says it's supposed to work in iCalendar, this may be different to the iMIP address and is for sending normal email to the participant, not iMIP messages.
Neil.

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 18 Feb 2021 22:23:22 -0500

Hi Neil,

--On Fri, 19 Feb 2021 14:06:57 +1100 Neil Jenkins <[email-masked]> 
wrote:

>  * The target for sending iTIP messages. This may be a mailto URI for iMIP,
> but may also be some other UI (which is essentially an opaque string to
> clients) if you have some internal mechanism for delivering the messages.
> Is that right?

Yes.

> Presuming so, then going back to the discussion of
> translation between iCalendar and JSCalendar, I think this maps very
> cleanly with the current spec:
>  * The CUA maps to the sendTo property <https://tools.ietf.org/html/draft-
> ietf-calext-jscalendar-32#page-36> of the Participant. There would be a
> single value in the sendTo map: if it's a `mailto:` URI the value would be
> under the key `imip`, otherwise it would be under the key `other`.

Can't we just use the URI scheme to determine the method? Why do we need 
'imip' and 'other' nested keys? I realise we might one day have e.g., 
multiple HTTP based scheduling protocols, but I feel like those should all 
have some kind of unique scheme. (Note this is just a question as to what 
drove the current design, not a request for a change - I am cognizant of the 
fact that we spent many man-hours debating the form of calendar user 
addresses for iSchedule without getting anywhere).

>  * The EMAIL parameter value maps to the email
> <https://tools.ietf.org/html/draft-ietf-calext-jscalendar-32#page-36>
> property of the Participant. Just as Cyrus says it's supposed to work in
> iCalendar, this may be different to the iMIP address and is for sending
> normal email to the participant, not iMIP messages.

Yes.
 
-- 
Cyrus Daboo

---

From: Michael Douglass <[email-masked]>
Date: Thu, 18 Feb 2021 23:01:22 -0500

On 2/18/21 22:23, Cyrus Daboo wrote:
> Hi Neil,
>
> --On Fri, 19 Feb 2021 14:06:57 +1100 Neil Jenkins 
> <[email-masked]> wrote:
>
> Can't we just use the URI scheme to determine the method? Why do we 
> need 'imip' and 'other' nested keys? I realise we might one day have 
> e.g., multiple HTTP based scheduling protocols, but I feel like those 
> should all have some kind of unique scheme. (Note this is just a 
> question as to what drove the current design, not a request for a 
> change - I am cognizant of the fact that we spent many man-hours 
> debating the form of calendar user addresses for iSchedule without 
> getting anywhere).

I'd personally prefer that we don't get too specific about the method. 
Even if it looks like a regular recognizable email we might choose not 
to use iMip.

Could we just specify "schedule" rather than "imip". What if - e.g. - 
one E______e system wants to send a jsCalendar invite to another 
E______e system.

---

From: "Neil Jenkins" <[email-masked]>
Date: Fri, 19 Feb 2021 20:14:54 +1100

On Fri, 19 Feb 2021, at 14:23, Cyrus Daboo wrote:
> 'imip' and 'other' nested keys?

The reason for nested keys is that you might have multiple. For example, at some point I'd like to look again at standardising an HTTP protocol we can use between servers rather than having to keep using iMIP forever. To invite someone external, you would still start by sending an iMIP email, as otherwise we still have the identity problem (we don't know where your calendar is, we just have your email). However, the invitation can include a JSCalendar version as well as the iCalendar version (for backwards compat), and the JSCalendar `replyTo` property can have entries for both imip and also the new protocol. If the invitee's calendar supports it, it can "upgrade" to the new protocol by replying with that instead of iMIP. If not, the iMIP option is still there.

As to why the values have keys instead of just an array of URIs where you just look at the scheme, it's mainly because it's more ergonomic: if my app just supports iMIP, I'll just look for an imip key. If I support multiple, I can quickly check for their presence in order of my preferred priority without having to scan. And of course we could end up with multiple HTTP protocols although I agree it would probably be better to give these unique schemes.

Neil.

---

From: "Neil Jenkins" <[email-masked]>
Date: Fri, 19 Feb 2021 20:18:49 +1100

> Even if it looks like a regular recognizable email we might choose not 

I'm not quite sure what you mean by this. The keys are advertising what methods you support. You definitely need this, because if you are sending an invitation across federated systems, the other side has no other way to know what protocols you support for exchanging scheduling messages. If you're supplying an email that's not for iMIP, you would not include an `imip` property in the participant's `sendTo`; you would just put it in the `email` property, as discussed earlier in the thread.

Neil.