Subject: [calsify] draft-ietf-calext-jscalendar and participants

From: Michael Douglass <[email-masked]>
Date: Mon, 15 Feb 2021 12:29:38 -0500

I ran into a problem mapping iCalendar ATTENDEE onto jscalendar 
participants.

For example I might have an ATTENDEE that looks like

ATTENDEE;CN=Michael 
Douglass;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED;ROLE=CHAIR;EMAIL=[email-masked]:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOhcljjCSqMYrUXDcs6f1z7CyXejTR/principal/

The value is a URI but certainly not an email address.

Additionally the value is used as a unique key to the attendee - 
something we don't have clearly defined in jscalendar.

I suggest we add a calendarAddress property which maps on to the value 
of the ORGANIZER or ATTENDEE properties.

The "calendarAddress" and "email" properties can then match the behavior 
specified for the EMAIL parameter and ORGANIZER/ATTENDEE values -

    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.

While I appreciate the intent of the jscalendar sendTo I'd suggest it's 
in general unnecessary to specify iMip - iMip is sending email with a 
calendar attachment and it goes to the email address.

I'd suggest that sendTo only be used for non-iMip alternatives - or if 
iMip really should be sent to a different address from email.

So the above would become:

"participants": {

    "123": {

       ....

      "calendarAddress": 
"/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOhcljjCSqMYrUXDcs6f1z7CyXejTR/principal/"

     "email": "[email-masked]"

      ...}

Additional to all this I realised there is no clear mapping for the 
SENT-BY parameter. This is used on ATTENDEE and ORGANIZER when somebody 
else sends on behalf of the participant. I suggest we add a "sentBy" 
jscalendar property for participants.

I believe there's no mapping for the jscalendar "invitedBy" from 
iCalendar - is that so?

---

From: "Neil Jenkins" <[email-masked]>
Date: Tue, 16 Feb 2021 10:06:52 +1100

On Tue, 16 Feb 2021, at 04:29, Michael Douglass wrote:
> I ran into a problem mapping iCalendar ATTENDEE onto jscalendar participants.

> ATTENDEE;CN=Michael Douglass;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED;ROLE=CHAIR;EMAIL=[email-masked]:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOhcljjCSqMYrUXDcs6f1z7CyXejTR/principal/

> Additionally the value is used as a unique key to the attendee - something we don't have clearly defined in jscalendar. 

Unless I'm missing something, that's just the participant id (i.e. the key in the participants object).

> I suggest we add a calendarAddress property which maps on to the value of the ORGANIZER or ATTENDEE properties.

I don't see the purpose of this proposed property.

> The "calendarAddress" and "email" properties can then match the behavior specified for the EMAIL parameter and ORGANIZER/ATTENDEE values - 

> While I appreciate the intent of the jscalendar sendTo I'd suggest it's in general unnecessary to specify iMip - iMip is sending email with a calendar attachment and it goes to the email address.

No, there is a difference:
 * Participant email property: this is the person's email address and can be used if you want to send them an email.
 * sendTo imip property: the user a) accepts calendar updates via iMIP; b) at this address (which may or may not be the same as the email – it may be a calendar-specific address that's just used for iMIP).

> Additional to all this I realised there is no clear mapping for the SENT-BY parameter. This is used on ATTENDEE and ORGANIZER when somebody else sends on behalf of the participant. I suggest we add a "sentBy" jscalendar property for participants.

Sure.

> I believe there's no mapping for the jscalendar "invitedBy" from iCalendar - is that so?

Potentially not, we can register a new iCalendar property.

Neil.

---

From: "Robert Stepanek" <[email-masked]>
Date: Tue, 16 Feb 2021 18:17:05 +0100

> Unless I'm missing something, that's just the participant id (i.e. the key in the participants object).

The difference is that the participant id has no meaning outside a single JSEvent. But a calendar user address is an identifier for an entity across events.

> I don't see the purpose of this proposed property.

It allows for unambigously mapping the ATTENDEE or ORGANIZER property value to JSCalendar and reverse. It's not clear from a multi-valued sendTo property which one should be used as the property value.

There is one other benefit of making more use of calendar user addresses in JSCalendar: the DELEGATED-FROM, DELEGATED-TO, MEMBER-OF, SENT-BY parameters all use calendar user addresses. But in JSCalendar we use participant ids for these properties. If a DELEGATED-FROM calendar user address has no ATTENDEE in iCalendar, we would need to create an artificial participant in JSCalendar. This participant could have an "informational" role, expectReply=false, because it's really not a participant. When mapping back to iCalendar we would need to figure out if to create an ATTENDEE for that. When we use calendar user addresses rather than participant ids for these properties then there is no ambiguity.

> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify
>

---

From: "Neil Jenkins" <[email-masked]>
Date: Wed, 17 Feb 2021 13:50:07 +1100

> It allows for unambigously mapping the ATTENDEE or ORGANIZER property value to JSCalendar and reverse. It's not clear from a multi-valued sendTo property which one should be used as the property va…

My reading of the current RFCs, although I think they are not super clear, is that the calendar user address is the only "sendTo" method. An email may be specified in addition but this is not intended as an iMIP destination (so would not be in the JSCalendar sendTo, just the participant's email property). Is your interpretation that the calendar user address is more like a uid? If so, can you use it for anything other than as an opaque token for equality comparison?

> There is one other benefit of making more use of calendar user addresses in JSCalendar: the DELEGATED-FROM, DELEGATED-TO, MEMBER-OF, SENT-BY parameters all use calendar user addresses. But in JSCal…

It seems a bit weird to me that you would have unresolvable identifiers like this (they don't seem particularly useful). I'd also say that you'd be making the JSCalendar object more awkward to work with (you'd have to linearly scan or build a separate index to get from one of these pointers to the participant it refers to). I would generally say a slightly more cumbersome translation is preferable to all objects in the new format being harder to use.

Neil.

---

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

On 2/16/21 21:50, Neil Jenkins wrote:
>>> Douglass;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED;ROLE=CHAIR;EMAIL=[email-masked] 
>>> <mailto:[email-masked]>:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOhcljjCSqMYrUXDcs6f1z7CyXejTR/principal/
>> The difference is that the participant id has no meaning outside a 
>> single JSEvent. But a calendar user address is an identifier for an 
>> entity across events.
>>
>> It allows for unambigously mapping the ATTENDEE or ORGANIZER property 
>> value to JSCalendar and reverse. It's not clear from a multi-valued 
>> sendTo property which one should be used as the property value.
>
> My reading of the current RFCs, although I think they are not super 
> clear, is that the calendar user address is the only "sendTo" method. 
> An email may be specified in addition but this is not intended as an 
> iMIP destination (so would not be in the JSCalendar sendTo, just the 
> participant's email property). Is your interpretation that the 
> calendar user address is more like a uid? If so, can you use it for 
> anything other than as an opaque token for equality comparison?

5545 only requires that the calendar address be a URI - it does not 
require it be a mailto URI - UNLESS it is used as the destination for email.

The ATTENDEE and ORGANIZER properties typically had a mailto uri as a 
value. When it was decided that the value should NOT be a mailto there 
was clearly a need for somewhere to put the address of the user so iMip 
could be sent - that's the EMAIL parameter. I don't see anything that 
suggests the calendar-address is no longer the identifier for the property.

5545 and 5546 very likely have no mention of an email address other than 
the mailto uri in the value because there was no EMAIL parameter at the 
time.

>
>> There is one other benefit of making more use of calendar user 
>> addresses in JSCalendar: the DELEGATED-FROM, DELEGATED-TO, MEMBER-OF, 
>> SENT-BY parameters all use calendar user addresses. But in JSCalendar 
>> we use participant ids for these properties. If a DELEGATED-FROM 
>> calendar user address has no ATTENDEE in iCalendar, we would need to 
>> create an artificial participant in JSCalendar. This participant 
>> could have an "informational" role, expectReply=false, because it's 
>> really not a participant. When mapping back to iCalendar we would 
>> need to figure out if to create an ATTENDEE for that. When we use 
>> calendar user addresses rather than participant ids for these 
>> properties then there is no ambiguity.
>
> It seems a bit weird to me that you would have unresolvable 
> identifiers like this (they don't seem particularly useful).
Any UID is intended to be an unresolvable identifier - doesn't make them 
any less useful.
> I'd also say that you'd be making the JSCalendar object more awkward 
> to work with (you'd have to linearly scan or build a separate index to 
> get from one of these pointers to the participant it refers to). I 
> would generally say a slightly more cumbersome translation is 
> preferable to all objects in the new format being harder to use.
It was precisely because I was having to do that that I raised the 
issue. The jscalendar spec DOES NOT specify that the id for a 
participant is the calendar address and the examples don't show it either.

What concerns me is that jscalendar seems to be essentially rewriting 
iTip - perhaps not intentionally.

We currently have 2 'properties' - the iCalendar attendee value - a 
calendar user address and an email address which may be the same or 
specified in the EMAIL parameter.

I do believe the EMAIL parameter to be underspecified but nothing in the 
text leads me to believe it is intended to replace the calendar address.

If we add a jscalendar calendarAddress property the mapping is simple 
and what works now will continue to work.

We *could* try some experiments and mess around with the values but if 
we don't have an easy reversible mapping between jscalendar and 
icalendar things will almost certainly break.