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

[Robert Stepanek <[e-mail]>]

On Tue, Feb 16, 2021, at 12:06 AM, Neil Jenkins wrote:
> On Tue, 16 Feb 2021, at 04:29, Michael Douglass wrote:
>> 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=[e-mail]:/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. 

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

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.


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

> 
> 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.
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify
>