Re: [calsify] RFC7986 and EMAIL parameter

[Michael Douglass <[e-mail]>]

On 2/18/21 22:23, Cyrus Daboo wrote:
> 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).

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.


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