Re: [calsify] RFC7986 and EMAIL parameter

[Cyrus Daboo <[e-mail]>]

Hi Neil,

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

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

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