Re: [calsify] RFC7986 and EMAIL parameter

[Michael Douglass <[e-mail]>]

Thanks Cyrus.

See below

On 2/17/21 10:22, Cyrus Daboo wrote:
> 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.
>
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?


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

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=[e-mail]:mailto:2_GM4T
  GNJSHAZTSMZVGI4DGOJTGW7UOVQIXU6S7IXFKVSLJVS4VP4YX5J2UCRWN6KC2YMIGY25PWAA
  [e-mail]
UID:E5C6F579-5003-4755-B29D-572E0FF147B1
DTSTAMP:20210217T051817Z
SEQUENCE:1
SUMMARY:Testing email param
LAST-MODIFIED:20210217T051817Z
CREATED:20210217T051744Z
ATTENDEE;CUTYPE=INDIVIDUAL;EMAIL=[e-mail];RSVP=TRUE;PARTSTA
  T=NEEDS-ACTION:mailto:[e-mail]
ATTENDEE;CN=Ken Murchison;CUTYPE=INDIVIDUAL;EMAIL=[e-mail];RSVP
  =TRUE;PARTSTAT=NEEDS-ACTION:mailto:[e-mail]
ATTENDEE;CN=Michael Douglass;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED;ROLE=CHA
  IR;EMAIL=[e-mail]:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOh
  cljjCSqMYrUXDcs6f1z7CyXejTR/principal/
END:VEVENT

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